Side Effects of NeoPixel Protocol Timing

Side Effects of NeoPixel Protocol Timing

I have a bunch of pi zeros that are no longer useful after I got them for a project that was supposed to go full open source, but to make a long story short, I’m just glad I only invested $20 in a few boards and not endless hours of my own time into the project.

Anyway, I decided to use one to script some pixels for lighting my desk (which I first used in my livestream with Anthony last week).  I was struggling to figure out why it was taking so long.  Sure Python is slow as dirt, but still, just filling a solid array took a long time.  I decided to try running it on a 3B+ and a 4 to see if what the difference would be. For the 182 RGBW pixel array on my desk: 14ms just to fill it with a solid color and no other math at all.  (10ms fastest time for just RGB)  running on a Pi 4.  (this took 50ms on the Zero and 20ms on a 3B+)

Then I started thinking about the protocol.  According to Adafruit, each RGB pixel takes 30us, plus 50us at the end of the array to signal the end of the update signal.  That means for a 120 pixel blade the minimum possible time to send the update is 3.6 milliseconds.  I also ran the numbers for the KR V1 strip, they require a whopping 8ms just to fill the strip, my 1800 pixel board requires at least 54ms.  To reiterate, that is the fastest theoretical time.  My python script that only fills the array then prints the time takes 100ms to fill the 1800 RGB array with a solid color, the calculated time is 54ms.

Depending on how everything is handled, that can have a pretty big impact on performance for the chip, the other logic required for your application, and even other peripherals.  That number doesn’t include the math required to handle the animations or anything, just for the time to send the update.

Leave a Reply