Comprensión de la generación de suma de comprobación del protocolo IR

Para controlar mi CA con un Arduino, estoy tratando de emular el control remoto IR. No con otro LED IR, sino conectado directamente al cable de señal de los receptores IR en la placa.

Usando Arduino como analizador lógico, pude entender el protocolo en aproximadamente un 90%.

El problema es que el último byte parece ser una especie de suma de comprobación. Para enviar mis propios comandos, necesito averiguar cómo se calcula. No tengo ni idea.

La siguiente esencia contiene toda la información que tengo sobre el Protocolo. Es bastante largo (112 bits). Al reproducir los comandos exactos, puedo controlar la unidad de CA.

https://gist.github.com/Hypfer/38b3b276e1a0fea92c30

Agregarlo directamente a esta página no funciona muy bien, porque el formato se desordena por completo. El protocolo es demasiado largo.

Importante: el control remoto no parece funcionar como un control remoto normal. No envía códigos clave, sino "objetos" de estado completo.

Quizás alguien aquí vea algún tipo de patrón en esos datos. :-)

si sangra el texto formateado con 4 espacios y se representará aquí como escrito. Quizás este problema sea más actual en un foro de criptografía: como puedes reproducir comandos grabados con éxito, la parte eléctrica está resuelta.

Respuestas (3)

Aquí está mi análisis, basado en su pequeña muestra de datos:

Si ignora los datos "Nunca cambia" y también elimina los ceros antes de la suma de verificación, sus datos se verán así:

00100100 11000000 00000000 01000000 01111110
00100100 11000000 00000000 01100000 01000001
00100100 11000000 00000000 00100000 00000001

00100100 11000000 10010000 00100000 10010001
00100100 11000000 10010000 00110000 10001001

00100100 11000000 11010000 01100000 10110001
00100100 11000000 11010000 01000000 10010001

Así que son cuatro bytes de datos y un byte de suma de comprobación (o lo que sea).

Ahora, invierta el orden de los bits dentro de esos cuatro bytes de datos (se omite la suma de verificación), es decir, el bit 0 se convierte en el bit 7, el bit 1 se convierte en el bit 6, etc.:

00100100 00000011 00000000 00000010
00100100 00000011 00000000 00000110
00100100 00000011 00000000 00000100

00100100 00000011 00001001 00000100
00100100 00000011 00001001 00001100

00100100 00000011 00001011 00000110
00100100 00000011 00001011 00000010

Ahora sume cada fila, módulo 255, invierta el orden de los bits nuevamente y compare el resultado con su suma de verificación:

01111110
10000010
10000000

10001001
10010001

10001101
10001001

Funciona para mí, pero tal vez hay más de esos datos (como el relleno cero) que se tienen en cuenta, pero necesitaríamos más muestras para resolverlo. Por ahora, puede crear el byte de suma de verificación simplemente invirtiendo el orden de los bits de cada byte de datos (es decir, ignore el "nunca cambia") y tomando la suma, módulo 255, luego invierta el orden de los bits de esa suma.

Toda esta necesidad de inversión de bits sugiere que los datos se envían de manera opuesta a cómo los estás interpretando. Por ejemplo, se envía MSB primero y usted asume LSB primero o viceversa. Aparte de eso, la suma de verificación es solo una suma acumulativa de los datos, ignorando el desbordamiento.

Invierta el orden de los bits en cada byte. Agregue cada byte (ignorando la suma de verificación y los bloques "nunca cambia"), módulo 0xff. Y agregue 0x55 a la suma. Invierta la suma final para obtener la suma de verificación esperada.

En mi caso, también necesitaba agregar una constante, pero no era 0x55. Y necesitaba restar la cantidad de bytes transmitidos (mis cuadros tienen una longitud variable).