Irremoteesp8266: Carrier_AC40 Protocol issue

[wahibmichael]

Hello,
refrence to the below issue
https://github.com/crankyoldgit/IRremoteESP8266/issues/1112#issuecomment-628040377

I'm using V2.7.7 of the library
decoding my remote returns CARRIER_AC40 C05011C0E1, uint64_t data = 0xC05011C0E1;
which is protocol 83
I'm trying to repeat the same message to AC using the below command it is not working
irsend.send(CARRIER_AC40, 0xC05011C0E1, irsend.minRepeats(CARRIER_AC40));

I'm suspecting that the protocol doesn't use the normal carrier gap (kCarrierAcGap = 20000)

• how to get the correct CarrierACgap & how to receive the whole 3 messages in one Rawfubber? setting my kTimeout = kMaxTimeoutMs; let me receive 1 message is raw array.

-if I increased the kTimeout higher than 130ms will I be able to receive larger messages or there is a technical capping that it can't exceed 130ms?

Thanks in advance

[NiKiZe]

Just to be sure, Is your sending circuit working for any other device, such as a TV or similar? Did you follow the troubleshooting guide for this scenario?

Edit: the reason for asking is that pulling your hair out because it's not working when testing something new, and after several hours or days of frustration noticing that the issue was due to not setting the correct output pin... that is not uncommon. so actually verifying that the led sends signal and that it has correct power, is a really really good first step.

[crankyoldgit]

-if I increased the kTimeout higher than 130ms will I be able to receive larger messages or there is a technical capping that it can't exceed 130ms?

kTimeout doesn't affect receiving "larger messages", it more correctly deals with "larger gaps" between messages. i.e. A period of "no messages" for 130ms.

Yes, there is a technical issue capping kMaxTimeoutMs.
See:
https://github.com/crankyoldgit/IRremoteESP8266/blob/7c0e2d095f0b1a5922a9445897e65b4dc0b3249b/src/IRrecv.h#L37-L49

If you want to increase kMaxTimeoutMs you first need to increase kRawTickhttps://github.com/crankyoldgit/IRremoteESP8266/blob/7c0e2d095f0b1a5922a9445897e65b4dc0b3249b/src/IRrecv.h#L37

e.g. 3 would give you a maximum timeout of 196ms, 4 would give 262ms, etc etc.

The downside is you lose resolution in the timing values, which you probably won't notice till you hit a value of ~50.

[wahibmichael]

@NiKiZe same circuit is working perfectly for my Carrier_AC64, and working on other 3 A/C
@crankyoldgit thanks for the clarification, for the time being, I want to work with RAW data only so while setting kTimeout = kMaxTimeoutMs I receive the below raw dump while trying to repeat same Raw dump using sendRaw(sendarray, 100, 38) the device isn't responding, what cloud be the possible reason for that?
Note: The same send raw function is working for my other A/c.

uint16_t rawData[83] = {8378, 4218, 510, 1580, 510, 1580, 510, 534, 510, 534, 510, 534, 510, 534, 510, 534, 510, 534, 510, 536, 508, 1580, 510, 536, 510, 1580, 510, 534, 510, 534, 510, 536, 510, 534, 510, 534, 510, 534, 510, 534, 510, 1580, 510, 534, 510, 534, 510, 534, 510, 1580, 510, 1580, 510, 1580, 510, 534, 510, 534, 510, 536, 510, 534, 510, 534, 510, 536, 510, 1580, 510, 1580, 510, 1580, 510, 534, 510, 536, 510, 534, 510, 536, 510, 1580, 510}; // CARRIER_AC40 C05011C0E1
uint64_t data = 0xC05011C0E1;

[NiKiZe]

@NiKiZe same circuit is working perfectly for my Carrier_AC64, and working on other 3 A/C
@crankyoldgit thanks for the clarification, for the time being, I want to work with RAW data only so while setting kTimeout = kMaxTimeoutMs I receive the below raw dump while trying to repeat same Raw dump using sendRaw(sendarray, 100, 38) the device isn't responding, what cloud be the possible reason for that?
Note: The same send raw function is working for my other A/c.

Are you using the exact same code for the different devices? Or could there be a IO configuration missmatch or similar.
If it fails with raw as well then eighter the frequency might missmatch, or the IR wavelength might be incompatible. (both unlikely since CARRIER_AC40 have been working before)
Just verify that the LED is flashing with a camera when you send this command - it will save you loots of time to get that simple step over with.

[wahibmichael]

@NiKiZe yes I'm using the same code and Led is flashing I guess it's using normal 38khz frequency since I'm able to decode with this freq.
@crankyoldgit If the library receives same message 3 times, does it save only one of them in the rawfubber?

[crankyoldgit]

@crankyoldgit If the library receives same message 3 times, does it save only one of them in the rawfubber?

No. The rawData/buffer is everything it sees.

[crankyoldgit]

Raw dump using sendRaw(sendarray, 100, 38) ...

uint16_t rawData[83] = {8378, 4218, 510, 1580, 510, 1580, 510, 534, 510, 534, 510, 534, 510, 534, 510, 534, 510, 534, 510, 536, 508, 1580, 510, 536, 510, 1580, 510, 534, 510, 534, 510, 536, 510, 534, 510, 534, 510, 534, 510, 534, 510, 1580, 510, 534, 510, 534, 510, 534, 510, 1580, 510, 1580, 510, 1580, 510, 534, 510, 534, 510, 536, 510, 534, 510, 534, 510, 536, 510, 1580, 510, 1580, 510, 1580, 510, 534, 510, 536, 510, 534, 510, 536, 510, 1580, 510}; // CARRIER_AC40 C05011C0E1

Um, you're using 100 and the array is only 83 long.

You should be using sendRaw(rawData, 83, 38);

[crankyoldgit]

yes I'm using the same code and Led is flashing I guess it's using normal 38khz frequency since I'm able to decode with this freq.

Just because you can "decode" a signal with a 38kHz IR demodulator, it doesn't mean the signal was 38kHz. Hence, potentially trying different frequencies is worth a shot. e.g. 24kHz, 36kHz, 38kHz, 40kHz, 48kHz, & 56700Hz are frequencies we have seen before.

same circuit is working perfectly for my Carrier_AC64, and working on other 3 A/C

Physically exactly the same circuit/LED (as in you are using only one device to send) or the "same" circuit (as in a physical copy of the circuit. e.g. a second sending device)?

[wahibmichael]

Hello, I tested again to dump the remote code, pressing the power on button once send the same command twice, so why the Rawdata doesn't include both messages in the same buffer?

uint16_t rawData[83] = {8378, 4218, 510, 1580, 510, 1580, 510, 1580, 510, 1580, 510, 534, 510, 534, 510, 534, 510, 534, 510, 534, 510, 1580, 510, 536, 510, 1580, 510, 534, 510, 534, 510, 534, 510, 534, 510, 534, 510, 534, 510, 534, 510, 1580, 510, 534, 510, 534, 510, 534, 510, 1580, 510, 534, 510, 1580, 510, 534, 510, 534, 510, 534, 510, 534, 510, 538, 508, 532, 510, 1580, 510, 534, 510, 536, 510, 1580, 510, 534, 510, 534, 510, 536, 510, 1580, 510}; // CARRIER_AC40 F050114091 uint64_t data = 0xF050114091;

uint16_t rawData[83] = {8378, 4218, 510, 1580, 510, 1580, 510, 1580, 510, 1580, 510, 534, 510, 534, 510, 534, 510, 536, 510, 534, 510, 1580, 510, 534, 510, 1580, 510, 534, 510, 534, 510, 534, 510, 536, 510, 534, 510, 538, 506, 536, 510, 1580, 510, 534, 510, 534, 510, 536, 510, 1580, 510, 534, 510, 1580, 510, 534, 510, 536, 508, 536, 510, 534, 510, 536, 510, 534, 510, 1580, 510, 534, 510, 536, 508, 1580, 510, 534, 510, 534, 510, 536, 510, 1580, 510}; // CARRIER_AC40 F050114091

[crankyoldgit]

It would be because it's pickup up the protocol's normal/natural "repeat" as a second message. i.e. The repeat came in after the timeout had expired.
I'm guessing the gap between the end of the first message and the start of the second message is larger than the timeout value.

If you look at the timestamp value that IRrecvDumpV2 etc provides, it should give you and idea of how long it is between the two messages (in seconds)

[crankyoldgit]

Btw ...

irsend.send(CARRIER_AC40, 0xC05011C0E1, irsend.minRepeats(CARRIER_AC40));

You are using that function/method wrong. You're telling it to send a 40 bit Carrier message in only 2 bits. (min repeat for carrier 40 is 2)
See:
https://github.com/crankyoldgit/IRremoteESP8266/blob/84fed74830dfdb591ce477d80a194bd00644c11a/src/IRsend.cpp#L745-L753

You should use:
irsend.send(CARRIER_AC40, 0xC05011C0E1, kCarrierAc40Bits);
or
irsend.send(CARRIER_AC40, 0xC05011C0E1, kCarrierAc40Bits, kCarrierAc40MinRepeat);
or just:
irsend.sendCarrierAC40(0xC05011C0E1);

[wahibmichael]

1- same physical circuit works on other A/c
2- will try sending using other frequencies
3- the delay between each message as below is 215ms (and it's sent 3 times) so it's confirmed to be more than the timeout (if i set kTimeoutMs =1000 will I get the 3 messages in 1 buffer?)
4- tried to use irsend.sendCarrierAC40(0xC05011C0E1); didn't work and noticed that kCarrierAcGap = 20000; which means it repeats every 20ms not 215ms maybe I'm wrong in my calculations 😄

Timestamp : 000108.302
Library : v2.7.7

Protocol : CARRIER_AC40
Code : 0xC05011C0E1 (40 Bits)
uint16_t rawData[83] = {8378, 4220, 510, 1580, 510, 1580, 510, 536, 508, 536, 508, 536, 510, 534, 510, 536, 508, 536, 510, 534, 510, 1580, 510, 534, 510, 1580, 510, 534, 510, 534, 510, 534, 510, 534, 510, 534, 510, 536, 510, 534, 510, 1580, 510, 534, 510, 536, 510, 534, 510, 1580, 510, 1580, 510, 1580, 510, 536, 508, 536, 508, 534, 510, 536, 510, 534, 510, 536, 508, 1580, 510, 1580, 510, 1580, 510, 534, 510, 536, 510, 536, 508, 536, 508, 1580, 510}; // CARRIER_AC40 C05011C0E1
uint64_t data = 0xC05011C0E1;

mqttarray array =
Timestamp : 000108.517
Library : v2.7.7

Protocol : CARRIER_AC40
Code : 0xC05011C0E1 (40 Bits)
uint16_t rawData[83] = {8376, 4220, 510, 1580, 510, 1580, 510, 536, 510, 536, 508, 536, 510, 534, 510, 536, 508, 536, 510, 534, 510, 1580, 510, 534, 510, 1580, 510, 536, 508, 536, 510, 536, 508, 536, 510, 534, 510, 536, 508, 536, 510, 1580, 510, 534, 510, 536, 508, 536, 510, 1580, 510, 1580, 510, 1582, 508, 536, 508, 536, 510, 536, 508, 536, 510, 536, 508, 536, 508, 1580, 510, 1580, 510, 1580, 510, 536, 508, 536, 508, 538, 508, 536, 508, 1580, 510}; // CARRIER_AC40 C05011C0E1
uint64_t data = 0xC05011C0E1;

mqttarray array =
Timestamp : 000108.734
Library : v2.7.7

Protocol : CARRIER_AC40
Code : 0xC05011C0E1 (40 Bits)
uint16_t rawData[83] = {8376, 4220, 510, 1580, 510, 1580, 510, 534, 510, 536, 508, 536, 510, 534, 510, 536, 508, 536, 510, 536, 508, 1580, 510, 536, 508, 1580, 510, 536, 510, 534, 510, 536, 508, 536, 510, 534, 510, 536, 508, 536, 510, 1580, 510, 534, 510, 536, 510, 534, 510, 1580, 510, 1580, 510, 1580, 508, 536, 508, 536, 508, 536, 508, 536, 508, 536, 508, 536, 508, 1582, 508, 1580, 510, 1580, 510, 536, 508, 536, 512, 532, 510, 536, 508, 1580, 510}; // CARRIER_AC40 C05011C0E1
uint64_t data = 0xC05011C0E1;

[crankyoldgit]

1- same physical circuit works on other A/c

Thanks, we can rule that out as a possible problem.

2- will try sending using other frequencies

Looking forward to your results.

3- the delay between each message as below is 215ms (and it's sent 3 times) so it's confirmed to be more than the timeout (if i set kTimeoutMs =1000 will I get the 3 messages in 1 buffer?)

A timeout (with the appropriate tick time change) of something around 200+ should capture all three in a single rawData capture.
Summing all the numbers in each capture below, comes to around 67430us. (67ms), So 215ms - 67ms = ~149ms gap between messages. So you need a kRawTick of at least 3 to achieve that long a timeout value. i.e. 200ms-ish timeout is all you should need.

4- tried to use irsend.sendCarrierAC40(0xC05011C0E1); didn't work and noticed that kCarrierAcGap = 20000; which means it repeats every 20ms not 215ms maybe I'm wrong in my calculations 😄

That would be correct.
Try changing kCarrierAcGap to 150000 or use:

irsend.sendCarrierAC40(0xC05011C0E1, 40, 0);  // No repeat.
delay(150);
irsend.sendCarrierAC40(0xC05011C0E1, 40, 0);  // No repeat.
delay(150);
irsend.sendCarrierAC40(0xC05011C0E1, 40, 0);  // No repeat.
delay(150);

Let us know if that works. If it does, we can adjust the timings for the protocol.

[wahibmichael]

1- increasing rawtick to 3 did the trick for me now I'm receiving the 3 messages in one buffer and it's very clear from the dump that the delay between messages = 65535 +65535+ 17856 = 150ms

_Protocol : CARRIER_AC40
Code : 0xF050114091 (40 Bits)
uint16_t rawData[259] = {8379, 4218, 510, 1578, 510, 1578, 510, 1578, 510, 1578, 510, 534, 510, 534, 510, 534, 510, 534, 510, 534, 510, 1578, 510, 534, 510, 1578, 510, 534, 510, 534, 510, 534, 510, 534, 510, 534, 510, 534, 510, 534, 510, 1578, 510, 534, 510, 534, 510, 534, 510, 1578, 510, 534, 510, 1578, 510, 534, 510, 534, 510, 534, 510, 534, 510, 534, 510, 534, 510, 1581, 510, 534, 510, 534, 510, 1578, 510, 534, 510, 534, 510, 534, 510, 1578, 510, 65535, 0, 65535, 0, 17856, 8376, 4218, 510, 1578, 510, 1578, 510, 1578, 510, 1578, 510, 534, 510, 534, 510, 534, 510, 534, 510, 534, 510, 1578, 510, 534, 510, 1578, 510, 534, 510, 534, 510, 534, 510, 534, 510, 534, 510, 534, 510, 534, 510, 1578, 510, 534, 510, 534, 510, 534, 510, 1578, 510, 534, 510, 1578, 510, 534, 510, 534, 510, 534, 510, 534, 510, 534, 510, 534, 510, 1578, 510, 534, 510, 534, 510, 1578, 510, 534, 510, 534, 510, 534, 510, 1578, 510, 65535, 0, 65535, 0, 17856, 8379, 4218, 510, 1578, 510, 1578, 510, 1578, 510, 1578, 510, 534, 510, 534, 510, 534, 510, 534, 510, 534, 510, 1578, 510, 534, 510, 1578, 510, 534, 510, 534, 510, 534, 510, 534, 510, 534, 510, 534, 510, 534, 510, 1578, 510, 534, 510, 534, 510, 534, 510, 1578, 510, 534, 510, 1578, 510, 534, 510, 534, 510, 534, 510, 534, 510, 534, 510, 534, 510, 1581, 510, 534, 510, 534, 510, 1578, 510, 534, 510, 534, 510, 534, 510, 1578, 510}; // CARRIER_AC40 F050114091
uint64_t data = 0xF050114091;_

I introduced delay(150) between each message and it worked successfully, however, while trying to increase kCarrierAcGap I received the below complier warning since uint16_t can't accept more than 65535
I guess also a new parameter should be added kCarrierAc40Gap in order not to break the existing Carrier protocol

ir_Carrier.cpp:38:32: warning: large integer implicitly truncated to unsigned type [-Woverflow]
 const uint16_t kCarrierAcGap = 150000;

[crankyoldgit]

Change it to a uint32_t and it should be fine.
I'll create a formal patch for it later tonight. I'm busy all day today. Or @NiKiZe might create a branch for you to test before that.

Yes, we will create a new gap parameter for it so we don't break existing protocols.

[wahibmichael]

Thanks for your help and patience
is it possible to increase the kRawTick to 4 in further library release to be able to handle more complex protocols, or maybe a function to override the default kRawTick value

I understood that kRawTick is a factor to scale down the micors() to fit unit16_t probably to save ram while capturing the IR code, then it's scaled up again during display using the same factor (just a guess I'm very bad in coding :) )
irparams.rawbuf[rawlen] = (now - start) / kRawTick;
&
uint32_t usecs = results->rawbuf[i] * kRawTick;

so if we said that kRawTick = 4 we will lose resolution of 1us max from the current situation. In the current situation of kRawTick = 2, we already lose 1us resolution. so total resolution loss will not exceed 2us which I believe negligible for any IR protocol. ( just a guess :) )

[crankyoldgit]

A raw tick of 4 will cause the resolution to drop to 4us, not 2us.

Yes, that will probably not make much of a difference if it was the default.

My experience is that any message over 60+ms is pretty much a "new"/separate message. Eg. A Repeat.

Ideally the library would not swallow the repeat(s) into the same buffer as the first in the sequence.

Changing the library to allow setting the rawtick at runtime could easily be done, how ever it would make the code slightly bigger and slightly slower. It would also spend more time in the interrupt handler, which is something that should be avoided at all costs. Hence a compile-time option (the current situation) is best.

[NiKiZe]

This might become a bad hack, but an idea..
What if a timing value has the high bit set (that is 0x8000 I guess?) then the value is reduced by that value and taken by a value *10 or *100, since at that lever precision is not not needed?

This would break any raw value that has a value larger than that. and really is a hack. Is there any cleaner way that each value could have a "factor" to it

[crankyoldgit]

@NiKiZe FYI. There are a number of ways we could "encode" higher values into the rawbuf however most/all require processing during the interrupt handler. That means more time in the handler (time in there should be as short as possible) and more instructions that need to be stored in the IRAM which is a very limited resource globally on the chip. Every instruction we can save from being in IRAM, we do. i.e. If I could, I'd ditch the rawtick (2) factor just to reduce time/space, except there are protocols that require matching a timing over 65+ms. /shakesfist. ;-)

[crankyoldgit]

@wahibmichael Can you please download, test, and confirm the following works? Branch: https://github.com/crankyoldgit/IRremoteESP8266/tree/Issue1190 / PR #1193
It should have the correct 150,000usecs for the gap, and thus work.

[wahibmichael]

Thank you will test and confirm.

[wahibmichael]

Working Perfectly

[wahibmichael]

@crankyoldgit

A raw tick of 4 will cause the resolution to drop to 4us, not 2us.

maybe you are right I did some calculations it turns out that lost resolution is 3usec max.
Original us | divided by 4 | refactoring *4 | delta from orginal
-- | -- | -- | --
1 | 0 | 0 | 1
2 | 0 | 0 | 2
3 | 0 | 0 | 3
4 | 1 | 4 | 0
5 | 1 | 4 | 1
6 | 1 | 4 | 2
7 | 1 | 4 | 3
8 | 2 | 8 | 0
9 | 2 | 8 | 1
10 | 2 | 8 | 2

My experience is that any message over 60+ms is pretty much a "new"/separate message. Eg. A Repeat.

• totally agree with you that more than 60+ms is a repeat, but there are protocols that send the repeat after a value more than 130ms like in my case. and in this case, repeating the rawbuffer will not work automatically, unless we manually calculate the delay and create a function, or educate the user to increase rawtick manually, and probably after the next library updates his code will break if he is using rawbuffer to capture and send commands.

Changing the library to allow setting the rawtick at runtime could easily be done, how ever it would make the code slightly bigger and slightly slower. It would also spend more time in the interrupt handler, which is something that should be avoided at all costs. Hence a compile-time option (the current situation) is best.

• you are right introducing a function in runtime to modify the rawtick will add overhead to the interrupt operations

[crankyoldgit]

Rawtick has no effect on sending. Only receiving.

[joelgamal]

I am facing the same issue with Carrier 40 bits, I receive each message as 3 sperate ones. Changing const uint16_t kRawTick to 3 and 4 did not solve it, any suggestions please?

[NiKiZe]

any suggestions please?

@joelgamal
Post the output from DumpV2 (or later) so that we can have a look.

[wahibmichael]

h message as 3 sperate ones. Changing

Hi @joelgamal
make sure that you set kTimeout = kMaxTimeoutMs; and kRawTick = 3

[joelgamal]

I tried it again and it's working now. Sorry for any inconvenience and thank you for help

[crankyoldgit]

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