Need help: I am trying to decode one unknown protocol

[MarkEvens]

Version/revision of the library used

v2.8.2

Describe problem

I have one old carrier AC of the 2012 model, and the protocol remote is unknown, so I tried to decode it. Need help with decoding.

Spread sheet link

Images of Remote

[crankyoldgit]

Please follow the steps in the wiki for adding a new protocol: https://github.com/crankyoldgit/IRremoteESP8266/wiki/Adding-support-for-a-new-IR-protocol We will need to the complete capture (especially the RawData) from the IRrecvDumpV2 (or V3) program. Looking at the spreadsheet you provided, it looks like the data is in LSB format, but we will need to format it some more to make it useful.

i.e. In that wiki page, you don't have to proceed to the "Modifying the library ..." steps unless you want to.

[MarkEvens]

Hi, I added Raw data to the sheet, please check, You can ask me if required more data or anything.

[crankyoldgit]

Looking at the timing data provided, it's not like the other carrier protocols thus far, so we will have to write a new send/decode routine for it. I should have enough to go on to do that. I'll try to get to it soon. FWIW, it looks like there is 128 bits of data being sent in two packets with some inter-packet headers too. And the temperature seems to be stored in BCD format.

[MarkEvens]

Hey I did a mistake in fan speed capture, so I am correcting sheet wait for a little

[crankyoldgit]

@MarkEvens I've created the following branch: carrier128_basic / PR #1798 Please download that branch and try it out. It should send & detect the protocol now.

You will need to recollect/capture your spreadsheet data using that, as it changes the byte order of the state[] array/hex code representation.

In theory, if it works correctly you should now be at this stage: https://github.com/crankyoldgit/IRremoteESP8266/wiki/Adding-support-for-a-new-AC-protocol#analysing-the-data

Please note, we'd like you to test sending a state[] code to confirm the sending part works with a real device, and we also need the model info of the actual A/C unit please.

Let us know how it all goes.

[MarkEvens]

I test your brach It detects protocol as carrier128_basic, but it shows exact decoding no matter whatever command I am the fire.

It takes time to test with a real device, sorry for that I will let you know when it's done

[crankyoldgit]

I test your brach It detects protocol as carrier128_basic, but it shows exact decoding no matter whatever command I am the fire.

Can you please include an example? I.e. The full text from the dump program. As I'm not sure what you mean.

[crankyoldgit]

Chasing this up.

[MarkEvens]

Here is the received data using dump program for ON and OFF command

IRrecvDump is now running and waiting for IR input on Pin 19
Timestamp : 000003.516
Library   : v2.8.2

Protocol  : CARRIER_AC128
Code      : 0x16223800939125B811220800000000E0 (128 Bits)
uint16_t rawData[267] = {4604, 2610,  330, 424,  338, 994,  336, 998,  334, 422,  330, 1002,  328, 426,  336, 418,  336, 418,  334, 420,  332, 1000,  330, 424,  328, 426,  336, 416,  336, 996,  334, 420,  332, 422,  330, 424,  328, 426,  338, 416,  336, 996,  334, 998,  332, 1002,  330, 426,  338, 416,  336, 418,  336, 418,  334, 420,  332, 422,  330, 424,  328, 426,  338, 416,  336, 418,  336, 998,  332, 1000,  330, 424,  338, 416,  338, 996,  334, 420,  332, 422,  332, 1002,  328, 1004,  336, 418,  334, 420,  332, 422,  332, 1002,  328, 426,  338, 416,  338, 996,  334, 998,  332, 422,  330, 1002,  338, 416,  336, 418,  334, 998,  332, 422,  330, 424,  330, 424,  338, 416,  336, 418,  334, 998,  384, 950,  382, 952,  388, 366,  388, 928,  382, 20594,  4628, 6702,  9314, 4958,  356, 1002,  338, 418,  336, 418,  334, 420,  332, 1002,  330, 424,  338, 416,  336, 418,  334, 420,  334, 998,  332, 424,  330, 424,  338, 416,  336, 996,  334, 420,  332, 422,  330, 424,  328, 424,  338, 416,  336, 996,  334, 420,  332, 422,  330, 424,  328, 426,  338, 416,  336, 418,  334, 418,  366, 388,  364, 390,  362, 392,  360, 394,  358, 396,  358, 396,  368, 386,  366, 388,  364, 390,  362, 392,  360, 394,  360, 394,  358, 396,  368, 386,  366, 388,  364, 390,  362, 392,  360, 394,  360, 394,  358, 396,  370, 384,  366, 388,  364, 390,  362, 392,  360, 394,  360, 394,  358, 396,  368, 386,  366, 388,  364, 390,  364, 390,  362, 392,  360, 394,  360, 394,  358, 974,  336, 998,  332, 982,  338, 20638,  4624};  // CARRIER_AC128
uint8_t state[16] = {0x16, 0x22, 0x38, 0x00, 0x93, 0x91, 0x25, 0xB8, 0x11, 0x22, 0x08, 0x00, 0x00, 0x00, 0x00, 0xE0};


Timestamp : 000006.839
Library   : v2.8.2

Protocol  : CARRIER_AC128
Code      : 0x16223800939125B811220C0000000020 (128 Bits)
uint16_t rawData[267] = {4598, 2616,  336, 418,  334, 998,  332, 1002,  330, 426,  336, 996,  334, 420,  332, 422,  330, 424,  330, 424,  328, 1006,  336, 418,  334, 420,  332, 420,  332, 1002,  330, 424,  338, 416,  336, 418,  334, 420,  334, 420,  332, 1002,  328, 1004,  338, 996,  334, 420,  332, 422,  332, 422,  330, 424,  328, 426,  338, 416,  336, 418,  334, 420,  334, 420,  332, 422,  330, 1004,  338, 994,  336, 418,  334, 420,  332, 1000,  330, 424,  330, 424,  338, 996,  336, 998,  332, 422,  332, 422,  330, 424,  338, 994,  336, 418,  334, 420,  332, 1000,  330, 1002,  338, 416,  336, 996,  334, 420,  332, 422,  330, 1002,  328, 426,  336, 418,  336, 418,  334, 420,  332, 422,  330, 1002,  380, 952,  388, 944,  334, 420,  384, 930,  390, 20586,  4626, 6704,  9312, 4960,  406, 952,  336, 418,  334, 420,  332, 422,  332, 1002,  328, 426,  338, 416,  336, 418,  334, 420,  332, 1000,  330, 424,  328, 426,  338, 416,  336, 996,  334, 420,  332, 422,  330, 424,  328, 424,  338, 994,  336, 996,  334, 422,  332, 422,  330, 424,  338, 416,  336, 418,  336, 418,  334, 420,  332, 422,  332, 422,  330, 424,  358, 396,  368, 386,  366, 388,  366, 388,  364, 390,  362, 392,  362, 392,  360, 394,  358, 396,  366, 388,  366, 388,  364, 390,  364, 390,  362, 392,  360, 394,  358, 396,  366, 388,  366, 388,  364, 390,  362, 392,  362, 392,  360, 394,  358, 396,  366, 386,  366, 388,  364, 390,  364, 390,  362, 392,  360, 394,  358, 394,  358, 396,  366, 966,  334, 420,  332, 406,  338, 20636,  4626};  // CARRIER_AC128
uint8_t state[16] = {0x16, 0x22, 0x38, 0x00, 0x93, 0x91, 0x25, 0xB8, 0x11, 0x22, 0x0C, 0x00, 0x00, 0x00, 0x00, 0x20};

But there is all state are same

[crankyoldgit]

But there is all state are same

No. They are not both the same. uint8_t state[16] = {0x16, 0x22, 0x38, 0x00, 0x93, 0x91, 0x25, 0xB8, 0x11, 0x22, 0x08, 0x00, 0x00, 0x00, 0x00, 0xE0}; uint8_t state[16] = {0x16, 0x22, 0x38, 0x00, 0x93, 0x91, 0x25, 0xB8, 0x11, 0x22, 0x0C, 0x00, 0x00, 0x00, 0x00, 0x20};

[MarkEvens]

Yeah, it is different, But I am confused that When I capture all data using remote and analyse it by script, the first byte is constantly changing. So what is the explanation for it?

[crankyoldgit]

the first byte is constantly changing.

If you're looking at it in the wrong bit order, then the first byte will be the last (sent) byte. That is usually the checksum byte/value. See: https://github.com/crankyoldgit/IRremoteESP8266/wiki/Adding-support-for-a-new-AC-protocol#example-analysis & https://github.com/crankyoldgit/IRremoteESP8266/wiki/Adding-support-for-a-new-AC-protocol#check-bytes

Regardless, now that the library decodes it which your output appears to do, you need to do all of your analysis using the state[] codes. As per: https://github.com/crankyoldgit/IRremoteESP8266/wiki/Adding-support-for-a-new-AC-protocol#raw-data-should-no-longer-be-needed-now

[crankyoldgit]

FYI, that branch has now been merged into the master branch.

[crankyoldgit]

Just checking in. How are you going with this?

[crankyoldgit]

Friendly ping.

[crankyoldgit]

FYI, the changes mentioned above have now been included in the new v2.8.3 release of the library.