Site icon josh.com

NeoPixels Revealed: Getting physical to uncover PWM Secrets

This is Part 2 in a series. Read Part 1 here.

 

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

Getting physical with a NeoPixel

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…

LED output at minimum brightness (0x01)

…and at half brightness of 0x80…

LED output at half brightness (0x80)

…and finally full brightness of 0xFF…

LED output at full brightness (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…

A lucky latch with very short latency

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.

Almost worst case of >1500ns of latency between latch and display

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…

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.

Exit mobile version