I've already mentioned the DMX protocol on here before, but since I had the opportunity to work with some actual DMX equipment these days, I thought this would be a good time to dive in deeper. Some words about the DMX protocol:
- It's the de facto standard for professional lighting equipment. Pretty much any kind of modern lighting equipment that is used on stage comes with a DMX interface (well, apart from simple lamps obviously, since those will usually be hooked up to a DMX dimmer).
- It is a serial protocol, transferred over an RS485 bus; It's initiated via a so-called "break" signal followed by a "start" byte and up to 512 channel value bytes in sequential order. After that follows the next break, and the cycle starts over. All bytes are sent as 8N2, meaning 8 bits followed by two stop bits.
Reference device with 6 DMX channels |
The one thing I am really after is to have an interface that would allow the integration of actual DMX devices into the PiLight system. It should be pretty simple to come up with a simple SPI-driven extension board for the Raspberry PI that would output DMX (fueled for instance by a ATMega328p), and I might eventually return to that idea.
But instead, I have a different idea.
From the past I already know a few DMX-Interfaces for computers, and most of them will work more or less reliably. But there is one Interface that is not only know for its reliability, but also its performance and the fact that you can actually build one yourself (and yes, I have). I'm talking about the Digital Enlightenment USB-DMX Interface.
Now, if I'd just follow the scheme and built another instance of this well-known interface, that would be kind of boring. Instead, I've had a few thoughts on the design (that dates back a few years now):
- It uses a separate USBN chip to communicate with the computer. While this works perfectly, it also seems a little redundant these days, since we now have microcontrollers available that come with an integrated USB interface (e.g. ATMega16u2, ATMega32u4).
- It uses an 8kb external memory chip (and an additional latch chip for communication) in order to store the current DMX state. This is due to the limited amount of memory available (512 bytes on an ATMega8515) in the original microcontroller. Now, 8kb is still a lot of data for a microcontroller today (an ATMega32u4 holds 2,5kb), but with some optimization I might actually find a solution that does not require any external memory.
So... with a little bit of work, I could reduce the necessary components, and combined with the switch to SMT components that would mean a much smaller and cheaper DMX interface!
After some work on the Arduino core I was able to come up with some modified USB code that contained the device descriptors of the original interface, and after some more hacking I held in my hand an Arduino Leonardo that was recognized by the original driver and was successfully receiving data from the software. I attached some LEDs to the PWM ports and was able to control their level from the computer. Success!
Now all I had to do was to come up with some code that would output the correct DMX-signals on the internal UART, add a MAX484 converter chip, and my newly created homebrew DMX interface would be finished. I connected it to my reference device, and it worked right away! Awesome!
What's next? Here's the (unordered) list of next steps:
Now all I had to do was to come up with some code that would output the correct DMX-signals on the internal UART, add a MAX484 converter chip, and my newly created homebrew DMX interface would be finished. I connected it to my reference device, and it worked right away! Awesome!
Complete DMX testing setup: Arduino Leonardo as DMX interface on the left, Arduino UNO as DMX reference device on the right, both connected via a DMX-like connection. |
Another shot of the testing setup |
What's next? Here's the (unordered) list of next steps:
- Testing. First of all I will need to test my new interface with some real-world DMX devices, to make sure that the generated output is sufficient for real-world applications.
- PiLight Integration: So far I've spent a lot of time coming up with a DMX interface, but I haven't spent any time to make it work with the PiLight software. The good news is, that there's already some python code available. Also, this would introduce compatibility with the original interface design.
- DMX Input: The original interface supported a DMX input, too, as well as a handful of different modes that would combine the signals in different ways which I'd like to implement as well for full compatibility.
- Configuration: The original design had a set of parameters that could be used to fine-tune the DMX output. The DMX standard allows for some variations in the protocol timing, and some devices might fail to interpret the data under certain circumstances. The parameters could be used to fix this. Would be nice to have that option, too.
- Galvanic isolation: The original design features a complete isolation of the DMX part from the microprocessor, that would protect the attached computer in case of a DMX device on the bus erratically outputting excess voltage onto the bus. Easily adopted from the original design.
- Packaging: Once the circuit and software is confirmed to work, I will try to come up with a PCB reduced to the minimum, and some sort of case. When leaving out the galvanic isolation, this might even be small enough to enclose into some sort of USB key.
To be continued!
No comments:
Post a Comment