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

Navega tus respuestas
2

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

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

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

La siguiente información 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.

enlace

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.

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

    
pregunta Hypfer

3 respuestas

1

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

Si ignora los datos de "Nunca cambia" y también elimina los ceros antes de la suma de comprobació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

Eso es 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 (suma de verificación omitida), entonces el bit 0 se convierte en bit 7, el bit 1 se convierte en 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 comprobació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 necesitamos más muestras para averiguarlo. Por ahora, puede crear el byte de suma de comprobación simplemente invirtiendo el orden de los bits de cada byte de datos (es decir, ignorar los "nunca cambia") y tomar la suma, módulo 255, y luego invertir 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 la forma en que se los interpreta. Por ejemplo, primero se envía MSB y usted asume LSB primero o viceversa. Aparte de eso, la suma de comprobación es solo una suma acumulativa de los datos, ignorando el desbordamiento.

    
respondido por el Roger Rowland
0

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

    
respondido por el user3779411
0

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

    
respondido por el Benoit-Pierre DEMAINE

Lea otras preguntas en las etiquetas

problema de calibración dspic MPU6050 xiomodule.h no existe tal archivo o directorio