In my previous blog post, I detailed the start of my LED wall build project. At the point where I left off, I had 16 working LED tubes, each 2 m long and 120 pixels each. However, they are not individually controllable in real time from my laptop. It was clear that the Arduino/Raspberry Pi combination is not sufficient. Not only does it not have individual pixel control, they are also quite hard to properly mount on a truss.
The next step in the journey is to find a better controller, which allows for individual pixel control, and solves the truss problem.
Choosing a controller
One controller immediately came to mind: the Pixelpusher from my friends at Heroic Robotics. The board has eight outputs, which is a perfect match for my eight strips (but with every strip split into two, I’d still have to link them together). It also features an ethernet connector. In addition, the board promises to be fast enough. Another very nice feature is that the Pixelpusher features a Processing library, with seamless integration and plenty of examples.
I did not go with this controller from the start for a few reasons. First, I was worried about signal degradation. Ideally, the controller is as close as possible to the strips. But in the original theatrical setup, the strips were scattered across the stage. I could not guarantee that the signal would reach the outer ends of the stage unharmed. The next issue was the cost and the shipping time. It was impossible for me to predict that the controller would arrive in time, due to customs. Finally, the Pixelpusher does not support RGBW strips natively.
Another controller that I discovered later on was the Advatek PixLite 16 control board. It’s more expensive, but has twice the amount of outputs than the ‘Pusher. There would be no need to link strips together. Additionally, it has the option to use long range receivers for the situation where strips are scattered across the stage. And, not unimportant, it supports RGBW LED types.
Clearly the Advatek PixLite seems to be the best option… unless you’re on a budget. Having had to quit my day job to focus again on my master’s degree, this quickly became an issue. So a nice little package arrived on my doorstep, containing one of these things:
Controlling the controller
The first issue is that the Pixelpusher does not support RGBW chip types, like my SK6812 RGBW strips. My idea was to simply reshuffle the bits and trick the ‘Pusher into sending RGBW, while it thinks it’s still sending RGB. Instead of sending pixel data like this:
I would do this:
I experimented with Processing, adapting the Pixelpusher library example sketches. The reshuffling hack appears to work quite well!
Another nice feature of the Pixelpusher Processing library is that it takes care of connecting automatically. If the ‘Pusher and the device running the Processing sketch are on the same network, the ‘Pusher announces itself to the sketch without any user intervention at all. No need to find or set IP addresses, just plug and play. This is the feature that pushed me over the edge on the ‘Pushers.
The soft side of things
Simple Processing sketches are nice, but they offer little in terms of advanced pixel control. There are many software packages out there for LED matrix and pixel mapping purposes. I stumbled upon Jinx!. This freeware software has some advanced features, such as a DJ-style crossfader console, plenty of built-in effects, screengrabber modus, and even a scripting tool.
Jinx! outputs Art-Net, which the ‘Pusher doesn’t support natively. Heroic Robotics has written an Art-Net bridge, but that proved not sufficient for my purposes. Neither Jinx! nor the Art-Net bridge support RGBW strips. So that’s something that I had to solve myself. I wrote my own Art-Net bridge in Processing (using the Art-Net library), which also does the colour order reshuffling part necessary for the RGBW strips. It also contains a little bit of logic that adds the extra white channel when the saturation (the “whiteness” value) of a pixel drops below a certain threshold. This makes the white really pop out from the other colours, and adds a nice punch to the screen! This bridge will be detailed in a future blog post.
Here’s a vid of the setup in action:
The harder side of things
Until now the strips were a loose ensemble of tubes that had to be attached together manually. This is intentional, as I wanted to have the option to distribute them across stage. But, with the individual pixel control finally working, it became necessary to connect the tubes tightly together. The zip tie method would no longer cut it. So, I got two M10 threaded rods, some nuts and a hand drill, and got to work.
It took me a couple days and an aching hand, but after drilling and redrilling 32 holes (one at each end of my 16 tubes), I was able to slide the threaded rods through the tubes and bolt them together. The LED screen is now not only in one piece, but also truss mountable!
Here is Milkdrop again:
A final mayor issue is still left. The wiring leads on the strips themselves are too short for any practical purposes. In the past, I resorted to using screw terminals, or even zip tying power supplies and controllers into the truss!
Not only was it dangerous, the screw terminals often gave bad connections, causing strips to be defective during gigs…
So, I got out the soldering station and attached the JST connectors to the clip-on solderless LED strip connectors. Then I got a cable and made 16 extension cords. Hurray for manual labour! Although it was a lengthy process making the connectors and extension cables, I’m sure it’ll save me a lot of time in the future trying to painstackingly attach leads together with screw terminals… The end result is well worth it. I can leave the PSUs and Pixelpusher safely in their chest on the floor, and I only have to attach the extension cords to the strips.
The whole control system is quite compact.
Not all is well…
I’m very pleased with my current setup, but there are still some flaws.
First is the power loss over the extension cords. They are 4 m long, plus various solder and clip-on connections. I’ve measured a loss of 2 of the 5 volts over the wire, at full power draw! This causes a brown-out on the strips. It’s noticeable when displaying bright images. To solve this, I’d need to either place the PSUs back closer to the strips, or get better cabling. Neither option is ideal.
Another issue is the SK6812 timing. Due to the absence of a clock line, the individual pixel control lags between strips. The strips aren’t too fast either. Strobing the image doesn’t work, and on moving features (especially text), the lag can be really noticeable. Not much can be done about this. It’s an inherent property of the strips I chose. It would be better to get a strip with a clock line (Heroic Robotics suggested the APA102s) but so far I haven’t found any which also had RGBW.
A last issue that needs to be solved is transport. The setup isn’t really road worthy. Especially the connectors at either end of the strips are prone to wear and tear. I still need to find a solution that protects the connectors. Another project for another time.
In retrospect, it would have been much better to go with the Pixelpusher from the beginning instead of messing about with Arduinos. Hardware wise, the form factor of the LED strips is quite hard to work with. The long tubes are clumsy to store and transport, and impossible to find a good enclosure for. If I were to build another LED wall, I would go with square panels on an aluminium plate, instead of tubes. However, I also like the option to split them out and use them as individual LED bars, the form factor just isn’t ideal for a real LED wall. The cost of flexibility…