Neopixel timing out of spec

General Discussion
1

Basic Information:

Printer Model: Voron 2.4
MCU / Printerboard: Spider + Mellow SB2040
klippy.log doesn’t apply

Describe your issue:

I’m currently converting my Voron to CAN and stumbled upon a problem with the Mellow SB2040 toolhead board and an attached Neopixel chain. The first LED randomly lights up in the wrong color and can’t be controlled by “SET_LED”, the others won’t work at all. Everything else attached to the SB2040 is just working fine.

After ruling out wiring errors, i checked the Neopixel drive signal with a scope and found the timing to be out of spec. Looked into the source code (neopixels.c) and found the same wrong values there:

#define PULSE_LONG_TICKS nsecs_to_ticks(650)
#define PULSE_SHORT_TICKS nsecs_to_ticks(200)

According to the WS2812 data sheet, this should be 700 and 350 (+/-150), for the WS2813 it should be 750~1000 and 300~450.
The following change did work for me:

#define PULSE_LONG_TICKS nsecs_to_ticks(800)
#define PULSE_SHORT_TICKS nsecs_to_ticks(350)

but someone should probably verify this for other MCUs.

On why this obviously wrong code has been working for many people, my best guess is that some MCUs are just inaccurate enough and/or some Neopixels are tolerant enough.

1 Like
2

Unfortunately, there is no meaningful specifications for the neopixel chips. Dozens of different chips were manufactured and various specifications were released with contradictory information. If I recall correctly, the values chosen in the source came from reports of other software developers that had run tests on various real world devices.

-Kevin

1 Like
3

Just reporting that I had the same issue and fix. This should be fixed to work with the standard LEDs used today. WS2812 family is one.

image
image712×562 49.7 KB

4

If you alter only PULSE_SHORT_TIME to 300ns does it still work?

#define PULSE_LONG_TICKS  nsecs_to_ticks(650)
#define PULSE_SHORT_TICKS nsecs_to_ticks(300)

-Kevin