Getting back to LED art and realizing you were never in: A mile high survey of today’s LED options.
What is this, exactly?
For the last few months I’ve been going from old to new in terms of how modern LED art is done. This post serves as a summary around what I’ve learned about how modern protocols, drivers, data driving and generation seem to be done. I don’t claim to be an authority, but I definitely have an opinion.
Creating LED art installations is a lot easier thanks to the advent of a few pieces of technology and their combined use to enable close to plug and play design and operation.
- OPC (controller agnostic control protocol)
- High quality LED data drivers (including color correction & other important features)
- WS2811/2/2b Cheap PWM drivers integrated in LEDs
- Great off the shelf animation controller options
If that was the key then this is the Lock
The land before light
I went to school for Electrical and Computer Engineering. I had a leg up in microcontrollers; I learned the painful, arcane basics while arduino was still nascent. I wrote my own one-off led driving firmware before FastLED/fadecandy/OPC or any of this great stuff came out. My roomate and I made a monochrome (blue) display for our ceiling for party. (everything was custom, but that isn’t something to brag about. The whole thing was as fragile as it was ephemeral)
So to come back to a Cambrian explosion of various drivers, displays and signal generators was a bit overwhelming. I’d seen the results at shows, museums, on people’s bikes (and other ahem vehicles). I was impressed by what a lot of people were able to pull off with relatively little background in the engineering and with simple hardware. Despite this scrappiness, it seemed like most of the artists were still stuck on the other side of the technology.
Let there be WS2811/2/b
Before these nifty integrated LEDs making LED art was a considerable mechanical and electrical undertaking. And all of that inflated cost. WS281*s changed all that with a few major features.
- R/G/B in one package, with a nice wide diffuser and reasonably even brightness
- A simple shift register style data in/data out with a latch after N usecs
- Built in driver with high speed PWM per LED
- Relatively low cost (and getting better all the time!)
This allowed you to pull an LED metrix/strand off the shelf and drive it with a bunch of ready-made arduino libraries. Very cool. I played around with signal generation on the arduino, pushing a lot of frames. I quickly realized I didn’t understand colorspaces very well, but I hacked around it with hand picked palettes to make the effect nice to look at.
Chroma? Is that some kind of slide film?
Learning about color spaces continues to be a deep topic, but there is help for the lazy (or was it busy) in implementations like HSLuv which make a few decisions for you but let you get on with that whole “making nice colors that go together” thing. Playing around with it directly to LEDs I found it somewhat disappointingly washed out. I’m definitely willing to believe operator error here, but even the examples and the colorspace seem to make this tradeoff.
I sat between uniformity and colorfulness until I learned about all of the other trade offs the people used to driving LEDs make, which tend to be against uniformity in exchange for richness. Lots of gamma adjustments, LUTs, and hardware specific tweaks seem to be the standard here. I’ve been more than happy with the implementation on the fadecandy so far.
fadecandy: pushing pixels so you can push frames
Since I first started, a lot of these solutions and approaches I’ve picked up piecemeal (mostly by failing, or as I like to put it, partially succeeding) have become implemented in hardware. I think soon enough, you won’t need to know about most of these things, arguably that time is already now. These WS281* drivers remove you from the low level concerns.
There are a large variety of drivers out there, but I picked the fadecandy out because it implemented some of what I had learned were key features for low level control.
- frame interpolation (smoothly draws many sub-frames between two frames)
- time domain dithering (higher bit depth emulation)
- high update rate (400hz) means no flicker
- lots of color processing to allow simple HSL/HSV control with good saturation and reasonable uniformity
- has a built in OPC server to push data to the display
One protocol to bind them: OPC
Software level protocols draw a lot of ire, especially when there’s no clear standard. It seems like the early winner so far is OPC which lets you, finally, just connect the damned animation controller to some server implementing the protocol.
I know a lot of people use DMX for this, but speaking of protocols and ire… I couldn’t believe this was the standard for stage lighting and control. It was probably awesome in the 80s, but it’s not suitable for modern LED control, for so many reasons… the main one being it’s designed around the physical nature of how it’s connected. With OPC I can just say “the server implementing this protocol, anywhere, with any arbitrary output speed etc”. DMX has no such server concept, just a set of controllers on channels daisy chained together.
I’d call it the difference between data oriented and object oriented, but I don’t want to start a fight.
The curse of complete control
Large scale LED installations need to push a lot of frames out to each part of the display, and can’t be bothered with things like dealing with the WS281*‘s poor color depth (8 bits per channel) and very non-linear response. They definitely don’t want to deal with pushing out frames at the rate each pixel needs and wants data.
What to do then? Put a lot of controllers into the project to handle these low level aspects, and give up complete control and move your effort towards generating frames worth looking at. I’d always gotten hung up on the lower level concerns that I’d never gotten around to doing stuff like music reactivity, channel mixing, effects, and other fun stuff. You know, what most people would consider the interesting part.
PS I really like the ideas in PixelController but I think it could use an OPC output. It’s very similar to what DJs use to mix songs together/on the fly.
What do do about the darkness, then?
I think today’s burgeoning toolset really enables a lot higher level focus’ for an LED artists projects. I’m working on wiring the fadecandy into a 16x16 matrix of WS2812s (only 32$ on alixpress/amazon/wherever online, similar things were easily 4x that when I started) and driving it with some of the effects in the PixelController. It’s not much, but just figuring out the different options available today was a significant chunk of research. Hopefully my very brief summary will help those with a bit of programming background wade through the options.
As an aside, my first stupid problem is of course wiring. The fadecandy only wants 64 leds in a row, but this panel is 256 in a row. Splicing and bodge wires, here I come…
I have a vague notion of plumbing electric sheep into some FFT code and sending it with OPC, but that will have to wait for another integration.