yawor
commented
7 months ago Here's some more information regarding this issue. This is based on the analysis of IRremoteESP8266 library, which seems to be used (or some variant/fork of it) in the charging base.
The remote @bikeymouse tries to learn signals from is using a Pioneer protocol, which actually is one of the NEC family protocols. The command data is actually decoded correctly, as the structure of the data is the same in both protocols. What's not working correctly is that the signal is recognized as NEC (protocol 3), and not Pioneer (50). There is a really important different between implementation of both protocols: the way the command is repeated. NEC implementation sends the command only once and then sends short burst pattern repeatedly as long as needed, which receivers recognize as "repeat the last command". On the other hand, Pioneer implementation repeats the whole command sequence every time. Also Pioneer requires the signal to be repeated at least once (the library doesn't do that by itself though).
That's why changing 3;0xA55A48B7;32;0 which was recognized by the R2 to 50;0xA55A48B7;32;1 works, because this changes it to Pioneer protocol and also adds at least one repeat.
The problem is in how the signal is being recognized. The array of received timings is put through all of the decoders in some order and first that matches is assumed to be the correct one. This is OK in most situations, but not in all of them. Here the NEC is tried before Pioneer and is decoded correctly (which is true, as this is based on NEC). So Pioneer is never even checked. Changing the order is also not a proper solution because then all NEC signals would be recognized as Pioneer. The main issue is that the recognition is being done based on a single signal sequence, without listening to repeats and this is the what differentiates both implementations. This is something the IRremoteESP8266 is missing altogether.
There's also another difference between NEC and Pioneer protocols: modulation frequency. NEC uses 38.4 kHz and Pioneer uses 40 kHz. The difference is not much and the Pioneer receiver would still be able to accept NEC frequency, but it would be possible to differentiate both protocols based on that. But I assume that R2 charging base has only a single, demodulating IR receiver, so the ESP32 gets already demodulated data and doesn't know the modulation frequency of the received signal at all. It would require a second, non-demodulating IR receiver, which could be used to measure the frequency.
Here's an example of a device with both demodulating and non-demodulating IR receivers: http://www.harctoolbox.org/arduino_nano.html I've built one few years ago and this is really awesome tool to analyze what the remotes actually do (I use it together with IrScrutinizer open source software).
zehnm
bikeymouse
Is there an existing issue for this?
Description
I have a Pioneer VSX-S510 A/V system. When learning from the remote, it learns the codes fine (green light flahsing 2x) but it does not work. With the help of an expert on Discord we have found out that the RC2 learns the codes as being NEC code-set. Changing the first "3" to "50" in the Hex Codes and changing the "0" (# of times to repeat) to "1" makes the codes work.
See: https://discord.com/channels/553671366411288576/553671366927450123/1174837672024477761
How to Reproduce
Start IR learning a code for "mute" Code learned is: "3;0xA55A48B7;32;0" Test -> does not work Change code to "50;0xA55A48B7;32;1" Test -> does work!
Expected behavior
Learning with green light flashing should mean that code can be reproduced as being received.
System version
1.4.5
What part of the system affected by the problem?
Core
Additional context
No response