Eso tiene una consecuencia negativa para mi, el N1MM asume que tiene el control CAT (Computer Aided Tuning) full del transceiver y que este no es compartido con ningún otro programa. Mala cosa cuando al mismo tiempo en la estación tengo 4 o 5 programas que también necesitan controlar el transceiver, lo que en general ocurre via OmniRig. La solución lleva ya mucho rodaje y es el programa MM2OR (N1MM to OmniRig) el que básicamente simula un puerto serie (con la ayuda del utilitario com0com) al cual el N1MM envia comandos como si fuera un transceptor, el programa empaqueta las instrucciones en formato OmniRig y las envia al transceiver, el mismo al contestar recibe la respuesta y se la envia a N1MM para su proceso. De esa manera los requerimientos de múltiples programas son coordinados por el OmniRig (ese es su propósito).
Con la migración a N1MM Plus vino la grata sorpresa que han escrito el driver CAT de forma que ahora funciona bien. En la versión de N1MM Classic sea por deficiencias de programación o por limitaciones del driver serie que utilizaban el procesamiento de comandos CAT estaba, malamente, roto.
En efecto, en los equipos Yaesu en general los comandos CAT consisten en registros de 5 bytes de longitud, el último de los cuales lleva el comando mismo. De ser necesario algun argumento este es transportado por los 4 bytes restantes. El argumento puede ser, de acuerdo al comando, ningun byte, un byte o mas bytes.
El N1MM emite constantemente dos mensajes de pedido de "status" al transceptor, el denominado frame 0x10 (leer status) y 0xfa (leer flags). El transceptor contesta con mensajes de diferente longitud a ambos y el N1MM Classic esperaba que las respuestas volvieran juntas, cuando una implementación correcta hubiera sido que el programa fuera capaz de procesar las respuestas en el orden que volvieran. Los intentos para que en el team de desarrollo del N1MM corrigieran eso fueron siempre en vano, no se si no entendían el problema, o no afectando a la mayoría de los usuarios preferían ignorarlo.
Como fuera por prueba y error logré interpretar como esperaba el N1MM los datos y con mi programa MM2OR mimetizaba la "anomalía" para que todo funcionara. Eso tenía el problema que cada equipo tenía una "anomalía" ligeramente diferente y por lo tanto habia que generar respuestas ligeramente diferentes también. Por eso adopté una arquitectura donde las respuestas a cada equipo están encapsuladas en una DLL diferente, por lo que en la configuración respectiva había que decir con que DLL se requería hacer la comunicación.
En el N1MM Plus este problema fue resuelto, ahora el software procesa correctamente los frames de respuesta del transceiver en forma individual, sin esperar ningún agrupamiento en particular, y por lo tanto mientras el transceiver reciba los 5 bytes del comando y conteste con la longitud de respuesta esperada todo parece funcionar bien.
La consecuencia inmediata es que con una sola DLL alcanza para manejar todos los equipos Yaesu cuya secuencia CAT utilice los mismos comandos y que reciba 5 bytes de longitud de comando; lo que es mucho mas simple. Hasta donde he podido revisar los comandos utilizados por N1MM son 0x01 (Split), 0x05 (VFOA/B), 0x0a (establecer frecuencia), 0x0c (establecer modo), 0x0f (ptt, en algunas configuraciones), 0x10/0xf7(?)/0xfa (status).
En principio no solo los comandos, sino también el formato mismo de todo el intercambio, varía de fabricante en fabricante y por lo tanto es improbable que esta implementación sirva para transceivers ICOM o Kenwood (u otros); de hecho no estoy seguro que sirva para todos los Yaesu si es que utilizan un formato de protocolo CAT diferente; lamentablemente no puedo dar soporte en esos casos pues para depurar el ambiente es necesario realizar pruebas.
He generado una nueva versión del programa MM2OR v1.8 que ahora tiene solo una DLL de soporte denominada YAESUB.DLL y con la que en apariencia puedo manejar indistintamente todos los equipos Yaesu en mi shack (FT100, FT840, FT890 y FT817), un gran avance.
No hay comentarios:
Publicar un comentario