IRForum

Hi All,

I need some help in figuring out the checksum of my signal. I am a total newbie at this so I apologize if I don't use the exact technical words

So far I have been successfully reading and transmitting the signals using AnalysIR however I'm a bit stuck trying to reverse engineering the signal.

My first exercise I did was just switching on and off the unit while changing the temperature from 16 to 30. While I did manage to identify the bits that are switching on and off the unit, I'm still stuck on how the checksum is being calculated. Also another strange thing I observed (apart from the 67 bit signal which is odd..at least in my newbie opinion) is the fact that the third byte changes state as soon as I hit the 24 degrees...also it seems that the last byte is changing constantly as I increase the temperature...still not sure about the first byte...again when I reach 24 degrees starts again from hex 20. I have seen in your form of another person trying to decode a gree unit similar to mine which has a 67 bit signal but not sure if he succeeded.

I tried using the checksum calculator as instructed in one of your videos (by ignoring the last byte...also did several tests on separate frames) however could not match the checksum (if present) in my hex. Can you please look at my session file (attached) and if possible give me some guidance on where to start to figure out how the checksum is being calculated.

Thanks in advance for your support.

Hi David

Yes this particicular protocol seems to be puzzling everyone wrt checksum.

We have spent a lot of time on this without success.

Some tips:
- record the signals & only change one parameter at a time
- e.g. increasing the temp only one degree at a time, will give you the best basis to work with.
- if possible start with a setting that has a checksum value of zero and then change parameters from there to see how it evolves (like the ON_27 signal in your image)
- Because this is 67 bits it is not on an 8 bit or 4 bit boundary & so is a lot more difficult than most.
- look out for values that are not included in the checksum calculation
- if calculating XOR or SUM the starting position may be non-zero
- LSB8 seems like a reasonalbe format to work with, but you cannot be 100% sure because of the uneven 67 bits.

Other than that, best of luck wit this tricky one. If we had an actual remote it would be a lot easier for us to troubleshoot.

do post back if you get any success with this.

In case anyone is interested, this has been resolved in the followin post:

viewtopic.php?f=5&t=544

Hey guys, in previous post it was mentioned, that checksum issue has been resolved but i haven't found here https://github.com/ToniA/Raw-IR-decoder-for-Arduino the correct way to make a proper checksum for Gree IR signal, so i reverse engineered it. Don't know if that's the same algorithm they use for all models, but i think it might be useful for somebody.

The only problem i have that it doesn't work in 100% of cases(like i have to send signal multiple time for AC to receive it) but i think it might be due to timings being slightly off, tbh i was hoping somebody could give me an advice on that regard

So the signal is structured this way: first 22 bits are the info you want to send:

AC mode 3 bits; power on/off 1 bit; fan mode 2 bits; swing on/off 1 bit, sleep on/off 1 bit; temperature 4 bits; timer 8 bits; turbo on/off 1 bit, led lights on/off 1 bit;

(reversed) then there is a fixed part of a signal you send after, it consists of 13 bits:

0001000001010010 (see line 109 in gree.cpp)

then there is a space approx 20000 microseconds (see line line 123 gree.cpp)

and after that the checksum or tail is generated from this info. It's 32 bit long and has only one bit that is set to 1 on every occasion i tested

0b00000000000001000000000000000000
or
0x00040000

Last four bits depend on temperature you're trying to set, ac mode and power on/off. It's actually the temperature bits, but they are taken from a LUT and index of the temperature is shifted depending on ac mode(see line 29 gree.cpp). So for example you want to send 16C, ID in LUT would be 0, let's say the mode is COOL so the shift would be SHIFT_COOL(which is 3), so the LUT id is 3 now.. There are also temperatures that ignore that rule and just require plan 1111 in the end(see line 73 gree.cpp).


If you have swing on. then this mask has to be added to checksum:
0b10001000000000000000000000000000
or
0x88000000

and temperature shifting also changes if id of temperature from LUT equals TEMP_RANGE(line 53 gree.h), for that see line 76 and the way unique_temp_shifted_id is calculated.

Now if you want to send a power off signal, you need to flip the last bit.


That is pretty much it, but i haven't tested timers at all since i didn't need them and auto mode might be wrong, but it worked on a brief testing.

source code:
gree.cpp : http://pastebin.com/U8WcXFHn
gree.h : http://pastebin.com/KVMB4WuB

data i obtained from my remote:
reference-binary : http://pastebin.com/ccXRB9pH
cross-reference : http://pastebin.com/bnShmMcJ

I haven't documented data much, but if you know what you're looking for you'll probably find it in there.

Hi Gavlig

Yes, it is a particularly difficult protocol.

The soloution is discussed in this thread: viewtopic.php?f=5&t=544

If you have a registered copy of AnalysIR, I can send you the new settings, which make it easier using the checksum calculator & reverse engineering tool.

Finally, thanks for posting your info as well.

Hello, no, i don't have a copy of AnalysIR, it was just a hobby project i might never come back to again so i don't think i'll need special tools for that. Though who knows, maybe later.

As i said earlier, i couldn't find the checksum generator in that thread, that's why i posted my code (though i admit i can be blind and it was right there but i missed it somehow).
I think my endgoal was for somebody to check if that works and let me know if they would have the same problems as I do.

sorry if this board is not an appropriate place for that

The other thread has a link to a full spec for the Gree protocol (on the second page of the thread).

Of course you are welcome to post on this forum...no problem.


The checksum calculator I mentioned is only within the AnalysIR windows application.

Thanks again for your input and for posting your work.

yep, i'm blind indeed. Thank you! I'll dig into that spec now!

My guess was right, timings were slightly off, got correct ones from this library https://github.com/ToniA/arduino-heatpu ... atpumpIR.h