Neopixel Glitch Problem

All ESP32 boards running MicroPython.
Target audience: MicroPython users with an ESP32 board.
Post Reply
lagmoellertim
Posts: 2
Joined: Tue Mar 24, 2020 2:24 am

Neopixel Glitch Problem

Post by lagmoellertim » Tue Mar 24, 2020 2:43 am

Hey,

I am currently working on a wifi controlled LED project.
I'm using an ESP32-WROOM and SK6812 LEDs (with logic level shifter 3,3v->5v).

The Problem:
Example 1: https://streamable.com/ocxbj
Example 2: https://streamable.com/oxky0

I already discussed this topic with some people on reddit (post: https://www.reddit.com/r/arduino/commen ... 12_glitch/), but since no one there knew Micropython particularly well, maybe you have some other ideas.

The problem seems to be the wifi part.
When disabling the wifi, all glitches disappear, and vice versa. Since wifi is essential to my project, I can't just leave it away.

Here are some things I tried to fix it (none of those worked):
  • Different timing (more delay on Treset)
  • Loboris Fork (eventhough it uses RMT and should therefor be resistant against interrupts, ... , I'm experiencing the same glitches)
  • Selfwritten Neopixel RMT library (pure Micropython) -> way to slow and memory hungry, can't even control 50 leds without mem alloc errors

I don't know how to continue. Do you have any ideas on what to try or whether an official RMT Neopixel integration is planned?

Thank you!

User avatar
mattyt
Posts: 410
Joined: Mon Jan 23, 2017 6:39 am

Re: Neopixel Glitch Problem

Post by mattyt » Tue Mar 31, 2020 2:53 am

I'm afraid you've identified all the possibilities for now.

BTW, disabling wifi won't prevent the glitches but it does make them less likely to occur. MicroPython on the ESP32 is built on the ESPIDF which employs FreeRTOS; it interrupts the system periodically causing the timing glitches.

There are at least two promising alternatives in the pipeline:

1/ I have wanted to extend the current MicroPython RMT implementation to allow paged transmits - this would work around the memory issues with the current implementation (there should be no 'slowness' with the current implementation). It would do so using a process similar to double-buffering, send one page of data while preparing the next and repeat. Unfortunately I've been saturated with my day job for the past couple of months and I'm not sure when I'm going to get to this (happy to help others if they do have more bandwidth!).

2/ There has been some work to integrate FastLED which already employs a similar method to drive RMT. FastLED is a mature, rich but large library so I'm not sure what ramifications there are to pulling this in wholesale...

Hope that helps...

Post Reply