Open icheered opened 2 years ago
Your code looks fine.
An overrun error occurs if the receiver sees more than 68 edges so my first port of call would be to count them on your scope. It's possible that your remote is non-compliant or perhaps there is an issue with your decoder chip.
Another test that can be done if you have two micropython platforms and an IR emitter is to set one up as transmitter and the other as receiver.
The NEC protocol is widely used. I tested with a number of remotes and never saw this problem.
I'm having the exact same problem.
Is it possible to have both the receiver and sender on the same device? For my application I want the user to be able to send data, but sometimes also receive data. That's what I'm testing right now too, so maybe that is the problem?
@Theagainmen it is absolutely possible to have the sender and receiver on the same device (got it to work fairly reliably). I don't fully remember what the solution to this problem was but I do remember tinkering with the circuit before getting it to work. If you have the tools I would recommend hooking up an oscilloscope to check if the signal looks correct.
Thanks a lot for your quick response! Turns out I didn't have the ground properly connected...
It seems to receive the signal correct occasionally now! However, is it normal that it's spamming error messages all the time when there are no IR signals being sent?
Invalid start pulse (getting these the most)
Error: bad block (these sometimes)
Great! Yeah those messages pop up intermittently because of IR from other sources, that's nothing to worry about.
I also just remembered that the overrun error still pops up sometimes and my solution was just to send the information a few times consecutively (only takes a few ms anyways) to increase chance of correct delivery.
Following the example code on an ESP32 I get an "Error: overrun" every time I receive data but I don't know what causes this or how to prevent this error from happening. I am receiving data correctly confirmed using an oscilloscope. This issue happens using both NEC_16 and NEC_8.
Receiver code
Transmitter code for completeness (Works as expected as confirmed using oscilloscope).
What exactly is causing this issue? And how can I prevent it from happening?