Raspberries, DMX and blinkenlights
I’ve been personally fascinated with lights for a while, especially with those that can move, change color, spin around and flash, all through some mysterious connection that seems to incorrectly use what is pretty much a microphone cable most of the time (those don’t tend to emit light though, at least not for long).
With my recent additional experiences in the event tech industry I’ve decided to play around with these things myself a bit. As it turns out, all that doesn’t always go without a hitch.
Lights are expensive
In fact, really expensive. In the grand scheme of things they are actually pretty cheap, but for a hobbyist like me who just wants to experiment a bit a price tag of more than 100€ is really hard to justify. Considering that proper lighting consoles can cost anywhere from 1,500€ to upwards of 32,000€ I’m not going to complain about that price range (at least not much). But it’s still a hefty price tag that I’m not too comfortable paying for something I’m not even sure will work in the end.
So instead I took to Ebay!
One requirement was obviously a light fixture that has a working DMX input, otherwise what would be the point? I was able to find a cheap one for around 30€ that seemed to support simple red, green abd blue chanel control, which would be plenty enough for a first experiment. I also managed to find a defective unit of this EUROLITE DMX Scene Setter for just 20€! Granted, it wasn’t working properly according to the seller, but that’s a steal for about a tenth of the retail value. Even if it was actually broken beyond repair, that wouldn’t leave me angry in the end.
Inspecting the light and the DMX console
I got both the light and the console home and went to inspect the lamp first. It’s definitely cheap and not of great quality, but it works and is actually decently bright. Definitely not a professional light, but absolutely works for a small party or private lighting setups at home. A quick look into the (fairly incomprehnsible) manual actually revealed that instead of the 3 DMX channels I had assumed it to have, it actually has a whole 7! One for general brightnes, one for red, green and blue respectively, one for strobe speed (or no strobe), one for mode constrol, and one for setting parametres, depending on which mode is selected. A lot more than I was expecting, but definitely a wecome discovery.
Next on the list was the DMX controller. According to the seller it would prower on properly, work for a few minutes and then proceed to randomly reset itself every couple seconds. I left it running for a bit and indeed after a few minutes it started malfunctioning. I played around with it a bit more and eventually discovered that the “Full On” button would cause it to continuously reset in rapid succession while pressed. So something was clearly not right with this unit. Despite the malfunctioning, it was able to putput at least some sort of DMX signal, even if it wasn’t at all what I had set it to.
With that I went ahead and opened the console up, which was vry straightforward. No hidden screws, no glue, just a proper metal casing with good threading and easily taken appart. I have to give credit where it’s due, it’s definitely not preventing anyone from accessing the internals through stupid means. To my surprise the entire unit’s circuit board was made entirely of oldschool through-hole soldered components, which I hadn’t expected. Not a single surface mount component in there. A single disconnected ribbon cable later I had the board sepparated from the chasis. One thing immediately stood out, which was a very ugly looking battery that was leaking all over the board. I went and checked the voltage on it, and it seemed fine, so for the time being I cleaned the leakage and the board around it up. I’ll have to eventually replace that battery for sure, but for the moment I decided that cleaning it up would be good enough. I’m not planing to use the console for anything other than quick testing of the lamp anyway at the moment. While inspecting the oard further I also noticed a couple bent transistors that looked like someone had dropped something on them, which I simply back into shape.
I quickly checked the voltage on the internal regulator, which also looked fine, so I put everything back together since I couldn’t find any other obvious issues with the board. Apparently the leaking battery really was the issue, since afterwards everything was working again like a charm. It’s been sitting on my desk for multiple hours now without any signs of random resets. It also now manages to output correct DMX signals, and I can now bathe my entire room in fresh RGB lighting. Take that, gamers!
Raspberry Pain
The first thing I wanted to try was getting any sort of lighting control to work from my Raspberry Pi, which according to my research shouldn’t involve much more than connecting the DMX data wires to the UART pins on the Pi and sending the right data at the right speed. At the time I didn’t quite realize that this wasn’t exactly correct, and I could have saved myself a day of useless debugging if I had paid a little more attention while reading. For now though I was trying to hook the DMX cable up to the right GPIO pins on the Pi, which is where I ran into the next issue.
I have a Raspberry Pi 3 Model B. If you have any experience with using the primary UART on these then you might already know what I’m getting at. For everyone else, there’s the explanation that I had to work my way through bit by bit.
The Pi’s primary UART is (usually) accessible through opening a serial port on /dev/ttyAMA0
. However, the Raspberry Pi 3B specifically instead uses this device for its Bluetooth receiver/transmitter. So opening that port like usual results in no outout on any of the expected GPIO pins. After reading up on it a bit more I figured out that there’s a way to change this behavior, and re-enable the default UART pins on /dev/ttyAMA0
.
I’ll update this section soon with a bit more info on exactly how this can be achieved, since I’ve had to experiment a bit with it myself. Either the info on the internet is only partially correct, or I’m only partially able to understand it. We’ll see once I confirm the exact steps.
With the UART now finally working on the correct pins I was able to proceed.
First attempts at sending data
My first attempt at sending any data at all was done using Python. (figure out which library I even used…) It was rather simple to set up and open the serial output. However, I sadly didn’t see any of the expected bright red color coming from my lamp, so I was a little disappointed at first. I decided that maybe it’s any issue with the Python library, so I looked for alternatives. I did find this library for Rust, which I’ve been wanting to play around with a bit more in general anyway, so that was a nice chance.
Aside from realizing that I definitely need more practice with Rust, I sadly came to exactly the same result in the end: A lamp that wasn’t making any light. At that point it was getting pretty late anyway, so I decided to call it a night and try again the next day with a fresh mind. That was a good decision, since I pretty much found the problem immediately when looking over the DMX protocol specification again the next day.
DMX uses “a unidirectional EIA-485 (RS-485) differential signaling” according to Wikipedia, which I didn’t realize at first. With this information it makes sense that just hooking a UART pin up to the DMX signal cable doesn’t work, since it doesn’t output a differential signal at all. So after a bit more research I figured that I’d need to use a little extra component in between that would turn my UART serial signal into a RS-485 differential signal. There are multiple very easy to use tranceiver chips out there that can do this for us. I didn’t really have a spare one on hand, but I managed to “borrow” the chip from inside the DMX console that I repaired just a day before. That obviously rendered the console unusable for it’s purpose, but I wasn’t planing on using it much anyway. I can always replace the chip after the fact once I’ve ordered a new one.
I quickly assembled the components on a breadboard and hooked the chip up to the correct wires. The exact chip was an SN75176BP
for which I was able to quickly find a datasheet on the internet that helped me figure out which wire goes where. A bit of electronics knowledge is definitely helpful here.
With the chip hooked up to the Pi I once more ran the exact same program that had failed me the day before, and I did get pretty excited when I got flashed in the face with a bright beam of red light; I should have probably turned the lamp somewhere else, but hey, it actually worked!
From that point onward it wasn’t difficult to start playing with the values, a simple sine wave that alternated between red and green lighting was the first slightly more advanced experiment I did. Overall it was a pretty simple program and very straight forward to use. The major time sink in this case was figuring out the quirks of the Pi as well as not understanding the requirements of the DMX protocol properly at first. Once these issues were resolved, it wa sreally just a matter of minutes to get the Rust (and even the Python) example up and running.
What’s next?
I’ve already been working on some more advanced things based on these experiments. There will be another post explaining more of the details of these, including delving into kernel drivers and struggling with Lua. Stay tuned for more DMX shenanigans in the future.