I’m in the process of building a POV display for Burning Man. The idea is to have 600 SK9822A LEDs on a string, 10cm/4in apart, held aloft by a helium balloon 60m/200ft in the air. I’m hitting some challenges and would love some feedback from the more experienced folks here.
I think I’ll need to drive the LEDs at 8MHz or more to be able to get updates fast enough for the POV effect. I can’t run multiple data lines, this has to be all one strip.
The first problem is that I’ve found that with some 60led/m test strips of SK9822 LEDs I get corruption in the display after ~150 LEDs at clock rates faster than 2-4MHz. Is this expected with this LED? Will the SK9822A’s be better? It’s not clear to me from the Electromage product pages what the limit is for the number of SK9822/A on a single strand at a given frequency.
The second problem I’m facing with the Pixelblaze is that it’s blazingly fast at sending the data, but appears to be compute bound calculating the individual pixels. Are there any facilities for precomputing or duplicating pixels that will allow for very fast frame rates appropriate for POV?
I’ve done some PoV stuff with Pixelblaze and SK9822s.
The relationship about clock speed and how many pixels can run in a single serial line before flickering occurs is dependent on a few variables. We can’t create a XY graph of the relationship on a product page because it depends on three things:
The physical spacing between pixels, both in terms of distance and amount of copper (impedance). Large influence.
The power injection scheme, IE how long before you reinject 5V. Large influence.
The quality of each chip in the sequence, IE depending on production batch and statistics about manufacturing consistency and whether you got lucky with those pixels (smaller influence)
The specific pattern you’re running, as it too can determine the voltage drop characteristics or have a bit stream that is more or less susceptible to noise.
So in general, you do need to find out the max clock speed that’s usable for your particular installation. For example, on Titanic’s End I found we could run 500 in a strand form factor with 10cm spacing at 2MHz.
There are a number of techniques (mostly precomputing and caching) that can be used to speed up any particular pattern in PB code, but you’re right that in general you’re going to find a compute bound at around 45,000 pixels per seconds, and depending on your pixel run length, that can be the limiting factor. In those cases, I’d be tempted to go back to trying to use something closer to the metal, like running my own C/C++ on Arduino or Espressif. And, the largest PoV displays don’t use shift register style pixels at all, they will do custom PCBs with parallel bus architectures (data to each pixel or groups of pixels).
I guess I’ll need to build some segments and see how it goes, keeping an eye on the impedance in particular. I’m planning on using the SK9822A, but if anyone has a suggestion for a better LED (HD107S has been offered by a supplier), I’m all ears.
Totally understand the limits of the PB with respect to being compute bound. My previous projects used Arduino C++ ESP32 and FastLED, so I guess I’ll head back to that approach and keep my PB in my arsenal for future projects. I’m stuck with a single pair of control lines given the weight constraints of the balloon!
One feature that would be awesome would be built-in scaling where you can declare a number of pixels for “render(index)” to be called and PB would scale them up quickly, possibly with interpolation. That would be totally fine for my application.
In any case PixelBlaze is really a terrific bit of kit, so easy to use to test out various ideas. I’m sure I’ll be using it more.
This sounds super cool! Yes, coordinating that kind of distance + speed will be a challenge.
First I’d figure out what kind of FPS you need for your POV effect. It’s possible to do some POV without hundreds of FPS. Figure out how many time-pixels of resolution you need, given the distance any imagery would be recognizable. Also are you doing text, pictures, or just neat patterns? Some of that will be more or less demanding on update rates.
I’d be tempted to try something with sync running a few separate PBs together, but it’s only good down to a handful of milliseconds and each could be slightly out of sync for POV (then again the line isn’t going to be exactly in a straight line either). Something like that would help keep total data runs lower, and boost FPS. You’d need to aim a directional antenna at them too to keep the signal linked up.
Honestly might be easier with a bunch of microcontrollers and an RS485 control bus (differential data pair) going along your wire to keep them all in sync and coordinate patterns. Or maybe some data encoded on the power line.
I’ve estimated about 400-500fps, just playing around with a strip of LEDs here up close to get a reasonable pixel width angle to get a portrait image, multiplying that out (400frames/sec x 600pixels/frame x 32bits/pixel = 7.68m pixels/sec). Hoping to do some text and graphic images, maybe even some bitmap photos if we have the storage). We’ll also have some non POV animations for things like lightning strikes and some nice color effects.
If we could afford the weight of additional wires I’d look into running mutilple SPI signals up (with differential drivers) or even running ethernet to multiple controllers.
But we’re very weight constrained, each gram costs another $1 to lift.
The two-wire spi protocol is kind of ideal for this, the trick really is about signal integrity, I think.
I wish I knew which LEDs handled signal integrity the best (both in input sensitivity and output reencoding.) It seems that the MHz specs are only a small piece of the story…
I wish I could remember! It depends on the pattern for sure, and you can estimate it by enumerating the radial resolution for each pattern and using the 40 RPM.
The 128 x 2020-sized closely-spaced LEDs for text was extremely high; IIRC you could drive it at like 500 FPS.
