Aircon remote control IR analysis checksum

This is my first time post my problem in this forum. I really need help on this project.

I am working a project of home automation but first I need to decode my air conditioning remote control. Anyway I have successfully receive raw signal and try to decode it. Skip the header, 19 bytes of raw signal are convert to 1 and .(0). A example signal shown as below
[.1… …1… …111 …1… … 1…11… …1111… …1 1111.1.1 … … .11… …11. … … …1 … .11.1… .1111…1

The last byte[19th] assume to be checksum
6th is OnOff[4bits]/Mode[4bits]
7th is Temperature
9th is Swing direction(Vertical)[4bits]/ Wind[4bits]
11th,12th,13th is TimerOff

However, the 18th byte is unknown. It changes between .11.1… and .11…

Because of the raw data is too long and too many. I will attach Infrared raw signal data and binary converted data.

I need help with the checksum algorithm and the 18th byte’s mystery. Please!

airconIRanalysis.txt (11.2 KB)

IRrawsignal[439].txt (136 KB)

Reveng is an excellent tool for solving CRC checksum algorithms.

To use it, you must represent the message as a series of bytes, expressed in hexadecimal format.

Thank you for your idea. However, It shows no models found! :frowning:

/home/user/reveng-2.1.1/bin/i386-linux/reveng -w 8 -s 4004072000800401f500006006000001006042 4004072000000401f500006006000001006082 4004072000800c01f50000600600000100604a 4004072000823c01f500006006000001006079 40040720008c0c01f500006006000001006849 4004072000840c01f500006006000001006841 40040720008c0401f500006006000001006841 40040720008c4401f500006006000001006821 40040720008c2401f500006006000001006861 40040720008c6401f500006006000001006811
/home/user/reveng-2.1.1/bin/i386-linux/reveng: no models found

It is hard to think that Aircon remote has a complex checksum. Maybe I should try a different way.

A 16 bit CRC is a possibility.

In reveng trials, you must make sure to include only the part of the message for which the CRC is calculated. Sync sequences and message start/stop symbols usually aren't.

Also, reduce the number of trial messages to 3. A single error in one message invalidates the entire batch.

40040720008c0c01f500006006000001006849
40040720008c0401f500006006000001006841

40040720008c0401f500006006000001006841
40040720008c2401f500006006000001006861

It looks like a simple modulo 256 check sum to me.

The difference between 1 and 2 above is in the 7th byte. 0x0C and 0x04. The difference is 0x08. The difference between the check digit bytes is also 0x08.

The same with 3 and 4. A difference of 0x20 in the payload is reflected in a difference of 0x20 in the check digits.

jremington:
A 16 bit CRC is a possibility.

In reveng trials, you must make sure to include only the part of the message for which the CRC is calculated. Sync sequences and message start/stop symbols usually aren't.

Also, reduce the number of trial messages to 3. A single error in one message invalidates the entire batch.

Unfortunately, I also tried CRC-16bit but still does not have a match model.

/home/user/reveng-2.1.1/bin/i386-linux/reveng -w 16 -s 4004072000800401f500006006000001006042 4004072000000401f500006006000001006082 4004072000800c01f50000600600000100604a 4004072000823c01f500006006000001006079
/home/user/reveng-2.1.1/bin/i386-linux/reveng : no models found

6v6gt:
40040720008c0c01f500006006000001006849
40040720008c0401f500006006000001006841

40040720008c0401f500006006000001006841
40040720008c2401f500006006000001006861

It looks like a simple modulo 256 check sum to me.

The difference between 1 and 2 above is in the 7th byte. 0x0C and 0x04. The difference is 0x08. The difference between the check digit bytes is also 0x08.

The same with 3 and 4. A difference of 0x20 in the payload is reflected in a difference of 0x20 in the check digits.

Thanks for helping me! The difference between those two set of data seems correct but cannot interpret other checksums like those below.

40040720008c0401f500006006000001006841 #Cold16C
40040720008c4401f500006006000001006821 #Cold17C
40040720008c2401f500006006000001006861 #Cold18C
40040720008c6401f500006006000001006811 #Cold19C
40040720008c1401f500006006000001006851 #Cold20C

If one bit changes in the message, and only one bit changes in the check value, it is not a CRC type of checksum.

It is something else, like a simple sum or XOR.

pbafiren:
Unfortunately, I also tried CRC-16bit but still does not have a match model.

/home/user/reveng-2.1.1/bin/i386-linux/reveng -w 16 -s 4004072000800401f500006006000001006042 4004072000000401f500006006000001006082 4004072000800c01f50000600600000100604a 4004072000823c01f500006006000001006079
/home/user/reveng-2.1.1/bin/i386-linux/reveng : no models found

Thanks for helping me! The difference between those two set of data seems correct but cannot interpret other checksums like those below.

40040720008c0401f500006006000001006841 #Cold16C
40040720008c4401f500006006000001006821 #Cold17C
40040720008c2401f500006006000001006861 #Cold18C
40040720008c6401f500006006000001006811 #Cold19C
40040720008c1401f500006006000001006851 #Cold20C

These pairs do exhibit the same behaviour:

40 04 07 20 00 8c 04 01 f5 00 00 60 06 00 00 01 00 68 41 #Cold16C
40 04 07 20 00 8c 14 01 f5 00 00 60 06 00 00 01 00 68 51 #Cold20C

40 04 07 20 00 8c 14 01 f5 00 00 60 06 00 00 01 00 68 51 #Cold20C
40 04 07 20 00 8c 24 01 f5 00 00 60 06 00 00 01 00 68 61 #Cold18C

That is, a single change in the payload part causes a corresponding change in the check digit.

These, however, don't, at least not modulo 256:

40 04 07 20 00 8c 64 01 f5 00 00 60 06 00 00 01 00 68 11 #Cold19C

40 04 07 20 00 8c 44 01 f5 00 00 60 06 00 00 01 00 68 21 #Cold17C

Each of the 19 byte data streams appear to be preceded by what looks like a 7 byte header, which you have not decoded. These could be included in the check digit calculation. Are those headers always identical?

Thanks guys! I just successfully decoded the last byte checksum of the IR signal. Turns out it is simple 8 bit modulo 256 checksum( reversed form). The checksum are the sum of reversed previous 18 bytes and then reverse the last 8 bits of sum value again. The following code is written in python

a = a.replace(".", "0").replace(" ", "").replace("[", "") #E.g a="1...1... ..1.1..."
a = hex(int(a, 2))  #Binary to hexadecimal for easy read
a = a[2:]  #skip the "0x"
item = [a[2 * i:2 * i + 2] for i in range(int(len(a) / 2))]   #separate by 1 byte
for i in item:
     byte = "{0:08b}".format(int(i, 16))  #Hex to bin
     reverse_byte = byte[::-1]  #reverse the byte
     check_sum += int(reverse_byte, 2)  #addition of all reversed byte
check_sum = format(check_sum % 256, "08b")[::-1]    #reverse the final checksum

However the change in 18th byte still remain unclear. Does anyone know what factor makes the 18th byte change?

What change? All the examples posted show 68.

The posted example only show some of the original signals. I have used same condition but different temperature for ease of comparison between checksum. Besides, some hexadecimal converted signal show 0x60 like the code below when I was trying to analyze CRC checksum model.

pbafiren:
/home/user/reveng-2.1.1/bin/i386-linux/reveng -w 8 -s 4004072000800401f500006006000001006042 4004072000000401f500006006000001006082 4004072000800c01f50000600600000100604a 4004072000823c01f500006006000001006079 40040720008c0c01f500006006000001006849 4004072000840c01f500006006000001006841 40040720008c0401f500006006000001006841 40040720008c4401f500006006000001006821 40040720008c2401f500006006000001006861 40040720008c6401f500006006000001006811

The 18th byte only shows differences between 0x60 and 0x68. Which is 0b01100000 and 0b01101000 in binary. In this moment, I have identified the OnOff/Mode byte, Temperature byte, Fan/Swing byte, TimerOff byte. But I still can't see the connection in the 18th byte.

This looks similar to the check digit encoding scheme you have published: Decoding a Midea Air Conditioner Remote | Matthew Petroff
Maybe you get a clue from there about the mystery byte also.