Irremoteesp8266: A Carrier Remote send raw data 3 times (similar, not inverted) with 20 ms between them, IRrecvDumpV2 detects them as 3 separate signals, any help?

[joelgamal]

I changed kTimeout to many values including 130ms which is the max, still the same. I am using v2.7.0 and also tried v2.7.6.
I am using nodeMCU v2 with KMS803 and also tried TSOP1738

[crankyoldgit]

As per the issue template you removed. And the troubleshooting guide, I'll need the raw data. Can you cut and paste it all here. I then have a chance/hope of helping you.

[joelgamal]

Timestamp : 000279.009
Library : v2.7.0

Protocol : UNKNOWN
Code : 0xBCF4730D (42 Bits)
uint16_t rawData[83] = {8428, 4188, 506, 1560, 530, 1584, 506, 1584, 504, 1584, 506, 516, 528, 516, 528, 538, 506, 514, 530, 538, 506, 538, 506, 1558, 530, 1582, 506, 514, 530, 538, 506, 1560, 530, 512, 532, 540, 506, 538, 506, 538, 506, 1584, 506, 514, 530, 516, 530, 1584, 506, 512, 532, 1584, 506, 1558, 532, 540, 504, 538, 506, 538, 506, 538, 506, 538, 506, 538, 506, 1560, 530, 1558, 530, 1584, 506, 1560, 530, 538, 506, 1558, 530, 516, 528, 514, 530}; // UNKNOWN BCF4730D

Timestamp : 000279.230
Library : v2.7.0

Protocol : UNKNOWN
Code : 0xBCF4730D (42 Bits)
uint16_t rawData[83] = {8402, 4166, 562, 1550, 538, 1526, 562, 1552, 538, 1524, 566, 504, 538, 504, 540, 480, 564, 506, 538, 506, 538, 506, 538, 1550, 538, 1550, 540, 506, 538, 506, 538, 1550, 538, 506, 540, 478, 564, 480, 564, 506, 540, 1550, 538, 506, 540, 506, 538, 1524, 564, 506, 538, 1550, 538, 1550, 538, 482, 562, 482, 562, 506, 540, 504, 540, 482, 562, 506, 538, 1550, 538, 1550, 540, 1524, 564, 1526, 564, 480, 564, 1528, 562, 504, 540, 480, 564}; // UNKNOWN BCF4730D

Timestamp : 000279.450
Library : v2.7.0

Protocol : UNKNOWN
Code : 0xBCF4730D (42 Bits)
uint16_t rawData[83] = {8428, 4190, 506, 1558, 532, 1584, 506, 1584, 506, 1584, 506, 514, 530, 538, 506, 538, 506, 514, 530, 538, 506, 538, 506, 1560, 530, 1558, 530, 514, 530, 512, 532, 1584, 506, 540, 504, 516, 530, 538, 506, 538, 506, 1558, 530, 514, 530, 512, 530, 1562, 528, 514, 530, 1560, 528, 1560, 528, 538, 506, 538, 506, 514, 530, 538, 506, 538, 506, 538, 506, 1584, 506, 1584, 506, 1584, 506, 1560, 530, 538, 506, 1558, 530, 538, 506, 540, 504}; // UNKNOWN BCF4730D

[crankyoldgit]

Good news & Bad news.

First, the bad. This isn't a Carrier protocol we've seen before. That is why it is not detecting it as that and behaving the way it is. Our existing Carrier protocol is 32 bits long, this one is 40 bits.

The good news. Those three messages are a single message, and two repeats of exactly the same message. There is nothing broken with the library and kTimeout.

If you're a good enough C/C++ programmer, you can add support yourself by following:
https://github.com/crankyoldgit/IRremoteESP8266/wiki/Adding-support-for-a-new-IR-protocol
It's easily understandable by our tools.
e.g.

$ cat /tmp/t3
uint16_t rawData[83] = {8428, 4190, 506, 1558, 532, 1584, 506, 1584, 506, 1584, 506, 514, 530, 538, 506, 538, 506, 514, 530, 538, 506, 538, 506, 1560, 530, 1558, 530, 514, 530, 512, 532, 1584, 506, 540, 504, 516, 530, 538, 506, 538, 506, 1558, 530, 514, 530, 512, 530, 1562, 528, 514, 530, 1560, 528, 1560, 528, 538, 506, 538, 506, 514, 530, 538, 506, 538, 506, 538, 506, 1584, 506, 1584, 506, 1584, 506, 1560, 530, 538, 506, 1558, 530, 538, 506, 540, 504}; // UNKNOWN BCF4730D
$ tools/auto_analyse_raw_data.py -f /tmp/t3
Found 83 timing entries.
Potential Mark Candidates:
[8428, 532]
Potential Space Candidates:
[4190, 1584, 540]

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

Guessing key value:
kHdrMark   = 8428
kHdrSpace  = 4190
kBitMark   = 516
kOneSpace  = 1570
kZeroSpace = 529

Decoding protocol based on analysis so far:

kHdrMark+kHdrSpace+1111000000110010000100101100000011110100
  Bits: 40
  Hex:  0xF03212C0F4 (MSB first)
        0x2F03484C0F (LSB first)
  Dec:  1031632240884 (MSB first)
        201918532623 (LSB first)
  Bin:  0b1111000000110010000100101100000011110100 (MSB first)
        0b0010111100000011010010000100110000001111 (LSB first)

Total Nr. of suspected bits: 40

[joelgamal]

Thank you so much for your reply. I am already working on adding support to this protocol, but what I need to modify to be able to detect IR signal as one message not 3 separate ones? I have changed kCarrierAcBits inside IRremoteESP8266.h to 40. When decodeCarrierAC method checks if raw data length equals to 251 [which is 83(single msg)* 3 (repeats) + 2 (one space between each repeat)], it returns false as signal received is only 83

[crankyoldgit]

Got a link to your code so far on github? Or elsewhere?

If you look at the existing decodeCarrierAc() length check:
https://github.com/crankyoldgit/IRremoteESP8266/blob/09d9ed2a4c9e2d5ed4b18198b9ef7524be3e1379/src/ir_Carrier.cpp#L68-L69

You can probably use similar. i.e. nbits should be 40 in your case. However, it's looking for 3 "messages"/sections as they form a check of sorts. i.e. Normal + Inverted + Normal. Hence the * 3.

  if (results->rawlen < ((2 * nbits + kHeader + kFooter) * 3) - 1 + offset)
    return false;  // Can't possibly be a valid Carrier 40 bit message sequence (3 messages).

(2 * 40 + kHeader(2) + kFooter(2)) * 3 - 1 == (80 + 2 + 2) * 3 - 1 == 84 * 3 - 1 == 251

That will only work if you've got a kTimeout value that's > 20 msecs. e.g. 90 catches all the protocols I know of. ;-)

Or ...
If you want it to work with the default kTimeout is 15 msecs. (FYI, It's adjustable at runtime when you create the IRrecv object.)

You can just look for the first message in the sequence of three (3) messages. This is what happens for most protocols with simple repeats.
e.g.

  if (results->rawlen < 2 * nbits + kHeader + kFooter - 1 + offset)
    return false;  // Can't possibly be a valid Carrier 40 bit message.

2 * 40 + kHeader(2) + kFooter(2) - 1 == 80 + 2 + 2 - 1 == 83

[crankyoldgit]

I have changed kCarrierAcBits inside IRremoteESP8266.h to 40.

FYI, that won't work. The timings are slightly different, and your protocol is sending the same message a total of 3 times.
The sendCarrierAc() protocol sends it once as normal, then once inverted, and then once normal again.

The existing decoder also checks this "inverted" message to confirm it's a real Carrier (32 bit) message.

Oh, and as you are having trouble with kTimeout, how & where are you setting/changing this?
and how are you creating the IRrecv class object?
e.g.
https://github.com/crankyoldgit/IRremoteESP8266/blob/09d9ed2a4c9e2d5ed4b18198b9ef7524be3e1379/src/IRrecv.cpp#L129-L144

[crankyoldgit]

@joelgamal I've created PR #1125 which should add decode and sending support for your 40bit Carrier messages.
Can you please download & test the following branch and let me know how it goes for you?
https://github.com/crankyoldgit/IRremoteESP8266/tree/carrier40bit

Until you collect a range of temperature data, the bit ordering may be subject change. e.g. the bits may get reversed, and the numbers all change.
i.e. Your now basically up to this step/stage: https://github.com/crankyoldgit/IRremoteESP8266/wiki/Adding-support-for-a-new-AC-protocol#determining-the-bit-order-of-the-protocol

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

[joelgamal]

First of all, I really thank you for your effort in writing and supporting this library,
1- I tested the branch and it detects the protocol.
2- Previously using the existing decoder (with bits = 40), I removed "inverted" message check and still not detected
3- I changed kTimeout in IRrecvDumpV2 to 15, 50, 90 and 130 and still not detected
4- For IRrecv I did not make any modification, Should I?

[crankyoldgit]

First of all, I really thank you for your effort in writing and supporting this library,
1- I tested the branch and it detects the protocol.

Excellent!

2- Previously using the existing decoder (with bits = 40), I removed "inverted" message check and still not detected

I'm not sure why, but as I can't see your code, I could only being to speculate.

3- I changed kTimeout in IRrecvDumpV2 to 15, 50, 90 and 130 and still not detected

Assuming you did it correctly, it should do it. Again, without seeing exactly what you did, I can't tell.

4- For IRrecv I did not make any modification, Should I?

Modifying that existing protocol was probably not going to work. Anyway, you've now got a decoder that works, and you can move onto the next stage which is trying to work out what bits control what, and what the correct bit ordering is. i.e. Check the temperature range.

I'll re-ask this again:

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

[joelgamal]

Brand: Carrier, It's an old one so nothing written on the remote itself and I try to find A/C model but not sure if it is possible
const uint8_t kTimeout = 50; this is the variable I changed inside IRrecvDumpV2

[crankyoldgit]

Check inside the battery compartment too.

re: kTimeout, that seems correct.

[crankyoldgit]

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