Understanding IR Protocol Checksum generation

Question

To control my AC with an Arduino, I'm trying to emulate the IR Remote. Not with another IR LED, but directly connected to the IR Receivers Signal wire on the board.

Using the Arduino as a Logic Analyzer I was able to understand the Protocol to about 90%.

Problem is, that the last Byte seems to be some kind of checksum. To send my own commands I need to figure out how it is calculated. I have no Idea.

The following gist contains all the Information that I have about the Protocol. It's pretty long (112 Bit) By replaying the exact commands I can control the AC Unit.

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

Adding it directly to this page doesn't work very well, because the formatting gets completely messed up. The protocol is just way too long.

Important: The remote doesn't seem to work like a normal remote. It doesn't send keycodes, but whole state "objects".

Maybe someone here will see some kind of pattern in that data. :-)

Answer 1

Here's my analysis, based on your small sample of data:

If you ignore the "Never changes" data, and also remove the zeroes before the checksum, your data looks like this:

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

So that's four bytes of data and one byte of checksum (or whatever).

Now, reverse the order of the bits within those four data bytes (checksum omitted), so I mean bit 0 becomes bit 7, bit 1 becomes 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

Now sum each row, modulo 255, reverse the order of the bits again, and compare the result with your checksum:

01111110
10000010
10000000

10001001
10010001

10001101
10001001

It works for me, but maybe there's more of that data (like the zero padding) that's taken into account, but we'd need more samples to figure it out. For now, you can create the checksum byte by simply reversing the order of the bits of each data byte (i.e. ignore the "never changes") and taking the sum, modulo 255, then reverse the order of the bits of that sum.

All of this necessity for bit reversal suggests that the data is being sent the opposite way to how you're interpreting it. For example, it's being sent MSB first and you assume LSB first or vice versa. Other than that, the checksum is just a cumulative sum of the data, ignoring overflow.

Answer 2

Reverse the order of the bits in each byte. Add each byte(ignoring checksum and the "never changes" blocks), modulo 0xff. And add 0x55 to the sum. Reverse the final sum to get your expected checksum.

Answer 3

In my case, I also needed to add a constant, but it was not 0x55. And I needed to substract the number of bytes transmitted (my frames have variable length).