Desde hace, aproximadamente, dos años que vengo usando en la configuración de fonía (SSB) de mi estación concursera el programa HZVox. Este programa surgió como solución a la falta de VOX en el FT-840 que usualmente utilizo como rig1 y en el funcionamiento desagradable del VOX que si tiene el FT-890 que uso como rig2. El programa, siendo capaz de disparar el PTT desde el mezclador de la placa de sonido es también entonces capaz de activar el PTT del emisor que corresponda (en modalidad SO2R).
El esquema funcionó bien por todo este tiempo y me dió buenos resultados, pero incrementa la complejidad de cableado de la estación; justamente lo que tengo en la mira reducir en este momento.
Para empezar el PTT se hace con un "doble comando" entre el N1MM quien emite su señal via el puerto paralelo (en mi configuración, podría hacerlo por el o los puertos serie) mientras que HZVox lo hace por un puerto serie adicional; las tres señales (PTT via puerto paralelo manejado por N1MM, FOCUS via puerto paralelo manejado por N1MM y PTT via puerto serie manejado por HZVox) se juntan en el controlador SO2R de transmisión activando las conmutaciones necesarias para rutear el audio al equipo que corresponda y activar su PTT correspondiente. Simple, efectivo, y sin muchas dependencias entre los programas involucrados. Pero al mismo tiempo requiere un puerto paralelo, un puerto serie, un controlador SO2R de transmisión y una buena madeja de cables llevando audio y señales entre la PC y el controlador siguiendo luego del controlador a los equipos.
Todos esos tienen que volar.....
Ensayé y revisé prototipos de distintos enfoques; como siempre me fui chocando con callejones sin salida donde o no funcionaba o me seguía requiriendo un cablerío importante para implementarlo.
El primero fue tratar de usar la "interfaz" natural del N1MM, el puerto paralelo que ya tengo de todas formas habilitado como Keyer para telegrafía y que rutea a los equipos respectivos; para simplificar tengo que hacer un conector diferente para telegrafía que para fonía puesto que en un caso el manipulador se activa con el pin 16 del puerto paralelo mientras que en fonía con el puerto 17. Se puede hacer un circuito sencillo de conmutación para utilizar uno solo (ruteando el "hot" desde pin 16 o 17 según corresponda puesto que el FOCUS y el strobe de masa son iguales en ambas configuraciones) pero eso ya impide que el controlador esté dentro del conector mismo, belleza que había logrado en la configuración de CW y que no quería perder. Pero no es tan terrible tener un adaptador que sea para CW y otro para SSB, no los uso excepto en concursos y no participo (por ahora) en concursos con formatos mixtos (excepto el CAHF, pero supongo que hacer el cambio en el entretiempo no es un gran obstáculo). El obstáculo real es que en CW se rutean entre la PC y los equipos dos señales (Speaker y KEYER) mientras que en fonía son tres (Speaker, MIC, PTT). Podría hacer un cable "especial" de tres hilos con blindaje o usar dos cables estereo; lo que hace que entre PC y equipos se ruteen 3 cables (CAT + speaker + ptt/mic) en lugar de 2 cables (CAT + speaker/ptt). Pero además del cable adicional (que como digo se puede solucionar con un cable especial) permanece un problema de arquitectura. N1MM se "sienta" sobre el puerto paralelo y no comparte su propiedad con otros programas (algo similar a lo que pasaba con los CAT y solucioné con el programa MM2OR hace tiempo ya). Desafortunadamente no hay, o no encontré, un device driver virtual como com0com pero para puertos paralelo; he escrito varios device drivers para Windows y eso ha generado un sano respeto por la complejidad técnica de desarrollarlos y probarlos, a diferencia de otros programas pequeños problemas de performance o estabilidad comprometen a todo el ambiente ejecutando en la máquina. Los DD ejecutan en modo privilegiado del procesador con iguales o mayores privilegios que el Windows mismo; no, eso es la última opción.
Estudié en detalle los sources del programa N1MM Logger mismo, a cuya lista de distribución Tom Wagner (N1MM) accedió amablemente a sumarme hace algún tiempo, viendo como opera el proceso de manipulación, el que es notoriamente complejo debido a la enorme variedad de alternativas que ofrece y dispositivos que soporta. Pero en esencia, el N1MM cuando detecta que tiene que activar el PTT envia un mensaje por TCP/IP (interno) entre el programa logger base y un programa servidor medio oculto que corre como su compañero de ruta llamado "CW IF.exe" que el mismo N1MM se encarga de levantar y bajar. Ese mensaje utilizar un formato XML. Me llamó la atención lo flexible de la arquitectura. El programa que realmente tiene la "propiedad" del puerto paralelo es "CW IF.exe" y no el logger mismo. Esto es una oportunidad porque si logro hacer un programa que envie el mismo mensaje a "CW IF.exe" como-si-fuera el N1MM podría (en teoría) prender y apagar el PTT con la lógica misma del logger pero desde otro programa.
Compartí la idea con Tom Wagner quien si bien confirmó que el análisis era correcto desaconsejó ese enfoque puesto que dejaría de ser válido en la nueva versión (basada en .net) que están construyendo, me aconsejó utilizar OTRSP (Open Two Radio Switching Protocol) con el mismo propósito; lo que efectivamente es un buen consejo porque me aleja de meterme con el funcionamiento interno del N1MM (¿es eso quizás lo que procuró Tom? :-) ) pero tiene el inconveniente que requiere de un hardware especial que lo soporte, cosa que yo no tengo. Quizás algún proyecto futuro porque el protocolo luce accesible de implementar en alguna plataforma embebida como Arduino o un PIC, pero no ahora.
Pero revisando el código para entender como funciona el OTRSP dentro del N1MM me tropecé con la solución, estuvo ahi todo el tiempo, y era además... la más facil. El viejo criterio KISS riendose de mi en la cara.... y "descubierto" de la forma mas retorcida posible, leyendo el código fuente y no navegando simplemente por las opciones del N1MM.
El N1MM permite activar el PTT mediante el CAT (Config/Hardware/Set--> PTT via Radio command).
Por su parte hace rato que tengo solucionado el compartir el CAT en mi estación via la ya mencionada integración con OmniRig via el programa MM2OR. O sea que todo lo que necesito es que otro programa (HZVox modificado) emita los comandos para prender y apagar el PTT via el CAT en vez de hacerlo via un puerto serie. Con este concepto, que estoy haciendo como prototipo y hasta ahora parece funcionar bien, solo requiero de dos cables entre PC y equipos; uno para el CAT y otro para transportar Spkr/Keyer en CW o Spkr/Mic en SSB. Ambos cables Stereo, algún día resumibles a un solo cable cuadrifilar por equipo. Y además elimino los dispositivos de hardware externos para SO2R e incluso el uso de puerto alguno en la máquina para SSB. Casi que me estoy acercando a los límites de que tan simple se lo puede hacer.....
No hay comentarios:
Publicar un comentario