SO1V es la técnica avanzada que
aplicamos todos, no importa que tan básica sea nuestra operación pues significa
“Single Operator 1 VFO” (Operador único con un VFO).
Hay muchas técnicas y trucos de
operación que aun así hay que aplicar y depurar antes de salir de ésta
configuración, sin hablar de sentirse cómodo en ella lo suficiente como para
aplicar “al mismo tiempo” otras acciones y haber llegado a la conclusión que se
está en una meseta de performance de la que se quiere salir.
Automatizar la estación va en la
dirección correcta usualmente, y esto implica por lo pronto tener implementado
un sistema CAT (Computer Aided Tuning),
es decir que los principales parámetros de operación (frecuencia, modo, banda
entre otros) puedan ser controlado por software. Esto agiliza mucho la
operación y será la plataforma sobre la que se construirán otros mecanismos.
En general los programas logger
(N1MM Plus o WinTest por ejemplo entre muchos otros) tienen la capacidad de
utilizar el equipo con el CAT si éste se encuentra disponible.
En mi experiencia el control
ejercido desde el logger es mucho, pero no es todo lo necesario para utilizar
la estación a full.
Encontré que muchos programas
soportan la utilización de un “bus común” para el sistema CAT denominado
OmniRig, con la notable excepción del N1MM Plus (por razones que no son
técnicas y exceden mi capacidad de comprensión).
Se puede aceptar las
restricciones y aplicar lo que ofrezca el logger desarrollar software para
forzar al logger a utilizar OmniRig; bueno yo tomé el segundo camino. En
perspectiva eso se llevó una cantidad muy significativa de esfuerzo, pero me
permitió alcanzar un nivel de integración en la estación que dudo hubiera
podido alcanzar de otra forma.
Un segundo aspecto a considerar
es la utilización de los DX-Clusters, los que no solo dán información sobre las
estaciones disponibles en un momento dado en cada banda sino que alimentan al
logger para que nos dé consejos habitualmente útiles sobre cual es la mejor
banda, donde están los multiplicadores que nos faltan, etc.
El uso de los DX-Cluster es usualmente
pié para un interminable debate técnico, reglamentario e incluso filosófico; no
pretenderé cubrir un espectro tan amplio. Solo reforzar el concepto que éstos
sean utilizados solo cuando reglamentariamente es admisible, en las formas que
se consideran de buen “arte” y si uno se siente confortable con hacerlo.
Existen recursos basados en
cluster mas “grisáceos” y cuya
interpretación debe ser cuidadosa; en general se considera una participación “asistida” cuando el recurso proporciona
información de estaciones y frecuencias para hacer contactos (ésta asistencia
puede ser “humana” en la forma de un operador que releve las bandas y nos lo
diga o “automática” por medio de un cluster).
Por ejemplo un cluster “gráfico”
donde no se dén éstos datos, solo se informe visualmente entre que puntos
geográficos hay contactos reportados; uno puede rápidamente visualizar
aperturas viendo la densidad y distribución de la “mancha” resultante. Otro
ejemplo es utilizar el Reverse Beacon Network pero filtrando los spots que nos
haga a nosotros mismos, de esa forma partiendo de la ubicación de los nodos
reportantes y la intensidad de la señal se pueden sacar conclusiones
importantes sobre el estado de las bandas. Hay muchos otros recursos
disponibles para algo similar, como por ejemplo utilizar ViewProp en conjunto
con DXAtlas. O sencillamente tomar nuestro propio “stream” de cluster, filtrado
convenientemente, y representarlo gráficamente, cosa en la que invertí muchas
horas que en retrospectiva podría haber destinado a mejor uso.
Habrán quienes indiquen en forma
enfática que son o no admisibles basado en sus opiniones, convicciones y
experiencia; también determinados concursos lo considerarán de una forma o de
otra dependiendo de los organizadores. No encontré hasta el momento una
posición única y universal fundada que dirima el debate, no que me haya dejado
satisfecho por lo menos.
Para el uso “manual” son muy
interesantes los Clusters con interfaz Web (como Arcala o DXHot entre otros) y
de hecho no daña tener una ventana abierta en ellos si se está usándolos; pero
cuando la conexión al cluster tienen que ser utilizadas por programas en
general la interfaz de preferencia es la Telnet.
Esta interfaz es un poco “aspera”
para el operador, pero una vez que uno se familiariza con ella se puede sacar
una enorme cantidad de información aparte de lo volcado en cuanto a estaciones.
Se puede tener datos de propagación, estado geomagnético, horarios y muchos
otros. También es útil poder manipular los “filtros” del cluster, que si bien
no son fáciles de asimilar, son extremadamente útiles para filtrar la
información de forma que nos sea mas útil. Por ejemplo, no me sirve de nada un
spot de una estación EA realizado por otra EA o una SP, pues no significa que
tenga alguna posibilidad de tener propagación para trabajarla. Otra historia
muy distinta es la misma estación EA reportada por otro LU, o incluso por
alguien en Sud América (habrá, aún así muchas posibles causas por las cuales
eso no garantice propagación tampoco).
Es cuestión de tiempo que se
necesite tener conexión con mas de un cluster simultáneamente, por ejemplo un
cluster convencional (como lu9da.no-ip.org:9000) al mismo tiempo que la versión
telnet del reverse beacon network
(telnet.reversebeacon.net); en general los programas logger no se sienten
cómodos con esa situación. Por eso es importante utilizar un “bus” de
información de cluster como WinTelnetX que justamente “junta” las corrientes de
varios clusters como si fuera uno solo.
Otro punto de integración
importante, aún en el caso de operación SO1V pero que se potencia al utilizar
modos mas avanzados (como describiré mas adelante), es la utilización del CW-Skimmer.
Alli encuentro un problema de
interpretación, o una vaguedad reglamentaria si se quiere, que atribuyo al
desconocimiento sobre la tecnología por parte de los organizadores en el
sentido de incluirlo (en ocasiones explícitamente) como motivo de transformar
una operación en “asistida”. Eso ocurre porque el CW-Skimmer permite ser
utilizado como medio de decodificación visual, sobre un ancho de banda
importante e indicando las señales distintivas de las diferentes estaciones, es
así como se utiliza para el RBN por ejemplo.
Pero el CW-Skimmer puede
utilizarse también en un ancho de banda mucho mas restringido de un transceiver
(2,5 KHz como máximo), en modo BLIND (no decodifica las señales) solo como
medio de sintonía muy precisa. Permite además utilizar la tecnología de filtros
bayesianos que incorpora (uno de los mas avanzados disponibles) y realizar
experimentos muy sorprendentes de la combinación vista/oido para decodificar
señales muy malamente interferidas.
El CW-Skimmer (existen además
versiones para modos digitales) provee sintonía por “click” en conjunto con el
sistema OmniRig (no es casualidad pues son del mismo autor), que empieza a
mostrar porque es interesante integrar éste con el logger.
Otros paquetes importantes son
sintonizadores rápidos (como el HamPort), digestión de información de bandas
(BandMaster), información en tiempo real de propagación (IonoProbe).
En ocasiones es útil poder
sincronizar el horario de la PC (que suele defasarse unas pocas fracciones de
segundo por mes), encontré que Orbitron (el programa de cálculo de órbitas de
satélite que posiblemente tengan instalados de todas formas) tiene la capacidad
de sincronizarse con servers en Internet con el protocolo NTP, siempre listo!
Desde winXP en adelante, el propio sistema operativo se sincroniza con los servidores ntp. Siempre que estés conectado a internet.
ResponderEliminar