IRForum

Posted: **Wed Jul 14, 2021 6:54 am**

I am completely new to working with infrared and I would like to eventually reverse engineer my AC remote. I've got a Daikin ARC433B46 remote but Analysir doesn't seem to decode any of the raw signals. I'm using an Arduino uno with the sketch you provided and the timings look like this.

Code: Select all

Raw: (583) 588, -300, 560, -300, 588, -272, 592, -272, 588, -272, 592, -25180, 3604, -1588, 564, -1160, 588, -272, 592, -268, 564, -304, 560, -1160, 536, -328, 560, -280, 584, -300, 584, -240, 596, -1160, 540, -304, 584, -1160, 564, -1156, 568, -296, 592, -1132, 616, -1108, 560, -1160, 564, -1160, 564, -1160, 592, -268, 564, -300, 588, -1136, 560, -300, 564, -300, 532, -332, 584, -272, 592, -268, 564, -280, 580, -280, 584, -300, 592, -268, 568, -296, 532, -1192, 560, -300, 564, -1160, 564, -300, 616, -244, 560, -300, 588, -1136, 536, -1188, 560, -300, 564, -300, 588, -272, 616, -220, 584, -284, 576, -284, 556, -328, 584, -276, 560, -304, 528, -308, 524, -360, 560, -284, 576, -284, 552, -308, 584, -300, 528, -312, 556, -1188, 504, -1220, 528, -1192, 536, -308, 552, -1192, 532, -328, 532, -1192, 532, -1192, 500, -34696, 3600, -1592, 584, -1140, 556, -304, 532, -308, 556, -328, 564, -1160, 504, -336, 584, -300, 532, -328, 532, -308, 556, -1188, 560, -280, 588, -1160, 560, -1160, 532, -308, 584, -1160, 536, -1188, 560, -1164, 532, -1192, 560, -1164, 532, -328, 564, -276, 556, -1188, 536, -328, 532, -308, 580, -304, 556, -284, 556, -328, 556, -284, 580, -280, 556, -308, 580, -280, 584, -300, 532, -328, 536, -1188, 532, -308, 608, -252, 552, -312, 608, -272, 532, -1192, 532, -308, 556, -1188, 536, -1188, 588, -236, 568, -1192, 532, -308, 588, -1160, 560, -1160, 564, -1160, 536, -308, 552, -1192, 532, -308, 580, -280, 580, -280, 556, -308, 552, -308, 556, -308, 580, -1164, 556, -284, 580, -280, 584, -300, 536, -328, 556, -280, 584, -1164, 528, -308, 556, -34664, 3572, -1620, 560, -1164, 536, -328, 556, -280, 584, -280, 556, -1188, 588, -272, 532, -332, 536, -324, 588, -240, 540, -1216, 536, -308, 580, -1164, 560, -1164, 560, -276, 584, -1164, 588, -1136, 528, -1192, 536, -1188, 532, -1192, 532, -332, 532, -328, 560, -1164, 532, -308, 552, -308, 612, -272, 532, -328, 532, -312, 552, -304, 556, -308, 580, -280, 584, -304, 560, -300, 532, -328, 532, -308, 556, -308, 580, -280, 556, -308, 528, -332, 552, -308, 584, -276, 612, -1136, 560, -280, 552, -308, 584, -1160, 560, -1164, 564, -1160, 560, -280, 580, -280, 580, -304, 536, -1188, 532, -308, 580, -304, 560, -1164, 528, -1196, 504, -332, 584, -304, 504, -336, 528, -332, 556, -328, 584, -240, 592, -284, 556, -308, 580, -280, 608, -276, 532, -1188, 536, -1188, 532, -1192, 532, -1192, 560, -280, 580, -304, 528, -1192, 564, -300, 532, -308, 580, -304, 532, -308, 580, -304, 532, -308, 552, -308, 556, -304, 552, -312, 580, -304, 500, -360, 532, -332, 532, -308, 552, -308, 552, -308, 584, -280, 556, -328, 560, -280, 524, -1220, 556, -1164, 508, -332, 556, -308, 556, -328, 556, -280, 584, -280, 556, -328, 560, -304, 532, -304, 568, -316, 536, -308, 552, -1188, 592, -1112, 552, -332, 556, -304, 560, -304, 532, -328, 532, -328, 588, -272, 532, -312, 520, -340, 556, -308, 580, -300, 536, -328, 560, -300, 536, -304, 556, -328, 532, -308, 552, -308, 528, -336, 580, -304, 584, -276, 536, -324, 560, -304, 528, -312, 580, -280, 556, -1188, 560, -1164, 564, -300, 532, -328, 532, -308, 524, -360, 532, -308, 552, -308, 580, -284, 528, -332, 556, -328, 532, -1192, 560, -300, 532, -308, 552, -308, 556, -308, 552, -308, 556, -304, 580, -284, 556, -328, 504, -1220, 556, -284, 580, -1164, 560, -1164, 560, -1160, 564, -1160, 592,

Perhaps you could double check for me that there isn't any existing protocol for this.

Also, receiving directly in analysir (as opposed to importing) gives me this. Not sure why this happens in AnalysIR but not in the Arduino serial monitor.

I've got samples so if you need them just let me know along with what type and the number of samples you need.

Posted: **Wed Jul 14, 2021 10:30 am**

It decodes as DAIKIN280AC on my system.

However I had to increase the tolerance slider to 120%.

Try that and let me know if it works.

2021-07-14 11_29_13_ScreenShot.jpg

Posted: **Wed Jul 14, 2021 12:23 pm**

Thanks, it works now. In my case I also had to enable all protocols in the protocols drop-down.

As mentioned I can't receive signals properly directly from analysir - I have to paste it from the arduino serial monitor for it to work. It would be a lot more convenient to be able to receive signals directly without having to copy and paste over and over.

Aside from that, do you have any good starting points or examples I could look at to try and reverse engineer this as a beginner? The sequence also seems pretty long - would I be better off trying something easier first?

Thanks for your help.

Posted: **Wed Jul 14, 2021 1:53 pm**

It should be pretty straight forward recording directly into AnalysIR, using hte firmware(s) provided in the initial download.

There are lots of docs provided in the download & manual.

If you cannot figure it out, let me know the IR receiver you are using & teh platform for recording.(arduino model etc).

It is all covered in the docs & firmware

Posted: **Sun Jul 18, 2021 7:50 am**

I've successfully managed to reverse engineer most of the sequence. The checksum was a little tricky to figure out, but I think I got it.

First exclude the first 21 bytes and the last byte from the sequence. Take the sum of what's left and divide by 0xFF. Now, this is the challenging part: add either 0x11 or 0x10 to that value.

I'm not too sure which one is correct because AnalysIR gives me results that are 1 less compared to manually calculating the sum in excel. Also in excel, a large number of results (but not the majority) are smaller than the predicted checksum by 1.

I have attached some signals which I recorded for you to test using the checksum tool as well as an excel spreadsheet. The spreadsheet assumes the formula is +0x11. The ones that do not follow the pattern are highlighted in dark yellow/orange. All values are in denary.

It would be appreciated if you could perhaps try and refine my formula a little if it needs any work. Thanks.

Posted: **Sun Jul 18, 2021 2:07 pm**

ok - I will have a look over the next couple of days.

Posted: **Tue Jul 20, 2021 12:47 pm**

oK...LOOKS LIKE WE HAVE GOT A WINNER,but it was challenging.

The checksum is as follows (Solved using the reverse engineering tools & checksum calculator in AnalysIR):

The sum of all bytes except the last byte using LSB8 format in AnalysIR. (result is = X )

Then add 106 (or 0x6A) to the result above [ S = X+106 ]

The checksum to be placed in the last byte is the lower 8 bits of this. [checksum = S & 0xFF]

Note: for future reference please use the following guide for recording a session of AC signals.
https://wiki.analysir.com/index.php?tit ... r_AC_units
This makes decoding much easier for us. If you have time please submit a complete set as described, to verify the above.

Posted: **Wed Jul 21, 2021 6:50 am**

I'm sorry. It's my fault for not sending you a set of signals where the time varies. You see, I figured out that the remote sends the current time as part of the signal, but I gave you a set where the time remained constant. This is how I came to the conclusion that I had to exclude the first 21 bytes, but you probably didn't know why. But thanks to you, I have managed to find the correct formula.

While I was testing your formula, I realised that the SUM function in the checksum calculator is modulus 0x100, not 0xFF. For convenience purposes, I decided to use that instead. Therefore, we needed to add 0x12 to the sum instead. And hence I was stuck between 0x12 and 0x13.

For some reason though, changing to modulus 256 got rid of most anomalies! Out of 113 signals, only about 9 of them didn't follow the pattern, as opposed to the previous 45/113 wrong checksums. That's including ones where the calculated checksum is 256 whilst the actual checksum is 0 (which makes sense).

Again, my apologies for wasting your time. But thank you for helping me realise my mistake. If 104/113 correct checksums are good enough for you, then I'll prepare to post my overall findings regarding this aircon remote.

Posted: **Wed Jul 21, 2021 12:44 pm**

Yes, please do post the makeup of all the fields....

When I mentioned 0xFF it was a logical 'AND' function which is the same as modulo 0x100.

Unless I am mistaken the timer function in most AC systems are never used & if you are controlling it via some micro-controller, you can always emulate this functionality remotely.

If you still have some signals that do not match the rule...send them to me(in the format suggested) & I will have a look.

Posted: **Wed Jul 21, 2021 3:14 pm**

Alright. This picture pretty much sums it up (open the picture for higher quality).

Before I go in-depth, I'm new to IR so not sure if those are called headers. All I know is that they are the same no matter what. Here we go...

Bytes 14, 15, 16: Time. Not going to go into this since most people won't need it. Also I was too lazy to work that out.

Byte 22: Mode/Timer. Used to control what mode the unit is in, as well as which timer mode it is in if a timer signal was sent. List of values in hex.

Byte 23: Temperature. Values go from 24 to 3E, going up with a step of two for each degree increase. Temperature range is 18 to 31. List of values in hex.
Eg: 18° = 24, 19° = 26, 20° = 28 ... 31° = 3E.

Byte 25: Fan speed. Values increase by 0x10 for each fan speed increment. Values range from 3F to BF. Min speed is 1, max is 5. After level 5 there are two extra modes before it returns to level 1. The pattern is the same. List of values in hex.
Eg: Level 1 = 3F, Level 2 = 4F ... Level 5 = 7F, "Auto" mode = AF, "Quiet" mode = BF.

Byte 27, 28, 29: Timer stuff. Again I am not going to go into this. However I have managed to work it out so let me know if you need it.

Byte 30: Powerful/quiet mode. Values are 01 for powerful, 20 for quiet, 00 for neither.

Byte 33: Econo/sensor mode. Values are 04 for sensor, 02 for econo, 00 for neither.

Byte 34: Mold proof mode. 02 for on, 00 for off.

Byte 35: Checksum. Exclude first 21 bytes. Run through SUM function in AnalysIR and add 0x12. The last two bytes are the checksum.

As a beginner to IR, this was made a breeze with the help of AnalysIR. Thank you for making this awesome tool. Now I just have to figure out how to send these signals...

IRForum

New daikin protocol? [ and checksum SOLVED]

New daikin protocol? [ and checksum SOLVED]

Re: New daikin protocol?

Re: New daikin protocol?

Re: New daikin protocol?

Re: New daikin protocol?

Re: New daikin protocol?

Re: New daikin protocol?

Re: New daikin protocol? [ and checksum SOLVED]

Re: New daikin protocol? [ and checksum SOLVED]

Re: New daikin protocol? [ and checksum SOLVED]