The DMX Experience (Part 1)

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.

To be continued!

Mixing up the Christmas tree

Every time, once a year, there's this special time for cookies, presents, warmth, family gatherings and cheesy decorations. I'm talking about Christmas, and event though it's already over, I'd still like to share with you my way of spicing up the decoration. This is not one of the usual, overly techy posts... in fact, this post just shows a mere application of the things that are already described in previous posts. Instead, I'd just like to leave you with some jolly pictures and videos. Enjoy!

Fully decorated & all lit up

Adding some color

Video showing twinkle and snowflake shows

The final video shows some interaction with music

For those of you who'd still like to know a few details: I used a 50-LED WS2801 LED strand (like this one from adafruit), in combination with the PiLight controller board, all driven via RS485 by my central PiLight command Raspberry Pi.

The new LED dimmer (Part 2 - now with brainz)

I wrote about a concept for replacing my old LED dimmer a while back (original post here), but with all the recent learnings and achievements I had to do a little brush-up on the original design (and I had a lot of fun doing so, since this brought even more improvements to the concept).

The first thing I did was to redesign the circuit. The original design was meant to be attached to a Raspberry Pi directly via I2C, which would then be receiving commands from the main controller via Ethernet. The recent discovery of the RS485 bus and the ability to integrate that directly into my circuits allowed me to completely dismiss the Raspberry Pi for this purpose, and I was even able to integrate the complete RS485 decoder circuit onto the board directly.

The finished eagle design looks like this:

New dimmer design including AVR

I then set out to build this, and I almost quit while making the PCB: It took me five attempts to get the toner for the top layer transferred to the raw copper. That, and the outlook that I had to do the same with the bottom layer almost drove me crazy. Luckily, things went way better after that: The bottom layer worked on the first attempt, and even the registration between the two layers was immediately perfect.

Here's a few pictures of the assembly:

Etched and drilled board with the first SMD components to be assembled

Microcontroller, crystal, RS485 decoder and PWM chips in place

It's alive! (Testing with the Arduino "blink" sketch)

More testing, this time with RS485 data

All amplifiers in place

Testing with actual LEDs

More testing and debugging

At that point I noticed a few communication glitches, and I ended up introducing some checksums to my self-devised serial protocol to fix them. In the picture above you can see the Arduino I used to download the firmware to the dimmer during this process.

I also ended up integrating a channel map to fix the channel sequence problems introduced by the board design right into the firmware.

Finished dimmer insides with the secondary output board on top

Finished dimmer with LED connections (Some are still available).

Here's a few things I learned from this project, too:

• The ISP header is too close to a mounting hole. This was no big deal as long as I was working with the base board only, but with the stacked output board mounted on top the ISP header is pretty much inaccessible.
• The overall power consumption appears to be pretty high. I only know that from the temperature the 7805 reached when multiple LEDs were on. Since the 7805 only supplies the microcontroller and the two PCAs, I suppose that it's the PCAs' outputs that run much more current than necessary to trigger the ULN2064s. The Adafruit PWM board that I previously used had 10K resistors in its output lines, and I should have included those, too. On the other hand however: Who would like to solder 32 individual 0805 SMD resistors? As a solution I replaced the 7805 with a step-down regulator that is more efficient and does not produce that much heat.
• Drilling the front plate was a bad idea. It literally crumbled in my fingers. But since I don't own a proper milling machine, I don't have many options. (You can see the damages in the last picture if you look closely.)

Where to go from here? Well, the device itself is not complete yet: It still lacks a back plate and some proper connectors for the RS485 bus (right now, the cables go right into the housing and are plugged into the main board). I'm currently thinking about RJ10 connectors for that purpose. And I might need to replace the front plate due to damages, but that would only be cosmetics. Other than that I'm pretty contempt with the result.

Taking the bus (Part 3): The controller

You know the day is going to be good when the mailman rings at the door during breakfast time. Well, apart from the breakfast obviously. In my case, I was about to receive a box of fresh new and exciting components to build awesome stuff with:

Bunch of components

Among them was the ATMEGA328P microcontrollers I was eagerly waiting for to be able to build the controller module from my previous post. I already prepared the PCB (my first double-sided one, with lots of vias), meaning that I could start with all the SMD components right away:

Pilight controller board, partially assembled

After making sure that there were no shorts or dead solder joints on the board I was ready to add the headers and program the microcontroller:

Finished controller board

Port illustration

Size comparison: Full-size Arduino, Pilight controller, Arduino Mini

Programming with ArduinoISP

The programming step was a little troublesome, because I wired the cable to connect the controller to the Arduino incorrectly, meaning that my controller was missing ground and in constant reset state. Of course the cable was the last part I checked... However, after fixing it programming went fine.

After that, I hooked the board to the WS2801 LED pixel strand only to find out that i switched data & clock on the SPI port. Oh well. Luckily, I could make it work with a corresponding cable:

Controller in place

I previously named this the "Pilight universal controller" because I designed it to be able to drive all the various pilight devices - and so I needed to try the I2C port, too:

Pilight controller driving a PCA9685 PWM board

I'm very glad it all worked out so nicely. This first controller prototype will now resume its work on the pixel strand, and I am back to the drawing board to integrate the same microcontroller circuit into the LED dimmer board.

Update: Here's another short video of the controller in action. Enjoy :)

Taking the bus (Part 2)

Over the last few days I've been working on a lot of small things, and I've had a lot of new interesting findings. This is a combined blogpost of all the new stuff I'm working on.

For one, I took apart my central pilight controller Raspberry (after a staggering uptime of 224 days!) and had it equipped with an upgraded version of the RS485 shield from my previous post. I didn't take pictures this time, but the RS485 part is basically still the same. What I've done is I've added both I2C and SPI outputs to the board for a directly attached LPD8806 strip and a 20*4 LCD display respectively.

From there, I ran a long network cable (about 10m) across my room for  RS485 testing. I would have preferred a phone line, but unfortunately I don't have one yet, and the network cable was the only cable at hand that met the electrical requirements and was long enough.

Pilight central command with attached RS485 line

On the other end of this line now sits an Arduino, which has already replaced the Raspberry Pi that was once used to drive the WS2801 LED pixel strand there.

I've been working on the serial protocol that is run over the RS485 line and the corresponding Arduino sketch to fix a few glitches. It's now operating properly, and will also allow me to address multiple target devices attached to a single line.

Also, a friend of mine that also happens to be the local Raspberry & Arduino dealer was so kind to provide me with a few more Arduino boards for experimenting, among them an Arduino Mini. I immediately had to try this one out, and after a little bit of fiddling with the cables (the Mini comes without USB, nor does it have a standard-compliant ISP port for programming) and modifying the sketches I was able to integrate it into my system successfully.

Arduino Mini with MAX485 on breadboard, RS485 line on the right

I also did a little measuring and was pleasantly surprised that the complete circuit on the breadboard consumes a mere 20mA. That (apart from other improvements like the drastically reduced latency) really is a huge advantage over the Raspberry Pi based solution.

Since all those little experiments have worked out so well, I've also had plenty of time to read up on where to go from here. I'm currently working on a first board that will in turn replace the Arduino again. I've taken the same microcontroller that sits on most Arduinos (the ATMEGA328P), added only the necessary components to make it work, a MAX485 bus driver and headers for ICSP, I2C and SPI. Here's what the design looks like:

Pilight universal controller board (size: 23*37mm)

It is slightly larger than the Arduino Mini (the TQFP package of the processor is bigger, and the Arduino does not have RS485) but it's still pretty tiny. I'm curious what case options will be available for such a small board.

I've also thought about a way to get some configuration (like device ids) onto the controllers (that's what the CONFIG jumper is for) but I haven't had the time to test it out yet, so this will be part of a later post.

I've also postponed the production of the new LED dimmer for now, since the current version is designed to be driven by an external controller (in my original plan that would have been a Raspberry Pi). With all those new findings however I'd really like to integrate the controller right into the dimmer itself, which would allow me to directly connect it to the RS485 bus without any additional hardware.

Next steps will be to compile a list of parts for the new controller, since this will most probably be the next device for me to build. I'll post another update on this soon.

Taking the bus

So you remember the bunch of boards I wired together for my previous post? Well, when I returned home today I was very happy to find a parcel full of electronic parts in the mail. It included the MAX3485 / MAX485 chips I ordered for this project, and with them I altered the circuit a little:

As you can see, most of the parts are still in place: bargraph display, PWM board, Arduino, Raspberry Pi. What you might be missing is the USB cable between the Pi and the Arduino: it's no longer necessary. Instead, the devices are now connected through a RS485 bus (the small, 3-wire cable that's visible between the Pi and the breadboard).

The amazing part is: In theory, when done right, that little cable can be extended to lengths of many meters, under certain conditions even kilometers. I don't think I will be going to such lengths, but that sure is enough to wire up a complete appartment or even house.

Another advantage of this concept is that I can daisy-chain multiple receivers to this bus, so that a single cable should be enough to wire up a whole lighting system.

This is very close to a DMX system already, however I think I will stick with the way it works now since I'm not sure wether the Raspberry Pi is capable of producing the necessary signal timing.

Some details.

Since the MAX3485 (a 3.3V compatible bus chip) was only available in an SMD package, I had to come up with a little testing shield in eagle:

This board is a mere transmitter due to the fact that the MAX3485 is designed for half-duplex mode. Switching between sending and receiving however would require an electronic signal that the Pi is (at least to my knowledge) unable to produce. I thought about wiring up a GPIO port, but this is purportedly too slow. Writing back to the Pi however is not really a requirement for my purpose, so I simply pulled the DE pin high, which means that this shield is only capable of transmitting data.

For the Arduino side, i wired everything onto a breadboard for now:

This is basically the same circuit, except that I used a MAX485 (the 5V equivalent) and pulled DE and RE low to put it into permanent receiving mode.

Next steps: I'm currently trying to figure out a protocol that will allow me to address multiple receivers on a single bus, without introducing too much of a delay. I'll post my results as soon as I worked something out.