N1MM bug con FT-100D CAT SO2R

Como parte del ajuste de la configuración de mi estación he cambiado al FT100 para que opere como rig1 manteniendo al FT890 como rig2; esa es la configuración que ensayaré al menos en WAE DX CW 2012 y la siguiente fecha del campeonato argentino de HF. Este cambio saca al FT840 que necesita reparaciones nuevamente por una muy marcada distorsión que tiene cuando trato de operarlo en LP (no molesta en QRP), y se vienen 4 concursos de LP (WAE CW/SSB y dos fechas del Argentino de HF).
Sin embargo al terminar el conexionado me encontré con un funcionamiento muy errático del N1MM operado a traves del CAT. Como lo he comentado en este blog el N1MM no da soporte al OmniRig, ni lo dará nunca según palabras de uno de los desarrolladores Joe Subich (W4TV) en una respuesta en el reflector. Según el porque el OmniRig no puede soportar todas las funciones. Eso es una pamplina por supuesto, todo se puede en informática.
Es importante contar con la sintonía integrada entre N1MM y los equipos del SO2R dado que en WAE se puede operar en forma asistida, y pienso sacar todas las ventajas que pueda de hacerlo.
Y en particular en este caso hay una función del OmniRig llamada "custom command" donde el OmniRig no intenta manejar los envios y respuestas del transceptor sino que transfiere transparentemente todo lo que pasa el programa y todo lo que el transceptor contesta. Como sea implementé un programa llamano MM2OR que actúa como una interfaz; le presenta al N1MM una interfaz como si fuera un transceptor conectado por un puerto serie y transfiere los comandos via OmniRig y en sentido contrario las respuestas.
El programa implementa cada transceptor con una Dynamic Linked Library (DLL) que se adquiere por configuración y tienen en cuenta las particularidades de cada equipo; hasta ahora implementé las correspondientes al FT817, FT840, FT890 y FT100.
Lo he usado en varios concursos y anda muy bien. Pero para el caso del FT100 nunca anduvo demasiado bien. Por un lado N1MM hace una implementación defectuosa del CAT en los equipos Yaesu en general y en el FT100 en particular. El programa envia dos comandos separados (0xfa y 0x10) con el objetivo de obtener el estado del transceiver, y lo hace continuamente. El primer comando tiene una respuesta de 8 bytes y el segundo depende del modelo de transceptor pero normalmente es de 32 bytes, los primeros 16 reflejando el estado del VFOA y los 2dos 16 para el VFOB.
Por su defecto de implementación N1MM espera siempre una respuesta de 40 bytes juntos, o sea que la mas minima latencia en la respuesta en los dos comandos hace que de errores; pedir los dos comandos juntos no está mal, esperar las dos respuestas juntas como si fuera una sola si. Cuando la PC corriendo el N1MM habla con el equipo directamente y si tiene buen tiempo de respuesta no tiene problema en procesar la relativamente lenta respuesta de un puerto serie de tal manera que las dos respuestas sean inmediatas; pero cuando hay software middleware en el medio no necesariamente eso ocurre asi y por lo tanto produce fallas erráticas.
En particular en SO2R anda mal, y dá continuamente error. Y siempre he pensado que se trataba de "algo" que mi programa MM2OR daba como respuesta que aunque correcta no terminaba de cumplir lo que el N1MM esperaba; e invertí una cantidad de horas importantes en tratar de resolver el problema; cosa que finalmente logré en todos los transceptores menos el FT100 tomando las respuestas y almacenandolas internamente para luego enviar bloques de 40 bytes contiguos. Hasta que para obtener un patrón de comparación corrí el N1MM directamente controlando al transceptor (con un analizador de tráfico en el puerto serie) para ver que pasaba. Grande fue mi sorpresa al ver que el mismo problema que me daba usando MM2OR lo daba sin el, el problema está en N1MM (!!).
Como en modos digitales uso el N1MM controlando directamente el rig (sin OmniRig hasta este cambio que acabo de hacer) siempre pensé que andaba bien de esa forma. Pero lo que no había tenido en cuenta es que  en digitales el N1MM está configurado como SO1V mientras que en el resto de los modos como SO2R, y es en ese modo que falla malamente.
Afortunadamente John (K3CT) amable como siempre ha tomado el problema y está produciendo versiones de prueba con los que progresivamente superar el problema, y ha empezado a re-escribir el manejo del FT100 completamente. No es la primera vez que John tiene una respuesta tan comprometida y tan buena, y es una maravilla tener semejante soporte de un paquete de software gratuito como es el N1MM. Asi que con un poco de suerte va a quedar todo en orden y andando.