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!
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.
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.
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
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.
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?
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.
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.
