Bueno, me permito añadir unas cosas que he encontrado leyendo y demás.  El sistema de cable trabaja en las cajitas codificado en lo que se conoce como “Manchester encoding”, y la velocidad a la cual trabaja es de 14.4Kbps.  Uno tiene que modificar el .ini del commchk para 14400, even, 8, 1 que es el estándar.  Lo único que ustedes tienen que tener en cuenta es esto, lo demás es utilizar el commchk en modo DOS porque el windows con commchk u otro tipo de terminal no interpreta el ascii adecuadamente.  El problema del hex del PIC es sincronizar en el Manchester de datos para entonces cambiarlo a rs232 para que sea leído por el com1, en el magic log esto está comprobado por muchas personas y el hex no tiene problemas de sincronía.

Para chuley2000:

Una vez yo estuve en esa situación, no comprendía cómo el pic iba a sacar niveles para comunicarse con el puerto a partir de 5 voltios de alimentación.  Pero simple lo hace… nadie me ha logrado responder esta pregunta, pero lo probé y funcionó sin problemas, y he compartido la información obtenida y no ha tenido ni un problema.  Varias situaciones salen que a veces los comandos que mandan la compañía de cable tienen bytes de relleno (FF) que lo utilizan con estos propósitos.  Ellos también necesitan establecer la sincronía con todos los decos.

Si es curioso porque si uno desea mandarle comandos al deco nada más tiene que usar un programita (como el hexgen o el RScommtool) y un simple inversor para comunicarse con la cajita, y para loggear un pic que decodifique a rs232.  Lo de inversión es porque el formato NRZ o rs232 está basado en esos niveles para transmitir datos, bueno eso es lo que recuerdo.

Saludos