I've spent the past few days designing a new PCB for the USB DMX interface. It's been an interesting experience working with Eagle again after some time, but after a few iterations and improvements I believe that I have found a pretty good design that fits all the hardware functions onto a rather compact form factor.
Current DMX board design
I've used A and B Series Neutrik XLR connectors that take up very little space, and I also managed to introduce galvanic isolation into the design (however I am not really sure whether or not the physical component spacing is sufficient to deflect an actual surge).
As you can see, the board incorporates an ICSP programming header; I included this for emergency use. The ATMega32u4 comes preprogrammed with a bootloader that allows flashing the firmware directly over USB. But since I don't have any experience with the process, I wanted to make sure that I can at least still test the rest of the circuit if problems come up.
Right now I'm waiting for all the parts to be delivered, so I can confirm the sizes of some of the components I had to build from scratch (are those optocouplers really that huge?).
Size testing the components.
Looks good, huh? If everything works out alright, I might finish this within the next week. Stay tuned!
Everything is working even better than expected. That's why there's still not many words today. Picked up my package today, and finally unpacked two real, unmodified stage-quality DMX LED PAR56s.
New lighting equipment
All I had to do was solder a short adapter cable with an XLR plug and connect it all up, configure a new fixture to correspond the DMX channel mapping, and plug it all together. Works like a charm, check out the video:
Today I had some more time to work on my DMX project, and since my new spotlights have not yet arrived (they seem to be at the post office for pickup), I chose to work on the software part, more specifically: the integration into the PiLight system.
This is not going to be a very exciting post since I'm just going to refer you to the github project for the details on what I've done simply because there was not much to be learned today. I included the python code from the FX5 project (the commercial clone of the Digital Enlightenment interface) and wrote some simple interfacing python code (luckily, PiLight is already somewhat similiar to classical lighting control systems in its architecture) and it worked right away.
Here's a video that shows it in action (and also an early development stage of the upcoming Android app):
Alright! It's been quite some time since my last post here (almost a year!), and I must admit that there has not been much going on, so at least you haven't been missing out. That is - until a few days ago, of course, and that's why I'm writing this new post to bring my latest experiences to you!
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.
The first thing I did was to attach a MAX485 chip to one of my Arduinos to have some sort of "reference device" that I could perform further tests with. I adapted some code taken from Hennes Sites and verified that it was working by attaching the circuit to a DMX controller. The good news from this experiment is: I did not need to alter the RS485 receiving circuit, which means that both the PiLight controller board as well as the PiLight LED dimmer are basically capable of receiving DMX signals; They only lack the right firmware, which I might eventually come up with.
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!
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.
