RCMM Decoding is not working consistently

[cjkarande]

Version/revision of the library used

v2.8.6

Describe the bug

One of my STB remotes uses the Nokia24 RCMM protocol. I tried decoding it using both 38khz (TSOP1738) as well 36khz (TSOP31436) IR Receivers. However, the results are not consistent.

Sometimes (once in 10 times) it decodes correctly Correct Decode: DecodeType: 21 Bits: 32 IRCode: 26002709

At all other times, for the same button it gives DecodeType: -1 Bits: 18 IRCode: B01556B3 dumpIRCode: Unknown encoding: 2954188467B01556B3 (18 bits, overflow: 0)B01556B3

Raw (36): 436 -260 184 -260 184 -594 184 -428 184 -592 184 -260 236 -208 210 -210 182 -286 208 -234 210 -570 184 -426 184 -760 184 -260 210 -234 186 -592 184 -426 210

Also, the correct decode works only when you hold the remote far off and use it in reflective mode i.e. Remote emitter pointing away from the IR Receiver like towards my body. Sometimes it works if I hold it below the desk at a specific level below the IR receiver (I know it sounds weird :D )

To Reproduce

Trying decoding with any remote with RCMM protocol (I am using Airtel STB remote).

Expected behaviour

The library to decode RCMM IR signals consistently

Output of raw data from [IRrecvDumpV2.ino]

Correctly Decoded Output Timestamp : 000041.049 Library : v2.8.6 Protocol : RCMM Code : 0x260027C1 (32 Bits) uint16_t rawData[35] = {440, 254, 216, 228, 216, 560, 216, 396, 216, 562, 216, 228, 214, 230, 214, 230, 214, 230, 214, 206, 210, 592, 212, 398, 212, 730, 214, 730, 214, 232, 212, 232, 212, 400, 210}; // RCMM 260027C1
uint64_t data = 0x260027C1;

Incorrect Decode Output for the same button Timestamp : 000052.808 Library : v2.8.6 Protocol : UNKNOWN Code : 0xB560852B (18 Bits) uint16_t rawData[35] = {440, 254, 216, 228, 216, 560, 216, 394, 216, 560, 240, 180, 238, 230, 214, 230, 214, 230, 214, 206, 210, 590, 214, 398, 212, 730, 214, 732, 212, 230, 212, 232, 212, 400, 212}; // UNKNOWN B560852B

What brand/model IR demodulator are you using?

38khz (TSOP1738) as well 36khz (TSOP31436) IR Receivers

I have followed the steps in the [Troubleshooting Guide]

Yes

Has this library/code previously worked as expected for you?

The library works perfectly fine for all 38khz protocols

Other useful information

Linking this issue to an earlier issue https://github.com/crankyoldgit/IRremoteESP8266/issues/21

[crankyoldgit]

It looks like your UNKNOWN signals are only ever so slightly out of the expected range for that protocol.

Try tweaking these values: https://github.com/crankyoldgit/IRremoteESP8266/blob/a2228ed9dcc1e9ef9aaee5f5bb89f03b72a26758/src/ir_RCMM.cpp#L36-L38

That should hopefully get you a more reliable detection.

[cjkarande]

Thank you @crankyoldgit. Do you recommend to increase or decrease the values?

FYI, yesterday tried to reduce kTimeout from the default 50 to 5. That helped me improve detection to some level like with holding the remote below the table. Should I reset it back to 50 before adjusting kRcmmTolerance & kRcmmExcess ?

Also, is kRcmmExcess getting used in the code? I tried searching for its references. If not I can leave it as is.

[crankyoldgit]

I'd slowly increase the tolerance value (kRcmmTolerance). The least amount you increase it and still get reliable detection is best.

You're correct. kRcmmExcess is an artifact that isn't used anymore. I'll remove it.

[cjkarande]

What do you recommend for kTimeout should I reset it back to 50? Also, will kTolerance play any role in this tunning? Saw it getting used in IRrecvDumpV2 code

[crankyoldgit]

What do you recommend for kTimeout should I reset it back to 50?

See: https://github.com/crankyoldgit/IRremoteESP8266/blob/a2228ed9dcc1e9ef9aaee5f5bb89f03b72a26758/src/IRrecv.h#L39-L47

Also, will kTolerance play any role in this tunning?

Yes, you can adjust this at runtime too. See IRrecv::setTolerance()

RCMM is very susceptible miss reading the value if the tolerances are too high. Most protocols only have 1 bit per "pulse", and the values (High & Low) are quite far apart, value-wise. RCMM encodes 2 bits per pulse. So it has to be broken down into 4 distinct ranges, so if the tolerance is to high, the potential for overlap is greater and it can parse the wrong value out of the signal. The use of it's own fixed tolerance is an attempt to limit that damage or posibility.

[cjkarande]

Now I get it. Thanks a ton for the detailed note, appreciate your support.

Will try out your recos and update you accordingly.