Neopixel "flicker"/noise only when Wifi is on
Port, board and/or hardware
esp32-C3 Mini
Matrix board like this https://www.hobbyelectronica.nl/wp-content/uploads/2021/11/8x8_WS2812_Led_matrix.jpg
with WS2812b Neopixels, all individual Neopixels have decoupling capacitors.
MicroPython version
MicroPython v1.24.1 on 2024-11-29; ESP32C3 module with ESP32C3
Reproduction
When Wifi is enabled and connected, a neopixel matrix (8x8) gives unexpected glitches.
Power and signal levels are checked and ok. (checked with an oscilloscope.)
This bug is the same as in https://github.com/micropython/micropython/issues/8161 however the fix will not work because the esp32-C3 Mini has only one core.
If this bug cannot be solved, I suggest adding a warning in the documentation that Neopixels on eps32 (single core types) cannot be used reliable when Wifi is on and used.
import time
from neopixel import NeoPixel # Standard lib of MicroPython v1.24.1
from machine import Pin
import config as cfg
import network
wlan = network.WLAN(network.STA_IF)
wlan.active(False)
ap_if = network.WLAN(network.AP_IF)
ap_if.active(False)
if not wlan.active():
wlan.active(True)
time.sleep_ms(100)
if not wlan.isconnected():
wlan.connect(cfg.ssid, cfg.passwd)
while not wlan.isconnected():
time.sleep_ms(100)
print('.', end='')
np = NeoPixel(Pin(4, Pin.OUT), 32) # Use 4 rows of 8 pixels
np.fill((0,0,0)) # All pixels off
np.write()
np[0] = np[8] = (1,0,0) # Red, lowest intensity
np[16] = np[24] = (0,1,0) # Green, lowest intensity
while True:
np.write()
time.sleep_ms(20)
The configuration of the pixels of this board is as follows:
0 1 . . . . . 6 7
8 9 . . . . . . .
16 etc.
So the example program above should give
R . . . . . . .
R . . . . . . .
G . . . . . . .
G . . . . . . .
Expected behaviour
First column (0) should be as above and steady
Observed behaviour
Only when Wifi is on and connected, glitches appear like for example:
R . . . . . . .
R . R . . . . .
G . G . . . . .
G . . . . . . .
or
R . . . . . . .
R . . . . . . .
G . G . . . . .
G . G . . . . .
The glitches always appear in column 2 (two pixels away from the first column)
and has the same color as the left one. I have not seen glitches in top row (0)
Additional Information
Conditions:
- Power supply (both 5 and 3.3Volt) has 100nF ceramic parallel with 470uF capacitors.
- Input signal of matrix module is within datasheet specs and look clean (Checked with oscilloscope).
- No long wires.
- No high currents (average current of the setup is below 50mA)
I checked the (total) time of the pulsetrain on the output of the esp with a oscilloscope, it shows 32 * 24 * 1.25uS = 960uS
This is as expected. However sometimes the pulsetrain is extended an extra 60uS.
This is probably when the glitches appear.
I also did the test with all 64 pixels (total time of pulstrain 1.92mS, column 0 -> RRRRGGGG) then also sometimes the extra 60 uS appear. Also parts of (bottom of) column 0 is copied to column 2 like above.
I have tested this with a few esp32-C3 and a few matrix boards. They all have the same behaviour.
I also tried using machine.bitstream but the same behavior shows up.
Code of Conduct
Yes, I agree
ESP32 neopixel library not working properly
Port, board and/or hardware
ESP32
MicroPython version
V1.25
Reproduction
compile for the ESP32 port using the generic ESP32 board setting the board variant to SPIRAM.attach neopixels to ESP32 and start up the neopixel library and simply fill the buffer with a single color and see if the colors of the neopixels get set to what you have set them to in code. Then repeat the same test except don't set the board variant at all.
Expected behaviour
I expect the neopixel colors to be set correctly no matter what the board variant is set to.
Observed behaviour
If I compile MicroPython setting the board variant to SPIRAM the neopixel library doesn't set the colors correctly when using the neopixel library. if I don't use the board variant then it works fine.
Additional Information
I believe the issue is actually upstream in the ESP-IDF but the problem there is MicroPython is using deprecated code in the ESP-IDF for the RMT. I believe that updating the code in the machine_bitstream.c source file to use the new version of the RMT in the ESP-IDF will more than likely solve the issue.
I am working on doing that now and I will let you know the outcome.
Code of Conduct
Yes, I agree