Adafruit Neopixel library: Max. number of LEDs in one bitstream

Hello,

Im currently tracing the bitstream send from my photon to a connected 16x6 LED-Matrix. Im using a logic port to do so.
Does anyone know how many bits are send with the function

matrix.setPixelColor(led,r,g,b);

For example:

matrix.setPixelColor(0,8,0,0);
matrix.setPixelColor(1,9,0,0);
matrix.setPixelColor(2,10,0,0);
matrix.show();

sends the bitstream: (0000 1000 , 0000 0000 , 0000 0000) (0000 1001 , 0000 0000 , 0000 0000) (0000 1010 , 0000 0000 , 0000 0000)

after this bitstream for the first three LEDs there are a lot of zeros added automatically.
My question now is, how many of these zeroes are added? There are usually packets of 512 channels, is this the same here?

There is no predefined limit.
The final zero-packets are there to sync/terminate the transmission.

AFAICT the only limit is your RAM to hold the individual pixel’s data.

1 Like

@ScruffR Thanks! Can you think of a way to see the full bitstream? Unfortunately the buffer of my logic port is not big enough. Of course I can reduce the sample rate but that brings inaccuracy with it.

Without the correct tools (e.g. logic analyzer) that would be difficult.
But can you elaborate what you want to find, looking at the raw bit stream?

Yes I mean logic analyzer, logic port is just the devices name sry.
Im trying the find out how many led I can connect to my photon without a power limitation. And after that I want to find out how many led I can connect without falling under 25 fps at a given power input. I was hoping the see the whole bitstream and than simply count it but the devices buffer is not big enough to see the whole thing.

For that you wouldn’t need to know about the bitstream.
You can recon with 60mA per Neopixel full white brighness, so you cannot drive a single pixel off of a GPIO but need to supply 5V from an external source.
However for the control signal you won’t need to worry about the number of pixels as you only need to supply that signal to the first (and maybe second) pixel which will virtually draw no current. All subsequent pixels will draw from their individual predecessor.

Again, there is no connection between frame rate and power consumption. The only thing you need to consider is the time you need for the data train of a single pixel and multiply that by the number of pixels you want to control.
You’d usually update all pixels in one go.

That sounds interesting!
My approach was to find out how long the complete bitstream is and divide it with the delay time between two following led.
So for example I found out that my total bitstream of setPixelColour(0,8,0,0,0) (im using a RGBW-Matrix with ICs) is about 29.95 ms long from first to last bit. The time that the stream takes from one to another led is about 38 µs. So I thought that the total number of led i can use is 29.95ms / 38 µs what is about 788.
How do you think about that?

As for the Neopixel protocol itself you can take these figures to calculate the frame periode for x pixels

If I’m not mistaken this would result in a rough formula like this

Trgb  = x * 24 * 1.25µs + 50µs 
Trgbw = x * 32 * 1.25µs + 50µs

This would account for up to 1331 RGB pixels or 998 RGBW pixels at 25fps.

These are the best-case figures but the library implementation may add some latency you should allow for some safety margin.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.