Irremoteesp8266: Adding Support for Carrier A/C 64-Bit

[wahibmichael]

Hello
I'm using the latest version of the library
\I'm trying to decode my AC remote using IRDUMPV2 I receive UNKNOWN protocol
each message is 66 Bit, and the RAW array Length is 132
I started to follow the troubleshooting guide to add basic support to the remote the guide say that I can be followed if the msg is <=64 bit.
how can I proceed further to add basic support?
NB. the A/C responds if I use SendRaw.
Thank in advance you are doing a great job over here :)

[wahibmichael]

Below is sample RAW data output

Timestamp : 000022.612
Library : v2.7.6

Protocol : UNKNOWN
Code : 0xE21A0A84 (66 Bits)
uint16_t rawData[131] = {8970, 4524, 504, 616, 534, 586, 534, 1704, 504, 616, 534, 586, 534, 586, 532, 586, 532, 1706, 504, 1736, 502, 616, 532, 1706, 504, 616, 532, 1706, 504, 616, 534, 1706, 502, 616, 532, 586, 534, 586, 532, 586, 532, 1706, 504, 616, 532, 1706, 504, 1736, 504, 616,
532, 1706, 504, 1736, 504, 1736, 504, 616, 504, 616, 532, 1708, 504, 616, 532, 588, 532, 586, 532, 588, 532, 586, 532, 588, 532, 1706, 504, 616, 532, 588, 520, 598, 504, 616, 532, 586, 532, 588, 502, 616, 502, 616, 502, 616, 502, 618, 502, 616, 504, 616, 502, 616, 504, 616, 504, 616, 504, 616, 504, 616, 502, 1736, 504, 616, 502, 616, 502, 616, 502, 616, 504, 616, 502, 616, 504, 616, 502, 1736, 504, 584, 504}; // UNKNOWN E21A0A84

Timestamp : 000025.278
Library : v2.7.6

Protocol : UNKNOWN
Code : 0x51655EA2 (66 Bits)
uint16_t rawData[131] = {9020, 4474, 534, 586, 534, 586, 534, 1706, 534, 586, 534, 584, 534, 586, 534, 584, 534, 1706, 534, 1706, 534, 586, 534, 1704, 534, 586, 534, 1704, 534, 586, 534, 1706, 534, 586, 534, 1706, 534, 586, 534, 586, 534, 1706, 534, 586, 534, 1706, 534, 1706, 534, 584, 534, 586, 534, 586, 534, 586, 534, 1704, 534, 586, 534, 1704, 534, 586, 534, 586, 534, 586, 534, 586, 534, 586, 534, 586, 534, 1706, 534, 586, 534, 586, 534, 586, 534, 584, 534, 584, 536, 584, 534, 586, 534, 584, 534, 584, 558, 562, 534, 586, 534, 586, 534, 586, 558, 562, 534, 586, 534, 586, 558, 562, 558, 1682, 534, 586, 532, 586, 558, 562, 558, 562, 556, 562, 558, 562, 558, 562, 558, 1680, 534, 554, 558}; // UNKNOWN
51655EA2

[NiKiZe]

Maybe #1112 can give you more information, both in regards to needed information, and the linked PR should show you some resulting data.

The issue template should have helped you to provide needed information.

With that said, using the analyse python script should give you a valid template even for >64 bit

[wahibmichael]

below the Python Script output

Found 131 timing entries.
Potential Mark Candidates:
[8968, 504]
Potential Space Candidates:
[4526, 1736, 618]

Guessing encoding type:
Looks like it uses space encoding. Yay!

Guessing key value:
kTestCarrierHdrMark = 8968
kTestCarrierHdrSpace = 4526
kTestCarrierBitMark = 503
kTestCarrierOneSpace = 1736
kTestCarrierZeroSpace = 615

Decoding protocol based on analysis so far:

kTestCarrierHdrMark+kTestCarrierHdrSpace+0010000110101010010001101100000000001000000000000000001000000010
Bits: 64
Hex: 0x21AA46C008000202 (MSB first)
0x4040001003625584 (LSB first)
Dec: 2425829139874316802 (MSB first)
4629700485713122692 (LSB first)
Bin: 0b0010000110101010010001101100000000001000000000000000001000000010 (MSB first)
0b0100000001000000000000000001000000000011011000100101010110000100 (LSB first)

Total Nr. of suspected bits: 64

[wahibmichael]

@crankyoldgit I Modified the code and now I'm able to decode the 64 bit
Protocol : TESTCARRIER
Code : 0x02020008747AAA21 (64 Bits)
uint16_t rawData[131] = {8940, 4556, 504, 616, 504, 616, 502, 1736, 504, 616, 504, 616, 504, 616, 502, 616, 502, 1736, 504, 1736, 502, 616, 504, 1736, 504, 616, 502, 1736, 504, 616, 502, 1736, 502, 616, 504, 616, 504, 1736, 502, 1736, 504, 1736, 502, 1736, 504, 616, 502, 1736, 502, 616, 504, 616, 504, 1736, 504, 1736, 504, 1736, 504, 616, 504, 1736, 502, 616, 502, 616, 504, 616, 504, 616, 502, 616, 502, 616, 504, 1736, 504, 616, 504, 616, 502, 616, 504, 616, 504, 616, 502, 616, 502, 616, 504, 616, 504, 616, 504, 616, 502, 616, 504, 616, 504, 616, 502, 616, 502,
616, 504, 616, 504, 616, 504, 1736, 504, 616, 504, 616, 504, 616, 504, 616, 504, 616, 504, 616, 504, 616, 502, 1736, 504, 586, 502}; // TESTCARRIER
uint8_t state[8] = {0x02, 0x02, 0x00, 0x08, 0x74, 0x7A, 0xAA, 0x21};

[wahibmichael]

I'll be working on Excel to reverse engineer the commands
at this point can I merge my Branch to add basic support for encoding/decoding?

[crankyoldgit]

Looking good. Yes, send us a Pull Request and we can get to work on cleaning it up and merging it.

I'd suggest using Google sheets rather than excel, as it makes it easy for others to see the latest changes etc.

[wahibmichael]

Created PR #1128
https://github.com/crankyoldgit/IRremoteESP8266/pull/1128

[crankyoldgit]

Just for the record and for future readers.

I'm trying to decode my AC remote using IRDUMPV2 I receive UNKNOWN protocol
each message is 66 Bit, and the RAW array Length is 132

Never believe/trust UNKNOWN's bit size or values.
Per: https://github.com/crankyoldgit/IRremoteESP8266/wiki/Frequently-Asked-Questions#my-remotes-signal-is-being-reported-as-an-unknown-code-what-does-that-mean-how-do-i-send-an-unknown-code

I started to follow the troubleshooting guide to add basic support to the remote the guide say that I can be followed if the msg is <=64 bit.

Turns out this protocol really is 64 bits. But, for protocols >= 64 bits, the script does produce code that often works for that, and the page in question does cover > 64 to some degree. I've changed the comment at the start to cover that fact.

[wahibmichael]

please create a new PR related to this issue where I can Commit changes

[NiKiZe]

please create a new PR related to this issue where I can Commit changes

Usually on github, you fork a repo, push to a branch, and then create a PR from there.
Githubs own documentation on the topic: https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/creating-a-pull-request

You have already created the fork, so it might just be an issue of you not pushing to the correct remote.

I can only guide you in shell mode, if you run git remote -v where you have your local IRremoteESP8266repo you are probably seeing something like:

> git remote -v
origin  https://github.com/crankyoldgit/IRremoteESP8266.git (fetch)
origin  https://github.com/crankyoldgit/IRremoteESP8266.git (push)

I hope that https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/configuring-a-remote-for-a-fork is helpfull for how to add you own fork as a remote.
when you have done that, you should be able to do something like git push newRemoteName, and from there you should be able to create a PR correctly.

Let us know if we can help you in any way with this.

[wahibmichael]

thanks for support please bear my ignorance I'm a noob 😃
PR Created, let me know if anything is wrong

[wahibmichael]

Sanity Check failed 😢

[wahibmichael]

Excel sheet with initial decoding
https://docs.google.com/spreadsheets/d/1EZy78L0cn1KDIX1aKq2biptejFqCjD5HO3tLiRvXf48/edit?usp=sharing

[crankyoldgit]

Excel sheet with initial decoding
https://docs.google.com/spreadsheets/d/1EZy78L0cn1KDIX1aKq2biptejFqCjD5HO3tLiRvXf48/edit?usp=sharing

Thanks for that. Looking at the data, we need to reverse the bit ordering. So that means all the values will change.

I saw your PR, and you seem to be tracking a branch that's quite old. I'm going to port your code to the latest version of the library and eventually abandon that PR.

[crankyoldgit]

@wahibmichael I've added Carrier 64 bit support in PR #1125 / branch https://github.com/crankyoldgit/IRremoteESP8266/tree/carrier40bit (don't let the name/url fool you, I've got another Carrier (40bit) protocol PR open as well)

Can you please download and test it out?
Note: Because I've changed the bit ordering compared to your version of the code and I'm not storing it in a state[] array, you'll need to recollect all the data in your spreadsheet.
However, this time the temperature numbers will actually increase when the temp increases. (That's how I know the bit order is correct)

Let me know how it goes and when you've got an updated version of the spreadsheet ready.

[crankyoldgit]

@wahibmichael Can you please also supply the Brand (Carrier I guess ;-) and the model number(s) for both the A/C unit and the remote?

[wahibmichael]

@crankyoldgit Thanks Super David for your help 🥰
I will download and test, will try to provide you a feedback today or tomorrow since I'm Celebrating my quarantine birthday today 🥳 😄

I noticed this issue in the excel sheet that bytes are reversed and I didn't know the reason for this since I used the state array results as is. I'm just curious was it an issue in the decoding, my code or it's the protocol properties?

@wahibmichael Can you please also supply the Brand (Carrier I guess ;-) and the model number(s) for both the A/C unit and the remote?

Unfortunately, It's an old unit, and the model label is washed out. tried to google lens the remote picture and I didn't get accurate results, will try to google it again

[crankyoldgit]

I noticed this issue in the excel sheet that bytes are reversed and I didn't know the reason for this since I used the state array results as is. I'm just curious was it an issue in the decoding, my code or it's the protocol properties?

See https://github.com/crankyoldgit/IRremoteESP8266/wiki/Adding-support-for-a-new-AC-protocol#determining-the-bit-order-of-the-protocol

The "order" is controlled by the MSBFirst parameter.
e.g.
https://github.com/crankyoldgit/IRremoteESP8266/blob/9e3c0943a28270b4980b1c2748572ff1c23a5382/src/IRsend.cpp#L273
https://github.com/crankyoldgit/IRremoteESP8266/blob/9e3c0943a28270b4980b1c2748572ff1c23a5382/src/IRrecv.cpp#L1102

You lost the 50/50 coin toss it seems. ;-)

Unfortunately, It's an old unit, and the model label is washed out. tried to google lens the remote picture and I didn't get accurate results, will try to google it again

Often the model info is under the access panel on the inside part of a split system. But either way, ... oh well.

[wahibmichael]

Hello Used the ir_Carrier_test.cpp to decode the results and it worked fine
below link to the updated excel sheet please have a look
https://docs.google.com/spreadsheets/d/1EZy78L0cn1KDIX1aKq2biptejFqCjD5HO3tLiRvXf48/edit?usp=sharing

I noticed something weird, in some modes(e.g. hot, cool, fan) only 1 Byte changes. is this normal?

[crankyoldgit]

Thanks for updating the spreadsheet.

I noticed something weird, in some modes(e.g. hot, cool, fan) only 1 Byte changes. is this normal?

In this case, yes. Based on the data you've supplied I think this protocol is only using half of the byte (a nibble) for a checksum, and the other half is the mode & fan settings data.

I'll try to write some code to break down the message into it's settings soon.

FYI, I've tried emulating sending messages with the 2.7.7 branch and it seems to detect/decode them fine. You've subsequently removed that comment/message from the issue. I assume everything is okay now?

[crankyoldgit]

FYI, the changes mentioned above have now been included in the latest release (v2.7.7) of the library.

[crankyoldgit]

@wahibmichael
[Q] Can the on & off timers be on/set at the same time? The data indicates its a possibility.

[Q] Do the timers still work/be set etc if you're in sleep mode? (The data for sleep & off time(r)) seem to overlap. So I'm guessing Off timer & sleep are incompatible).

[crankyoldgit]

@wahibmichael I've created PR #1133 & branch https://github.com/crankyoldgit/IRremoteESP8266/tree/carrier64

This should support all the features you've documented in your spreadsheet thus far.

Can you please download, try it out, & let me know if there are any issues?

[wahibmichael]

messages
Hello, yes I removed the comment because I used the IRrecvDumpV3 to decode and it didn't work, then I figured out that I have to use the ir_Carrier_test sketch and it works

Small modification on the ir_Carrier.cpp file I noticed the below comment in line 186-187
/// Decode the supplied Carrier 64-bit HVAC message.
/// Carrier HVAC messages contain only 64 bits, but it is sent three(3) times.

I think my protocol send only 1 time not 3 times.

[wahibmichael]

@wahibmichael
[Q] Can the on & off timers be on/set at the same time? The data indicates its a possibility.

[Q] Do the timers still work/be set etc if you're in sleep mode? (The data for sleep & off time(r)) seem to overlap. So I'm guessing Off timer & sleep are incompatible).

I tested the 2 cases and updated the excel sheet
https://docs.google.com/spreadsheets/d/1EZy78L0cn1KDIX1aKq2biptejFqCjD5HO3tLiRvXf48/edit?usp=sharing

• Seems we can we set both On & Off timers at the same time
• Sleep seems to override the Off timer with value 2, I tested the unit on sleep and it turns off after 2 hrs which confirms the dump

[crankyoldgit]

Cool, I'll look in the morning.
I'm really worried that IRrecvDump isn't working for you. Can I get you to please check V2 and V3 on the new branch? As far as I can tell, they should both detect and decode your real messages as is. If not, then that's a problem.

[wahibmichael]

Cool, I'll look in the morning.
I'm really worried that IRrecvDump isn't working for you. Can I get you to please check V2 and V3 on the new branch? As far as I can tell, they should both detect and decode your real messages as is. If not, then that's a problem.

IRrecvDump V2 & V3 are now working fine on the new branch, will be sending A/C commands, and providing feedback.

Mesg_Desc.: seems to be accurate in all cases, the only issue is that On Timer override the off timer, however, it seems they are independent based on the updated dump.
Thanks, fo your awesome support.

below sample message
Protocol : CARRIER_AC64
Code : 0x103000102C255584 (64 Bits)
Mesg Desc.: Power: On, Mode: 2 (Cool), Temp: 28C, Fan: 0 (Auto), Swing(V): On, Sleep: Off, On Timer: Off, Off Timer: Off
uint16_t rawData[131] = {8940, 4556, 504, 616, 502, 616, 502, 1736, 504, 616, 502, 616, 502, 616, 504, 616, 502, 1736, 502, 1736, 504, 618, 502, 1736, 504, 616, 502, 1738, 502, 616, 502, 1736, 502, 618, 502, 1736, 502, 618, 502, 1736, 502, 616, 504, 616, 502, 1736, 502, 618, 504, 616,
504, 616, 504, 616, 504, 1736, 504, 1736, 504, 616, 502, 1736, 504, 616, 502, 616, 502, 616, 504, 616, 504, 616, 504, 616, 502, 1738, 502, 616, 502, 618, 502, 616, 504, 616, 502, 616, 502, 616, 504, 616, 504, 616, 502, 616, 504, 616, 504, 616, 502, 616, 504, 616, 504, 616, 502, 616, 502, 1736, 504, 1736, 504, 616, 504, 616, 502, 616, 504, 616, 504, 616, 504, 616, 502, 1738, 502, 616, 502, 616, 502, 586, 502}; // CARRIER_AC64 103000102C255584
uint64_t data = 0x103000102C255584;

[wahibmichael]

Hello tested sending commands using Web-Ac-control.ino after some tweaks to work with ir_carrier.h
following functions work flawlessly

• turn on/off
• Fan Speed
• Temperature
• Mode

[crankyoldgit]

I've updated the branch to try to reflect more of those timer/sleep restrictions & conditions.

Thanks for confirming it's all working.

[crankyoldgit]

FYI, the code & changes referenced above have been included in the v2.7.8 release of the library.