Hi! I’m working on a 2,080 pixel (8 rows of 260) staff with WS2812, 3.7v lithium power and a mapped cylinder (thanks Scruffynerf).
I’m at 10% brightness and have tried various data speeds but I’m getting less than smooth display and random freeze. Have I reached the outer limits of the controller? Any and all advice more than welcome!
Here’s a video in case that helps:
Hi!
@Wizard can probably tell you more, but I’m thinking at at 2000+ LEDs, you might possibly be seeing voltage drop problems, but what’s limiting your frame rate is the amount of time it takes to send data to the LEDs. (Unless you’re using an output expander or some other method of driving the LEDs in parallel – if that’s the case, ignore this!)
It’s been a while since I did the calculation, but I remember the generally accepted transmit time per WS2812 pixel is about 30 microseconds. So, doing absolutely no per-pixel calculation, you could drive 1000 WS2812s at around 30fps. That means the absolute max frame rate for 2000 is 15fps. Any work your pattern does to calculate pixel values is going to drop the frame rate pretty fast.
Love the staff, btw – I’m about to start building one too. Is that lexan? It looks great!
Thanks @zranger1. It’s a 1” ID tap plastic acrylic tube with some laser cut strip channel rings surrounding…will have batteries in the center and another acrylic tube 1.75” ID over the inner tube. I do have a channel expander so this may be the right time to dust it off and give it a try.
Hi @JerryB,
WS2812s have a few disadvantages over apa102. They have a fixed data rate, which can limit FPS, and they require either buffering or streaming out with a half-speed data rate (further limiting FPS for lots of LEDs). A single string of 2080 WS2812 LEDs have hard limit around 15 FPS (like @zranger1 mentioned). 800kbps / 24 bits per pixel = 33k pixels/sec assuming no downtime spent calculating pixels.
The other bottleneck is that Pixelblaze V2 can only pump out so many pixels a second. Here are rough numbers:
Pixelblaze V2 can generate between 12,000-45,000 pixels per second.
I hope that helps explain where you may be hitting a problem, but perhaps more helpful would be what you can do to boost FPS!
Try both buffered and unbuffered WS2812 options. Unbuffered has half the output data speed, but can pipeline data and rendering.
The output expander could help with bandwidth and slightly offload Pixelblaze and allow some pipeline improvements. Maybe up to 2X improvement.
Wiring the strips in parallel would give you an 8x speed up as it would be only 260 pixels at that point. You’d loose the ability to use the angle around the cylinder in animations though, and would effectively be 1D.
Alternatively, you could wire half of the strips in parallel (on opposite sides) for a 2X speedup. The thinking here is that you usually only see whatever 4 strips are facing you and could still get some nice 2D animations. You’d only have 1040 pixels, with 4 columns available for 2D rendering.
If you are getting weird pauses, try disabling the live previews by clicking on it in the interface (just under the main nav), or load a minimal set of resources by adding ?min to the url.
I hope that helps, let us know what you try!
Awesome @wizard for the quick and thorough reply with many options to contemplate! Always a pleasure!!!
But I’d definitely try output expander first, compare speed, ensure no voltage drop, etc.
Then slowly simplify until it’s an acceptable speed.
You could still do a 3d mapping so long as you’re ok with rendering it on half the space.
Thanks @Scruffynerf…I’ll definitely try the OE. I presume it emulates a single continuous strip? How many channels do u suggest I break the 2,080 into? 8x260? I also like the idea of mirroring each side!
With the OE, it takes the pixel data and sends it to the OE rather than to the pixels directly. Then the OE translates and sends to each strand as needed. If your speed issue is calculation of pixel data, you won’t see much speed difference. If the issue is pushing pixel data fast enough, you’ll see the speed increase greatly.
Since the OE has 8 channels, you might be tempted to just add all 8 strands, one to each, but looking at the video of the data flow, if the strands are up and down, you can more easily try adding them as 4 pairs (ie 520 pixels) first before you have to work to reorient 4 strands backwards to make them all go in the same direction to more easily wire the OE into 8.
Thanks for clarifying that as that makes perfect sense in terms of both strip orientation and wire management. This project has very tight spaces which in itself is quite a challenge…especially for managing the 21700 LI batteries and their wires safely in a 1" tube! Had to get creative with the battery connectors (5/8" disc magnets and zinc washers with wire soldered to them…all encased in acrylic.
Definitely interested in seeing photos of the battery setup. I’m building poi and hoops and so on and considering what’s the best options…
Just got some 18650 and 16340 batteries and regulator/charger holder/pcbs (so they’ll do 3.3 and 5v, and have a USB charge port), but also looking at 14500 (3.7v), vs 3 AA or even AAA (which is nominally also 3.7ish, not really 4.5v-5V) for something like a hoop.
Here’s a couple of pics. The silver discs are magnets and behind those are zinc washers soldered to the power or ground wire that pops out the other end. It’s designed so I can run several batteries in parallel within a 1" tube. My final version will have 2-pin connectors at each end so I can daisy chain as many batteries as needed to increase hours. I thought about adding a charger to avoid battery removal but all that I read seemed to conclude "don’t charge LI batteries in parallel. So the design allows for quick removal as they are just held by magnets. I bought from Battery Junction…Samsung 5,000 mah unprotected…same I think they use for Teslas. Still work in process and still learning much!
@JerryB,
Thats a neat setup! I like the magnet connectors!
When you connect two batteries in parallel, their voltage will attempt to equalize.
If your cells are already equalized (or nearly so), parallel is OK. If not, and let’s say you connect a low voltage one and a fully charged one, the charged cell will provide current to the discharged cell and may charge it too quickly (like heat, fire, explosions, and that kind of thing).
Once equalized, charge current applied to a parallel pack is spread to all cells and their voltages will remain equalized. Cells of different capacities can be mixed in a parallel pack. Only at extreme charge currents and with very mismatched cells could one cell be charged too quickly. If in doubt, set your charge current to the max an individual cell can accept.
In series is where charging gets tricky and you need a balancer. Otherwise the difference in cell capacity can cause voltage differences that can exceed the safe range (fire, explosions, time-continuum paradoxes, that sort of thing) . e.g. if you have one cell with an actual capacity of 1000mAH and 1 with 2000mAH, the weak cell will charge first, and then start to overcharge before the other reaches capacity. Usually the difference is not this great, and series packs are made with balanced cell capacity, but the balancing charger ensures they don’t drift too far and overcharge any one cell. This is why series chargers for lithium batteries always have more wires, they tap in between each cell.
Thanks! Yes, I saw some scary videos of the power of an explosive LI battery. For the parallel pack, I only use the exact same types of batteries which have been either fully charged. But as they say…if you don’t see smoke…you’re not trying hard enough!
I’m back again with a failed attempt at the Output Expander so I diagramed out how I connected everything (used two channel example but actually using 4) as you can see in the Settings (last strip is 260 - waiting for Amazon to deliver more LED to complete!). PB is powered, I presume the OE is powered but no blinky lights at all. Where did I go wrong?
Probably just a drawing omission, but I don’t see a data line from PB to the OE in your diagram.
Does the orange light on the OE light up? If so, it is getting valid data for its address.
Is this an older output expander or newer model? The older ones are limited to 240 pixels per channel. The newer ones have one of the chips rotated 45 degrees like a diamond shape.
New:
Old:
Even without actual LEDs working or expander connected, your FPS should be reported accurately. See an improvement?
Unfortunately no orange light on the OE and yes, a newer OE as you described. Ah…I neglected to connect PB Data to OE Data. Back to the table and be right back!
I do see the FPS increase from about 4 to 5 so about 25% using Angle and Radius pattern. But still no orange light on the OE unfortunately so I can’t complete today’s experiment.
Definitely data, and not clock? Try a continuity check across the boards (sometimes soldering joints or wire insulation in the screw terminal can cause issues).
Also check the underside, none of the cuttable jumpers has been nicked has it? That could change it from address 0. You can try each of the 8 addresses one at a time in the UI and see if it responds on a different address just in case.
Would you also try it with just a few pixels on one channel just to see if it lights up the orange status LED?
Great news…Bright Orange appeared…and we have power to the OE board…FPS is better but not quite where I want to so I think I need to split the staff into two as you suggested.
So the angle and radius pattern is going to be very intensive to calculate…
Going from XY to RA involves sqrts and math
Going from RA to XY is far more trivial: it’s sin or cos and that’s all.
If you replace the XY mapping with an RA mapping, and the pattern is purely RA focused, what’s the FPS? Your slow down could be due to all of the math needed that could be entirely precalculated.
(Happy to flesh this out if you want … I’ll have to dig out the math/etc)
