Unable to decode MCE/RC6

[drebes]

I'm trying to decode some MCE/RC6 codes. However, IrScrutinizer leaves the decode field empty.

Here are some sample (raw) codes:

POWER TOGGLE (0x800F040C):
+2593 -927 +483 -369 +483 -368 +483 -818 +483 -810 +1281 -909 +483 -377 +482 -377 +483 -377 +494 -365 +483 -377 +483 -377 +482 -377 +483 -377 +482 -377 +483 -377 +864 -436 +483 -369 +482 -369 +483 -817 +483 -378 +482 -396 +463 -378 +482 -377 +863 -887 +481 -378 +482 -379 +481 -377 +482 -379 +481 -379 +861 -439 +482 -819 +481 -378 +482

WINDOWS (0x800F040D):
+2584 -927 +485 -368 +484 -368 +485 -816 +484 -830 +1288 -882 +486 -376 +484 -386 +474 -376 +484 -376 +485 -375 +485 -376 +484 -375 +485 -376 +484 -376 +484 -376 +897 -404 +503 -350 +484 -368 +484 -817 +485 -375 +502 -359 +484 -376 +485 -375 +897 -854 +484 -376 +484 -376 +485 -376 +484 -376 +484 -376 +897 -404 +485 -817 +897

Is it possible for IrScrutinizer to decode these?

[bengtmartensson]

It decodes for me:

MCE: {D=4,S=15,F=12}, beg=0, end=67, reps=1
MCE: {D=4,S=15,F=13}, beg=0, end=65, reps=1

Make sure you are using the current version; reset properties (File -> Set properties to default and restart).

[drebes]

I'm using the 2.4.0 release from Github (the macOS version) with default properties. I see a few commits since then, is there any minor release expected soon?

[bengtmartensson]

There is no release planned for the immediate future. However, this is not a major restriction, due to the continuous builds.

IrScrutinizer can decode your signals. I cannot reproduce your problem. How can I help you?

[drebes]

I did a bit more testing, and indeed I can decode those signal if I just start a new instance and paste & scrutinize those codes.

It seems that the decoder will fail if first I try to decode the following code, which belongs to another device and also fails:

0000 006D 0014 0000 0067 0023 0012 001F 0012 000E 0012 000E 0031 0033 0012 000E 0012 000E 0012 000E 0012 000E 0012 000E 0012 000E 0012 000E 0012 000E 0012 000E 0012 000E 0012 000E 0024 000D 0012 001F 0012 000E 0012 0CC5

After that, the MCE codes will not decode. Strangely NEC1, Sony20, etc codes will still decode.

[bengtmartensson]

It turned out that I, to my surprise, was able to reproduce, an it was a bona-fide bug, issue #496. Your signals from the first post were without explicit modulation frequency, so the frequency was (erroneously) take from the GUI, as left from previous activities. MCE has a frequency of 36000 (pretty low) which is more than frequency-tolerance away from the Pronto-Hex signal, but NEC1 (38400) and Sony20 (40000) are not.

Thank you for the contribution. I would be happy if you can confirm that it is now working (continuous build!).

[drebes]

Thank you for the fix. I confirm that with the latest continuous build it's working fine now.

And just for my own knowledge, do you know why the Pronto code above (copied below)

0000 006D 0014 0000 0067 0023 0012 001F 0012 000E 0012 000E 0031 0033 0012 000E 0012 000E 0012 000E 0012 000E 0012 000E 0012 000E 0012 000E 0012 000E 0012 000E 0012 000E 0012 000E 0024 000D 0012 001F 0012 000E 0012 0CC5

does not decode, but its equivalent RAW code

+2740 -860 +388 -909 +374 -476 +375 -476 +1362 -1281 +375 -476 +374 -477 +374 -476 +375 -476 +374 -477 +374 -476 +375 -475 +375 -477 +374 -476 +375 -476 +374 -476 +885 -409 +375 -922 +374 -476 +375

does? Is it because Pronto codes don't include an explicit modulation frequency?

[bengtmartensson]

It is supposed to be an RC6 signal. RC6 has modulation frequency 36000Hz, so a signal needs to be 36000 +- frequencytolerance to decode as RC6. Your Pronto signal is 38028 (enter 006D in Tools -> Time/Freuency Calculator), so it does not pass, using the default value of frequencytolerance (2000). A signal without explicit frequency is considered to be 38000, so it just passes.

You can also set frequencytolerance (Options -> Protocol parameters -> Frequency tolerance) to any suitable value, Setting it to -1 disable all frequency tests.