Decoding AC Remote Ir Signal

I am working a project, trying to automate my AC remote using an Arduino.
I have successfully gathered the raw signal and I am in the process to try and decode it.

I have managed to decode most of the signal but I am stuck at the last 2 bytes that I think are some sort of checksum. I could really use some help on this.

It seems to be a 13 byte signal
1 byte header
2 byte swing + temperature
3 byte swing horizontal
4 byte unknown (always 0)
5 byte fan speed
6 byte ac mode
7 byte different modes (e.g. iFeel)
8 byte unknown (always 0)
9 byte on/off
10 byte unknown (always 0)
11 byte unknown (always 0)
12 byte part of checksum?
13 byte checksum

Because the data are too long I have attached some of them in a file.
Here is a link
Ir Data

If anyone can figure out what the checksum algorithm is and if the 12byte is part of it , I would greatly appreciate it.

Below is the included file/link.
You tell about bits. Do You know what byte is? To me it looks like 13 byte.

HEAT AUTO
16 degrees celsius
11000011 11100010 00000111 00000001 00000101 00000000000000010 00000000 00000000 00011000 00000001 00000001 1011101
17 degrees celsius
11000011 11110010 00000111 00000001 00000101 00000000000000010 00000000 00000000 00011000 00000001 00000001 1000011
18 degrees celsius
11000011 11101010 00000111 00000001 00000101 00000000000000010 00000000 00000000 00011000 00000001 00000001 1010011
19 degrees celsius
11000011 11111010 00000111 00000001 00000101 00000000000000010 00000000 00000000 00011000 00000001 00000001 1001011
20 degrees celsius
11000011 11100110 00000111 00000001 00000101 00000000000000010 00000000 00000000 00011000 00000001 00000001 1011011
21 degrees celsius
11000011 11110110 00000111 00000001 00000101 00000000000000010 00000000 00000000 00011000 00000001 00000001 1000111
22 degrees celsius
11000011 11101110 00000111 00000001 00000101 00000000000000010 00000000 00000000 00011000 00000001 00000001 1010111
23 degrees celsius
11000011 11111110 00000111 00000000 00000101 00000000000000010 00000000 00000000 00011000 00000000 00000000 1001110
24 degrees celsius
11000011 11100001 00000111 00000000 00000101 00000000000000010 00000000 00000000 00011000 00000000 00000000 1011110
25 degrees celsius
11000011 11110001 00000111 00000000 00000101 00000000 00000001 00000000 00000000 00001100 00000000 00000000 01000001

You are right, I wanted to write byte, but for some reason, I wrote "bit".
I have edited my first post.

Bits are needed in the final end but, as a beginning, hexadecimal would be easier to scan. When boggling the checksum decimal might be interesting.
How old is the design? Thinking about the eventual checksum..

The ac unit is fairly new, I would say the model is 4-5 year old.

Okey. Depending on the level of security the CRC can be "anything". I coded a 15-CRC, a cyclic one working like a shift register with a few bits fed back, for space communication more than 30 years ago. Not easy to find out by reverse engineering. Try HEX representation. I'll see if I can undust the old memory for other kinds of CRC.

I will mess around with hex a bit. To see if I can figure out anything.

It also seems that I wrote the byte representation wrong

1 byte header
2 byte swing + temperature
3 byte swing horizontal
4 byte unknown --> it seems to change from 1 to zero after 23 degrees
5 byte fan speed
6 byte different modes (e.g. silence, turbo)
7 byte ac mode (heat ,cool, dry)
8 byte special modes (e.g. iFeel)
9 byte unknown (always 0)
10 byte on/off
11 byte unknown (always 0)
12 byte part of checksum?
13 byte checksum

If You can identify the present temperature setting being some 23 byte 4 might have an explanation, above, below.....

The IRremoteESP8266 project supports a large number of air conditioner IR protocols. Perhaps one is similar to your A/C.

https://github.com/crankyoldgit/IRrcemoteESP8266/blob/master/SupportedProtocols.md

For example, some A/C use 88 bit codes (8 bits/byte * 11 bytes). Then 2 more bytes for 16 bit CRC/checksum equals a total of 13 bytes.

From the example shown in post #2 it looks like the last byte is a simple checksum (it increases by 8 as the second byte does).

Good observation!
One simple checksum can be that adding the sum of the message bytes to the checksum should yield zero....

I don't get it, maybe I am missing something. Can you give an example?

What I have tried is below:

11000011 11100010 00000111 00000001 00000101 00000000 00000001 00000000 00000000 00001100 00000000 10000000 11011101
195	  		226		7		1			5		0		1		0			0		12   	0		128		  221
																							575 % 256 = 63  00111111
																											11000000

11000011 11110010 00000111 00000001 00000101 00000000 00000001 00000000 00000000 00001100 00000000 10000000 11000011
195			242		7			1		5		0		1		0			0		12		0		128		 195
																							591	% 256 = 79  01001111

I tried to sum the different bytes and then mod the sum with 256 with no luck.
I also tried to inverse the payload or/and the checksum still no luck.

Well done. Could You post the same adding HEX notation to the printout? So far I don't see a solution.

I think it is LSB first: i.e. byte 4 is not 1 but 128.

In case of an integer, I agree. LSB comes first. But..... There are 11 byte to checksum. There are obviously byte data present. Don't remember but check summing byte wise is still possible. Then I would guess that checksum is one byte.

Yes that is what I mean: each byte interpreted as LSB first (i.e. the first bit is least significant bit of first byte; 9th bit is LSB of second byte etc.), sum bytes 1 - 12, you will get byte 13.

I would like to see the code printing those figures....

First I used the sample code (ReciveDump) from the IRLibrary to get raw data from the IR Sensor
and then I used the analyze tool (auto_analyse_raw_data.py) from a github repo --> GitHub - crankyoldgit/IRremoteESP8266: Infrared remote library for ESP8266/ESP32: send and receive infrared signals with multiple protocols. Based on: https://github.com/shirriff/Arduino-IRremote/

Please... do the digging up and post the code here, using code tags.

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.