# Help with working out a checksum

I'm trying to work out how to reverse engineer the checksum on infrared remote data stream for a heat pump. I've established that it's not a CRC, and I've tried methods found on this forum. It doesn't appear in other works like this one.

I'm tearing my hair out because it appears to be XOR, and it works some of the time. I'm reaching out to see if anyone here can give me some pointers.

``````0xCB8830C000191B
0xCB8830200019FB
0xCB8830A000197B
0xCB8830600019BB
0xCB8830E000193B
0xCB8830100019C3
0xCB883090001943
``````

For info, the data changing is the selected temperature. The 4th byte, `0xC0` in the top item is 19 oC, the one below – `0x20` – is 20 oC. If you reverse all the bytes, the temperature makes more sense and needs 16 decimal adding.

The checksum is the last byte. Working on `0xCB8830C000191B` and taking `0xCB` as the 1st byte, XOR bytes D1, D3, D4, D5, D6 = `0x22`. XOR this with `0x39` and you get the desired checksum of `0x1B`. This works for all the ones ending in `B`, but is off by 8 for the last 2. I can't find any data such as counting bits that gives me this difference.

To help other people trying to do the same, the stream comes from a Airton heat pump, which is only sold in France. It's also sold under Ferroli and Lamborghini (really!)

Ferroli and Lamborghini heat pumps are built by Gree, so why not yours, too?

For some IR remote from Gree with 8Byte of data in 2 pulse trains you will find here a description of checksum calculation. Location of Temp in the stream is different, but calculation by `16 + 0x0` to `16+0xF` is the same. I think, your wording "The 4th byte, 0xC0 in the top item is 19C, the one below 0x20 is 20C." is not correct here.

However the following works for the small number of provided codes, above 4 bits are used for Temp and data are presented in 14 nibbles, thereof 12 data I assume that last byte is 1 nibble checksum and 1 nibble parity, then

• when last bit for Temp is even (2, 6, A, C, E), the nibble(13) at the end is `B`. When odd (1, 3) then `3`, just like a parity information.
• xor all nibbles (0) to (11), then xor(13) gives checksum nibble(12)

Nevertheless it needs to be noted that considering just parity might be not good enough, when other bits in code are changing.

@dieter reichl. Thank you for the suggestion. Another solution that has been found is based on ordering the data LSBF, i.e. `0xDB9800000C11D3`

Packet structure is `|CS|D0|D1|D2|D3|D4|D5|`

Checksum calculation formula is `CS = ((0x7F - (D0+D1+D2+D3+D4+D5)) % 0x100) ^ 0x2C`.

Credit to PtilopsisLeucotis for this solution posted here.