Edge was 69 vs 68

[dustinlacewell]

I was having great success with this library on a RPI Pico. However, I've switched to an ESP32-S2 Adafruit Feather in order to take advantage of its ESP-NOW features and I'm finding I just can't read from my IR sensor any longer. I'm using a KeyeStudio Digital IR Reciever Module.

https://learn.adafruit.com/adafruit-esp32-s2-feather/overview

https://wiki.keyestudio.com/Ks0026_keyestudio_Digital_IR_Receiver_Module

I've tired all sorts of pins. I've tried both my simple RC car NEC8 remote and my NEC16 Roku remote. In both cases, the edge length is always 69 instead of 68 and it fails to parse the messages.

Am I just simply out of luck due to using an ESP32 platform? I am experiencing this trouble when no wifi is in use.

[peterhinch]

I tested all protocols with the original ESP32 but not with the newer variants.

Reception is dependant on a pin interrupt being handled in a timely fashion: it's possible that the S2 isn't too good in that respect. When you refer to edge length I suspect you mean the count of edges which should always be 68 on the NEC protocol. I can't think why you're seeing an extra edge, especially as everything worked on the Pico.

As an outside chance you could comment out lines 23 and 24 on nec.py but this is a revolting hack which doesn't address the underlying issue. Failing that, I'm stumped at the moment.

[dustinlacewell]

I actually had tried that! It just reports bad data:

Bad data c8000000 addr=00 cmd=00
Bad data 000002ea addr=ea cmd=00
Bad data 00000002 addr=02 cmd=00
Bad data 0000000a addr=0a cmd=00
Bad data 0299c2ea addr=ea cmd=99
Bad data c80042ea addr=ea cmd=00
Bad data c899c2ea addr=ea cmd=99
Bad data 013002ea addr=ea cmd=30
Bad data cd3382ea addr=ea cmd=33
Bad data 0009c2ea addr=ea cmd=09
Bad data cd338580 addr=80 cmd=33
Bad data 8299c2ea addr=ea cmd=99
Bad data 00200402 addr=02 cmd=20
Bad data 0019c2ea addr=ea cmd=19
Bad data 05200002 addr=02 cmd=20
Bad data 001200ea addr=ea cmd=12
Bad data 2699c2ea addr=ea cmd=99
Bad data 91338580 addr=80 cmd=33
Bad data 8000840a addr=0a cmd=00
Bad data 0d3002ea addr=ea cmd=30
Bad data 000002ea addr=ea cmd=00

[dustinlacewell]

FWIW, thanks for making this library.

[peterhinch]

I've thought some more about this. The edge count of 69 simply means that there are > 68 edges. The receiver saves a tmestamp for every edge that occurs in a burst, analysing the result after the end of the burst. The array that stores the timestamps has a length of 69: the extra element exists so that overruns can be detected. The ESP32 might detect 100 edges in a burst yet it would still report 69 in the exception.

The detection of extra edges is puzzling. If the ESP32-S2 were slow in responding to interrupts I'd expect to see errors such as Bad data, yet this only happens when the overrun error is disabled. I can't think of a mechanism which would cause a platform to detect nonexistent edges.

My first port of call would be to suspect an electrical issue; alternatively to consider IR interference. It would be very interesting to put a 'scope or logic analyser on the pin used for reception.

[dustinlacewell]

In order to keep momentum on my project, I introduced a Raspberry Pico and am using it to drive the IR receiver. I'm sending the decoded presses to the ESP32 over PWM GPIO. On the Pico, the IR receiver behaves correctly, so I don't think it is interference, if I understand what you mean. I also ordered an IR receiver with an onboard NEC decoder which I'll try to move to when it arrives. Suffice it to say, we'll probably not need to puzzle this one all the way through, especially if you suspect it's a hardware issue anyway. I'll close this and reopen it if I need to revisit.

Thanks for your quick responses and I think your library is very handy. 🙏