lunes, 28 de marzo de 2016

Duos, Duelos y Trios (SO1V)

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!

1 comentario:

  1. Desde winXP en adelante, el propio sistema operativo se sincroniza con los servidores ntp. Siempre que estés conectado a internet.

    ResponderEliminar

Buscar este blog

Páginas vistas en total