I’m planning on controlling 13000 WS2812 LEDs using 3 ouput expanders and a Pixelblaze V3. From the online documentation this seems to be possible as three output expanders can drive 38008=19200 leds. However, I am wondering how many pixel updates per second I can then expect using a PixelBlaze V3 to make a judgement on whether the update speed is sufficient or not. I am guessing the update speed also depends on the pattern used but a general indication would be nice. So my questions are the following:
Could I get an indication of the amount of pixel updates per second possible using this setup, so how many times I could update the entire length of 13000 pixels per second?
How could this update rate be improved? E.g. would adding more ouptut expanders help without increasing the amount of LEDs or should I use multiple PixelBlazes?
This question has come up a few times in the past. Here’s some good threads with estimation tools and info for V3.
The TL;DR is I’d expect 2.3-5 FPS on the pixel generation side with a single Pixelblaze V3. For a trivial pattern that could exceed 5FPS, you’d then be limited by the output expander’s 2Mbps serial line speed. When running 3 expanders off of one serial line, this should also cap you to about 5FPS.
Using multiple Pixelblaze, or wiring sections of the install with symmetry in parallel (as mentioned in the first link), is the best way to start getting more FPS. In my experience, this should scale nearly linearly until you start hitting your next limit, such as WS2812 timing (33 Kpix/s per strip) or 2Mbps serial = 66 Kpix/s per expander.
A Pixelblaze V3 generates 48Kpix/s on average. If you wanted to get to 30FPS, that’s 13000 pixels * 30FPS = 390Kpix/s. 390K / 48K = 8 Pixelblaze V3. I’ve had good experiences with the ease of synchronizing multiple Pixelblaze using the free Firestorm stuff on a laptop or Raspberry Pi.
Hope this helps! That’s a LOT of LEDs! What are you cookin up?
Thanks for your quick and insightful response! I see I should have done my research a bit better because these threads help a lot indeed.
Especially Firestorm seems like a brilliant way to increase the amount of frames per second so I will definitely consider that.
13000 is indeed a lot of LEDs, they will decorate a large fountain so their quantity is absolutely neccessary :). This means they will also need a relatively complex mapping, do you have any thoughts on whether this would reduce the framerate significantly? I don’t really think so since the mapping seems to be computed only once and stored in a large array but please correct me if I’m wrong.
With that many LEDs, sounds like the perfect case for using multiple PBs, where a single map is used for all of them.
Example (simple, your case is more complex)
PB 1: 2000 LEDs, but map has those 2000 plus extra phantom pixels to define the corners of the entire total field of pixels
PB 2: 2000 LEDs, but map has those 2000 plus extra phantom pixels to define the corners of the entire total field of pixels
PB 3: 2000 LEDs, but map has those 2000 plus extra phantom pixels to define the corners of the entire total field of pixels
PB 4: 2000 LEDs, but map has those 2000 plus extra phantom pixels to define the corners of the entire total field of pixels
So you’d have 4 PBs, 8000 pixels but let’s imagine each is one quarter of the total…
And you draw a ball of light circling around…
Each PB is calculating the same ball, but at any given time, 2-3 of them don’t have pixels that will be lit up, since the results will be “off their map” (it’ll still be within the 0…1 range on each axis)
Make sense?
You’d have to use firestorm synced timing, and perhaps a seeded random that generates the same “random” on each PBs so they match up.
Okay, then I will still assume the 48Kpix/s as the Pixelblaze V3’s speed in this scenario. I will most probably end up using 4 Pixelblazes and 4 output expanders to end up at approximately 15FPS (Pixelblaze V3 limited) which sounds good.
just came across this, as I was reviewing older posts looking for code…
In your case, having 13000 pixels in each map/PB might be too much… but the goal is the same number of pixels, I think, so the CPUs are working with about the same amount of data each render cycle… so 13000/4 is roughly ~3000+ pixels, but do try to at least keep equal amounts on each PB…
You’re going to have to play with timing to get it to work right. Again, non-trivial # of pixels, so the syncing of multiple PBs on that scale will take some work/experiments. Keep us in the loop.
13K pixels in a 3D map will definitely push a few limits. The map would be 78k of coordinate data which has to sit in memory. There might be enough RAM, but I would’t recommend it.
What I’d recommend for something this large and going with the extra pixels method would be to have a few extra marker pixels (in the map only), just enough to keep the map coordinates scaled to the larger world, so it doesn’t normalize to the single subsection’s coordinate space.
I do not recommend setting the pixel count to 13k on each subsection. It is unnecessary to keep multiple PBs in sync for time() based patterns.
@LEDCreate, Some animation methods in some patterns do not lend themselves to parallelization across a Firestorm of Pixelblaze, which relies on synchronized animation time bases. KITT is an example of a pattern that doesn’t use time(), and instead uses the relative passage of time with delta and incremental calculations in beforeRender(). In cases like that, Firestorm/timesync can’t keep them synchronized.