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

Question

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

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

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

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

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

Añadirlo directamente a esta página no funciona muy bien, porque el formato se estropea completamente. El protocolo es demasiado largo.

Importante: El mando no parece funcionar como un mando normal. No envía códigos de teclas, sino "objetos" de estado completos.

Tal vez alguien aquí vea algún tipo de patrón en esos datos. :-)

Answer 1

Este es mi análisis, basado en su pequeña muestra de datos:

Si se ignoran los datos de "Nunca cambia", y también se eliminan los ceros antes de la suma de comprobación, los datos tienen este aspecto:

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, invierte el pedir de los bits dentro de esos cuatro bytes de datos (se omite la suma de comprobación), por lo que quiero decir que 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 suma cada fila, módulo 255, invierte el orden de los bits de nuevo y compara el resultado con tu suma de comprobación:

01111110
10000010
10000000

10001001
10010001

10001101
10001001

A mí me funciona, pero quizá haya más datos (como el relleno cero) que se tengan en cuenta, pero necesitaríamos más muestras para averiguarlo. Por ahora, puedes crear el byte de la suma de comprobación simplemente invirtiendo el orden de los bits de cada byte de datos (es decir, ignorando el "nunca cambia") y tomando la suma, módulo 255, y luego invirtiendo el orden de los bits de esa suma.

Toda esta necesidad de inversión de bits sugiere que los datos se están enviando de forma contraria a como tú los estás interpretando. Por ejemplo, se está enviando primero el MSB y tú asumes primero el LSB o viceversa. Aparte de eso, la suma de comprobación es simplemente una suma acumulada de los datos, ignorando el desbordamiento.

Answer 2

Invierte el orden de los bits en cada byte. Suma cada byte (ignorando la suma de comprobación y los bloques "nunca cambia"), módulo 0xff. Y añade 0x55 a la suma. Invierte la suma final para obtener tu suma de comprobación esperada.

Answer 3

En mi caso, también necesitaba añadir una constante, pero no era 0x55. Y necesitaba restar el número de bytes transmitidos (mis tramas tienen longitud variable).