I stuck a photo-detector on a NeoPixel to get an insider’s look at exactly how they do their PWM…

Looking at the photo-detector output on a scope at a 500us timescale, the PWM of the LED shows up perfectly – it is running at about 500hz (~2ms per cycle).

Here is the LED showing the lowest brightness of 0x01…

…and at half brightness of 0x80…

…and finally full brightness of 0xFF…

 

We can see that the LED is never continuously on. Even when the color is set to full brightness, the LED still turns off for about 100us at the end of each PWM cycle. This means that there will always be some flicker with a Neopixel, although nothing noticeable to human eyes.

This PWM clock runs independently from the data coming in. This has some practical consequences. It means that there is up to ~2ms of jitter between when you latch new data and when it actually shows up on the LED. Here are a couple of extreme examples…

Here we see the LED come (top trace) on almost immediately after the data stops (middle trace). We just got lucky that the PWM cycle was ending just as we finished sending data.

This time there is delay of >1.5ms (1,500,00ns!) between the end of the data and the LED lighting up. We just missed the end of the previous PWM cycle and so had to wait for the next one.

There is no practical way to avoid this jitter. Some implications include…

• the shortest flash you can make with a NeoPixel is ~2ms. This rules out using an array of NeoPixels as a high-speed strobe flash.
• if you try to show a frame of pixels for less than 2ms, there is a real chance that you might completely miss a PWM cycle and they will never actually be displayed at all. This practically limits your maximum frame rate before frames start getting dropped.
• since each pixel has a free-running PWM clock,. there will always be up to ~2ms of time between resets when some pixels in the same string will be displaying new data while others are still displaying old data. This could cause problems like motion tearing and dithering if you take a photo of a changing Neopixel display using a 1/500 second or shorter exposure time.

So now we can detail exactly a frame refresh works…

1. Every time the data signal falls from high to low, a countdown timer starts. The data line going from low to high stops the countdown.
2. About ~6us after the reception of the last bit, the countdown timer expires and the newly received color data is latched into an internal buffer.
3. At the end of the next asynchronous  PWM cycle (which could be anytime in the next ~2ms), the chip grabs the data from the buffer and starts displaying it on the LED.

FAQ

Q: Couldn’t I use a photo-detector or current probe to lock into the PWM clock and then make sure my data always ends just before the next PWM cycle starts?
A: Keep in mind that every pixel has its own independent PWM clock and they are all free-running and all have different periods due to manufacturing and environmental differences. So you probably will only be able to get your data to be optimally timed for a single pixel in the string.

There is an easier way to drive NeoPixels using code that…

1. is simple to understand
2. easy to change without breaking
3. allows indefinitely long pixel strings
4. addresses the root cause of signal reshaping glitches
5. needs only a trivial amount of memory regardless of string length

Here is a demo of a 1,000+ pixel string being driven by a vintage Arduino DueMillinove at about 30 frames per second…

Continue reading →