ESP32 Forum

Hello Everyone

As described by the title i try to do some "animations" with NeoPixels and a ESP32. They work perfectly fine and do exactly what expected and programmed.
I use the followint RMT-based library: https://github.com/marcmerlin/IoTuz/blo ... ws2812.cpp

Now, as soon as I use the WiFi there is flickering, as if the data gets corrupted.

I tried to use core-pinned task, prioritize them and changed various configs/timings. To no avail. As soon as the WiFi is doing more than idling the flickering starts.

Does this forum have any help fo me? What am I missing? Is WiFi using RMT? What channel?

Thanks already!

No, RMT and WiFi are entirely separate. Do you connect the Neopixels directly to the GPIO of the ESP32? If so, that may be your problem: the Neopixels are 5V and the signal level of 3.3V the ESP32 uses in that configuration is just marginal. Using WiFi may pull that 3.3V down to a level where the communication gets corrupted. Suggest using a level translator in that case.

Hy and thanks for your answer.

Yes, the NeoPixel get 5V.
Important to note is, that the pixels and the control of the pixels work flawlessly. We get way more than 60Hz and can do animations and whatnot. Everything is as it should be and as we wanted.
But as soon as we start using the wifi, some of the Pixels (it seems random which) change to another color (also seems random which color). Just very briefly and a redraw of the Pixels does help. What also helps is not to update the pixels, while the WiFi is active. But later is not an option for us.

So our problem really only appears when we use the WiFi and are doing a request/getting a response. Today we try to use an oscilloscope and see if we can see anything unusual in the signal for the pixels, while using WiFi. I keep you guys informed and if anyone else has a good hint, we'd appreciate it!

Cheers!

If possible, power your NeoPixels from 4V ~ 4.5V power supply, separate from ESP32 power supply.
Or, if using 5V power, use the silicon diode (1~10A rated) to lower the the voltage by 0.6V. It may be simpler than using the level shifter.

So we tried to power the NeoPixels from a completely different power source. We observed a stable voltage of 4,5V or 5V (depending on what we configured). Also the ESP32 has enough power (at least the voltage is stable).

We analyzed the signal directly on the GPIO-Pin and as well as after our "amplifier". They're identical (with different Voltages(3,3=>5V) and the timings are fine as well. With the help of the plugin we could verify that:
https://github.com/monkbroc/neopixel-saleae

We adapted the library, so we have a "static" buffer, in the sense that we don't allocate the buffer at runtime, to minimize possible memory-override issues. Didn't help. We tried different RMT-Flags/Options, but no changes.

But we definitely get wrong data on the signal. Timings are proper, correct, stable and we verified that.
A) at various places we can see different values (we expect the value 78, but get 64 or 14)
B) We have too much information, as in we still observe a signal with proper timings at the end of the last NeoPixel
C) We can even see wrong encoded data when we change the protocol. Timings change, but as they should with a change of NeoPixel protocol.

Remember we only and always get this wrong data when WiFi is active and under load.

We redraw with a refresh rate around every 33ms. The redraw takes around 2ms. Again without WiFi: Everything is perfect.

Our WiFi stack involves embdTLS and we do simple GET with a total length of <200Bytes(Request&Response). Could somewhere in the encryption/SSL/TCP components be a issue?

We're really out of ideas and options. We're planning on using a single core alone for controlling the NeoPixels (SW-Based) and drop the RMT-implementation, as we have currently no more ideas on what could cause the issue.

But as always: We greatly appreciate your support and help!

Could you see if in make menuconfig, under components -> mbedtls, any of the 'Enable hardware [something] acceleration' is enabled? If so, can you turn those off and retry?

Thanks for your input!

We tried various combination inclusive all turned on and off. Sadly no solution either.

Does this only happens when you call ws2812_setColors repeatedly?

Have you tried a different driver like https://github.com/MartyMacGyver/ESP32- ... ED-Drivers

Not sure if it helps or not, but I am using the RMT to control WS2812B while at the same time actively drowning the Wifi with data without issues.

To me it sounds as if you're suffering from an incomplete termination signal to the WS2812Bs. I had that problem in my driver and that resulted in very erratic failures.

You can see my GPL'd driver here:
https://github.com/PerMalmberg/Smooth/b ... RGBLed.cpp
https://github.com/PerMalmberg/Smooth/b ... d/RGBLed.h
https://github.com/PerMalmberg/Smooth/b ... edTiming.h

Did this ever get resolved?
I see the same issue, when sending MQTT, starting the sending just before, or during sending of RMT sequence (to drive ws2812 leds).
Waiting while sending the RMT sequence (e.g. rmt_write_items(..,..,..,..,wait =TRUE)) and then sending MQTT after shows no issues,
so it seems the MQTT logic (or underlying wifi) somehow interferes with the RMT timing.

With some debug gpio toggling in the interrupt handler, it seems that what is happening is that the RMT threshold interrupt is triggered too late, so the memory block/buffer isn't refilled on time. So I guess something in the wifi prevents the interrupt from being handled timely. Weird with 2 cores..
This wouldn't be a problem for 'slow' IR signals, but with the WS2812B fast timing, and the small RMT memory block size (only 64 pulses total), this becomes a problem