search

peterhinch / micropython_ir

Nonblocking device drivers to receive from IR remotes and for IR "blaster" apps.
MIT License
240 stars 51 forks source link

ESP32: Trouble Receiving NEC when Wifi is Active #7

Closed adamoell closed 2 years ago

adamoell commented 2 years ago

Hi there - first of all, thank you so much for this brilliant library! I am, however, having a bit of trouble. I am trying to receive NEC codes on an ESP32 with a VS1838b receiver. The code works perfectly - until I connect the ESP32 to the Wifi. While the ESP32 is connecting to the access point, I get a handful of "Error: overrun" errors followed by a few dozen "Invalid start pulse" errors, even though no IR transmission is taking place. Once the Wifi is connected, I am unable to receive any NEC codes at all (every so often, I will get a slew of spurious "Invalid start pulse" messages).

I have tried the default pin (23) and a number of others - changing the pin made no difference. I've also tried running the ESP32 at different clock speeds (from the default 160MHz up to 240MHz), but this also didn't seem to make any difference either. It's almost like there is 'noise' on the GPIO pins caused by Wifi, or the Wifi is causing latency issues which mess up the reading of the IR pulses, but I lack the skill to investigate much more deeply. Do you have any ideas/suggestions? Potentially I could 'offload' the wifi stuff to a second board, maybe an ESP8266, and communicate via I2C, but that feels like an especially nasty hack. Any advice most gratefully received!

adamoell commented 2 years ago

I should have said - I am using the standard firmware esp32-20210902-v1.17.bin

adamoell commented 2 years ago

I have done a little testing with other firmware versions:

esp32-20210922-unstable-v1.17-68-g35fb90bd5.bin Successfully receives roughly 50% of sent NEC codes.

esp32-idf4-20210202-v1.14.bin When clocked at 240MHz, it's receiving roughly 90% of sent NEC codes. There are a number of "invalid start pulse" errors sprinkled in, even with no IR activity, and maybe one read in 20 seems to have the wrong address value, but it's close enough that I can work with this for now!

While this is great news for me, it looks like something has changed in the Micropython firmware causing a regression :-(. Any suggestions on tackling this would be much appreciated!

peterhinch commented 2 years ago

This implies that pin IRQ's are occurring on the input used by your receiver. The cause may be electrical.

I would investigate by connecting a pin to chip Gnd using a direct link - the absolute shortest wire possible. Then run the decoder specifying that pin as the input pin. Obviously you should never receive IR signals on that pin. Then run the WiFi. If you get errors the fault may be in firmware. If you don't, it points to hardware. It does always surprise me that anything works so close to a transmitting antenna. I can think of ways to approach this if it is hardware, but the first step is to determine whether it is.

adamoell commented 2 years ago

I think the problem was electrical - I had something else hooked to what was labelled GND on my board, but was actually CMD, and I think that was causing the weirdness. All seems to be working well now, thanks for your help. And thanks again for putting together this library!

peterhinch commented 2 years ago

That CMD pin has caused me trouble. It's too easy to read the silkscreen as Gnd.

adamoell commented 2 years ago

This is my first time with an ESP32, and my experience with ESP8266 boards conditioned me to expect a ground there... Such things are sent to try us!