I am now working on my first large scale installation for a local festival:
2M diameter ring with 2x 6M LED strips WS2815 144LED/m on each side (i setup WS2812 setting since there is no WS2815)
Total 2x6M = 12M strips / 1440 LED (720/ring)
Power injection at start and end of each strip (3M per injection) = no issue at all
Data cable running through the whole 12M (to run the 2 rings independently from 1 Pixelblaze)
I thought the PB could handle 1440 pixels easily (i was reading 48000 pixels, but oh boy I didn’t RTFM correctly (PER SECOND)). I have less than 6-10 fps with 1440 LED… However, it advertises 800 led max at >30fps. It does not.
I have 12-24 fps MAX with 720 pixels with most of the patterns, particularly the sound reactive ones that’s i’m looking to use. The simple ones (intro to PB, chaser…) can go to 26-29 fps, not above.
Data speed setting for the LED strip is 800 kbps / CPU is at 240 Mhz (max).
I’m a bit disappointed to be honest, i’m very far from the super smooth effects I had with my 171 LED wearable.
I can accept to reduce functionality and run the 2 rings with parallel data lines (synchronized) to reduce the pixels to 720, but even this is not enough to reach a proper framerate (>30-40fps), particularly for sound reactive.
What kind of solution should i look at ?
Can it be due to the quality of my LED strip not transmitting data fast enough ? I’d rather avoid to change it.
A second Pixelblaze to run the second half of the strips (360 LED), but how do i manage patterns rotating 360°C around my ring with 2 PB ?
Would the output expander even help on this ? I would need to setup 1 end of each strip (basically 360 LED) on 1 output, but then it would mean the index of each LED segment would start from the extremity of the ring, and I have no idea how i can then run a pattern of LED rotating at 360°.
In this configuration I’d have index 1->360 on the first half of the ring, then 720->361 back to the start. Would i solve this with mapping ?
You are likely hitting two constraints affecting fps.
The first is that an 800kbps LED has a data rate limitation of about 33k pixels a second with standard 24 bit rgb pixels. That’s a theoretical fps limit of 23 fps for 1440 LEDs just to get the data out.
The next is the cpu rendering, and how this works with ws2812 compatibles with the current driver. The 48k pixels a second is average for the shipping patterns. That gives a theoretical average fps around 33 for 1440 pixels. But the ws2812 driver doesn’t pipeline (yet). So rendering and data happen sequentially. What you have is a frame that takes 1/33 seconds to render then 1/23 seconds to send. Adding these gives you about 13fps. 1/(1/33 + 1/23). Again, that’s a gross average for the shipping patterns, some would be slower, and some should be faster but no faster than the data would allow.
The current best/easy way to get around both issues is to throw in an output expander. The expander has a data rate around 66k pixels a second and allows Pixelblaze to pipeline rendering. You’d need to split up the LEDs into at least 2 parts, and drive each from an expander output, effectively doubling the pixel data rate of the system. Plus the expander driver allows Pixelblaze to pipeline render again, and you’d most likely be limited only by the cpu rendering, getting 33 fps on average with a max around 45.
Past that adding more pixelblazes and further splitting up the LEDs would help. I’d still use expanders, otherwise two PB would only get you around 26 fps. With expanders and two PB you’d get average around 66 with max of 90 fps.
Some more good news for you, I’ve recently been rewriting all of the drivers and have a pipelined ws2812 that can render in parallel, and would bump up the single PB (no expander) system with 1440 LEDs to 23 fps, often limited by the data bandwidth, and 46 for two PBs with that split up. Not as good as a pair of PBs with expanders but might fall within your requirements.
I can get you a beta build with the new driver if you want to give it a spin.
Once again, fast and clear answer ! Great support !
From what I see, the easiest solutions are:
try the new beta drivers (but i’d still be capped at 22 FPS max due to strip limitations): i’d still like to try, can you send it to me ? I can provide feedback on it if you want
buy an output expander (how does it manage to double the bitrate at 66K, isn’t it a limitation of the LED chip to be at 800 kb/s ?)
Addtionnal question: you’re talking about pipeline rendering, and i see the output expander is “buffering” data. How does it work delay-wise ? Can it create a delay in how the Pixelblaze reacts to sound ? At the moment I can see that for example with 1440 pixels running (around 10 fps), i have a massive lag between sound and the pattern reaction.
I have found that for any sound patterns, if you want it to look picture perfect, you have to be plugged into the 3.5mm jack. Using the mic is fine for patterns that are augmented by sound, but you’ll see a delay if you’re wanting precise effects.
I’m using it with the jack, it works perfectly. To be fair even with the microphone it’s sync enough, the delay is barely noticeable.
But when I start to run over 500 led, the FPS can’t catch up with it and I observe a massive delay, whatever the pattern I use (I use mostly the stock ones for this). That’s why I want also to be able to run my LED in a smooth way.
Hopefully the modified drivers will prove enough, else I’ll have to go for the output expander (even though I don’t understand how it’s able to handle 66,000 led considering the 33,000 looks like a strip limitation (800kb/s).
Just to clarify, the current spec is 5000 LEDs max without an output expander, and 51,200 LEDs max using one controller with 8 output expanders having exactly 800 WS281X LEDs on each of the 8 outputs on an expander. A single Pixelblaze can have up to 8 output expanders in parallel on a single output bus from a controller. With the WS281X protocol speed problems subdivided by these 64 output channels, you would expect to see the controller calculating 48 Kpixels / second, which comes out to 48,000 / 51,200 = .9 frames per second.
The use case for something in the 1 FPS range like this is not animations. Imagine ambient lighting that changes colors extremely slowly, or reacts to ambient light, or is programmed for time-of-day on/off. Most of James Turell’s pieces that change color do so very slowly, and this could be used for something like that.
Another factor that hasn’t been mentioned so far is that many people are using SK9822s (APA102 protocol) LEDs. They’re significantly faster. While WS281X protocol pixels are limited to 800KHz, which comes out to 33k pixels per second max as mentioned above, the SK9822s can typically run 2MHz - 12MHz, with the max usable pixel transmission clock speed depending on the physical length and number of pixels. With an output expander, 3500 SK9822 LEDs spread across the 7 channels of an output expander would certainly be able to run at a very high protocol clock speed, and thus the 48 Kpixel / controller is the speed constraint you’d hit before the serial protocol is the limiting factor. In that case I’d expect about 48,000 / 3500 = 13 FPS.
In fact, I tried setting that up on a real controller and that’s exactly what I got (13.1 FPS for “Fast Pulse”, 10.3 FPS for “color twinkle bounce”, 12.2 FPS for “sound - rays”, 7.6 FPS for “matrix 2D honeycomb”).
The recent wireless sync features are the best way for people to get above the typical overall 48 KPixel/sec rendering speed. By subdividing the rendering load between multiple controllers, you can scale up and see better frame rates on large installs. In my last example, dividing the 3500 pixels between three controllers that are in sync mode, I’d expect around 3X the FPS for each of those measured.