martes, 28 de febrero de 2012

Parche para operar SO3R de LU7HZ

Desde hace algún tiempo captura mi atención la operación denominada SO3R (Single Operator 3 Radios). Esta es la extensión lógica de la mas común denominada SO2R (Single Operator 2 Radios).
En esta operación, normalmente utilizada en el contexto de concursos, se tiene la capacidad de operar mas de una radio simultaneamente a partir de disponer de un controlador donde se puede seleccionar alternativamente el audio de un equipo, el otro o ambos (uno en cada oido). La idea básica del modo de operación es que se utiliza uno de los equipos en modo "run" llamando permanentemente mientras que el otro se lo utiliza para trabajar multiplicadores o simplemente seguir las condiciones de otra banda con vistas a un cambio (o a la estación de referencia que se utilice para ver como viene el ritmo, normalmente una M/S o M/M cercana). Idealmente mientras se hace el llamado (mediante algún método automático) en un radio (usualmente llamado rig1 por convención) se escucha en el otro (usualmente llamado rig2, también por convención). En operación QRP incluso la interacción es lo suficientemente baja como para que sea viable usar ambos equipos en la misma banda.
Los detalles del modo pueden leerse mas extensamente en el excelente artículo de Dani Perez (EA5FV) que puede ser bajado aqui. El modo básico no está exento de críticas, puesto que (con algo de razón) se argumenta que es solo una forma de dispersar al operador y que ocasiona que no opere bien ninguna radio.
En mi experiencia el controlador SO2R me ha permitido incrementar muy notablemente mis tasas de contacto, casi al doble en un año, puesto que los "run" operando QRP son necesarios para poder levantar el puntaje pero no son tan efectivos (ni cerca) que los equivalentes en LP o (ni que hablar) HP. Entonces uno se encuentra en el dilema de hacer run (porque es lo mas efectivo) con una tasa baja o hacer multiplicadores y otros contactos al mismo tiempo mayoritariamente en search & pounce (S&P). El controlador SO2R permite abordar ambos objetivos.
Al respecto me viene a la referencia un comentario que hizo Juan (LU3HY/LT0H) durante su exposición en la reunión del grupo LU-CG en Alvarez (Santa Fé, Argentina) en Abril del año 2011. En aquella oportunidad Juan esbozó una categorización de la estrategia de operación basado en la tasa que en su momento fue una nota en mi cuaderno de apuntes pero posteriormente pude validar empiricamente; la sugerencia de Juan fue:
  • Tasas de 20 QSO/Hora o menos, puedo utilizar los "chiches" (como el SO2R).
  • Tasas entre 30 y 40 QSO/Hora son las necesarias para tener buen resultado (en HP).
  • Tasas de mas de 40 QSO/Hora no puedo usar SO2R porque me tengo que dedicar 100%.
Si la operación es, además, single band es mas probable que en los momentos que la propagación se está estableciendo o decayendo tenga oportunidades de tasas bajas.
Como quiera que sea lo concreto es que en mi caso su uso me dio muy buen resultado; en una entrada anterior compartí como es el controlador SO2R que utilizo.
Pero ... SO3R?
Me genera curiosidad mas que nada, aunque con un sano excepticismo si el intentar este modo de operación agrega o resta. La usual revisión de bibliografía y antecedentes entrega muy poco.
Los circuitos disponibles en realidad aportan poco porque son conmutadores de audio entre tres (o mas) radios, pero no abordan la mezcla y simultaneidad que requiere este modo (en la mayoría de los casos).
Por otra parte los paquetes de software de concursos soportan rutinariamente el modo SO2R pero ninguno soporta SO3R, algunas respuestas de los autores dan a entender que no lo harán en ningún futuro próximo tampoco.
Finalmente, las referencias operativas son muy escasas; resalta la realizada por Martin Monsalvo (LU5DX) operando la estación cordobesa concursera LP1H en el CQ WW CW del 2010. Incidentalmente, en esa oportunidad Martín refiere que no le anduvo bien.
En lo que a mi respecta solo resta experimentar esta forma de operar y ver si al cabo de varios usos produce alguna mejora o no lo hace; no deja de haber un factor de aprendizaje involucrado que en el caso del SO2R me llevó bastante tiempo (sobre todo en CW) acostumbrarme a sonidos diferentes en cada oido sin que esto me confudiera.
Basado en la experiencia con el controlador SO2R tengo claro que la interfaz de un controlador SO3R tiene que ser mecánica, poder ser operado "al tacto", sin mirar y con una forma espacialmente sencilla de ir a cualquiera de las configuraciones posibles (es decir, sin depender de donde esté para determinar como ir a donde uno quiere). En el controlador SO2R esa interfaz son tres botones, rig1 el de la izquierda, rig2 el de la derecha y rig1/rig2 el del centro. La configuración es tan sensible que originalmente tenía los equipos dispuestos al reves de los botones y tuve que invertir estos ultimos para evitar que me confundiera.
Una configuración SO3R requiere de 6 botones para hacer lo mismo de tal manera de poder seleccionar los pares (i1,i1)(i1,i2)(i2,i2)(i1,i3)(i2,i3) e (i3,i3) a lo que hay que sumar la necesidad de hacer intervenir 3 actuadores para activar los respectivos ruteos; la lógica para hacer eso no es imposible pero no es trivial tampoco.
Un segundo enfoque es implementar una máquina de estados con solo tres botones (atrás, adelante y reset) donde pulsando el atrás/adelante alternativamente se puede retroceder/avanzar entre estados, siendo el de reset el que lo lleve al modo de reposo. Este enfoque es mucho mas simple circuitalmente (basta un PIC pequeño y unos pocos componentes) pero requiere poner mucha atención para operarlo puesto que hay que mirar el controlador para saber en que estado está y acompañarlo con la vista hasta que llegue al deseado.
Un tercer enfoque intermedio es aprovechar el hecho que un controlador SO2R en realidad es un switch N:M (N entradas y M salidas conmutadas) y siempre es posible (por la topología geométrica que implica) generar un switch de orden de conmutación superior tomando uno de orden inferior y agregarle en cascada uno de orden 2:1. Y eso es lo que hice. Implementé un controlador simple que conmuta entre rig2 y rig3 (rig1 es un bypass), su salida (rig1,rig2) o (rig1,rig3) se alimenta al controlador SO2R anterior para dar todas las combinaciones posibles. La desventaja es que se tiene dos cajas de controles, pero la ventaja es que es muy simple de implementar. El circuito está adjunto y utiliza un procesador PIC12F675 junto con dos
relays una via inversora ademas de unos pocos elementos adicionales para comando y control.
En realidad el controlador conmuta (rig1,rig2)(rig1,rig2+rig3) y (rig1,rig3) dando la alternativa de en un momento dado tener el audio del rig1 en un oido y el combinado de rig2 y rig3 en el otro.
En la configuración adecuada y con algo de entrenamiento estoy seguro que se puede manejar tener la mezcla de audio en un oido, en especial si uno de los rigs está tomando ruido y con el otro se busca una estación.
El microcontrolador requiere un firmware realmente sencillo que puede construirse con el IDE de MicroChip o bajarse para grabar directamente en un PIC (.asm y .hex).
El soporte del logger (N1MM en mi caso) puede obtenerse indirectamente configurando la estación como si fuera una M/S con dos posiciones; de esa manera el rig1 y rig2 son controladas por una mientras que la 2da posición (además de proveer un hot backup durante el concurso) puede manejar el rig3 (CAT y eventualmente manipulación si el contest fuera de CW).
¿Andará? .... no tengo idea.... lo usaré en ARRL International DX SSB el próximo fin de semana y ahi me enteraré. Mientras tanto fue bastante divertido ir recorriendo las siguientes etapas de concepción de este experimento, la diversión a menudo está en el camino y no la meta.

No hay comentarios:

Publicar un comentario

Buscar este blog

Vistas de página en total