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 #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:

IRremoteESP8266/src/ir_RCMM.cpp

Lines 36 to 38 in a2228ed

	// Use a tolerance of +/-10% when matching some data spaces.
	const uint8_t kRcmmTolerance = 10;
	const uint16_t kRcmmExcess = 50;

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:

IRremoteESP8266/src/IRrecv.h

Lines 39 to 47 in a2228ed

	// How long (ms) before we give up wait for more data?
	// Don't exceed kMaxTimeoutMs without a good reason.
	// That is the capture buffers maximum value size. (UINT16_MAX / kRawTick)
	// Typically messages/protocols tend to repeat around the 100ms timeframe,
	// thus we should timeout before that to give us some time to try to decode
	// before we need to start capturing a possible new message.
	// Typically 15ms suits most applications. However, some protocols demand a
	// higher value. e.g. 90ms for XMP-1 and some aircon units.
	const uint8_t kTimeoutMs = 15; // In MilliSeconds.

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.