Building the PiLight remote

Sometime ago I began to think about how cool it would be to have some kind of physical control for all the lights that I have set up in my apartment over time. Yes, I do have full control using the pilight website or app... but still, something a little more "haptical" is usually more intuitive and gives a better feel. Also, a dedicated device to control the light seemed appropriated, given all the nice things you could do with it.

I already had a CC3000 breakout module from adafruit at my hands, and so I started to experiment with one of the analog inputs and a simple sliding fader, and I was able to dim a light wirelessly. Awesome!

First basic setup, running off a battery for testing

One of the things I wanted to achieve was automatic discovery of the PiLight server using UDP Broadcasts. The CC3000 library was not really very supportive with this, but I got it to work after all using some low-level socket functions.

To make something useful out of my experiment, I ordered a few components: I hooked up an MSP3208 ADC chip and some more faders and pots to the existing setup. I added a 74HC165 parallel-to-serial latch and a rotary encoder. To display useful as well as not-so-useful information, I added an HD44780 2x20 character LCD to the setup. All this went into a handy little console case that was sitting in my attic for the past ten years or so.

Laying out the components (Motorized faderes are too big for this project. Maybe next time.)

Components in place, working on the ADC code and testing battery life once more

Adding the LCD display

While making progress with the firmware for the Arduino I started to notice unpredictable network connection dropouts and sometimes complete processor freezes. I tried a lot of debugging and could not really get any real results. After some research on the net I quickly found out that this seems to be quite a common problem of the CC3000 chip, and that there was very little I could do about it.

I really thought I was stuck at this point, but since the remote was working fine as long as the network was stable, I did not really want to scrap the whole project. Luckily, I stumbled across a new wireless development platform: enter the Spark Photon, featuring a 120MHz processor with integrated WiFi on an incredibly small form factor. There is also a handy battery shield available from SparkFun that is designed to run the Photon from a single-cell LiPo battery, plus the power consumption of the Photon is lower compared to the Arduino / CC3000 combo. A lot of advantages for the project at hand. Even porting the code was pretty simple, since the Photon uses C as the Arduino does, and all the libraries I used so far were available as well.

At this point I added a few more buttons to be able to trigger macros or effects, and I hid a LiPo that was originally intended to run an iPod under the main board. That little battery gives me 6-8 hours of uptime, which is plenty.

I did a pretty awful job with the openings of the top of the case once more... I still have no idea how to get a proper case done without a CNC machine or 3D printer unfortunately. But hey, it's working!

Finished casing

A few things are still to be done, though: The charging circuit still needs an external power connector, right now I have to fiddle a USB cable into the circuitry to charge it up. And I'd like to light up the buttons to be able to show whether something is turned on or off. I guess I'll be using another PCA9685 for that job, with it's 16 PWM outputs it would be perfect to put an RGB LED onto each one of the buttons, and with the last channel I might even be able to dim the LCD backlight.

The DMX Experience (Part 6 - Testing)

Last weekend I had the chance to use not only one, but two of my new USB DMX interfaces in a big, real-world party lighting setup. One of them was driven by Chamsys MagicQ (a professional lighting software) and the second one was actually connected to one of my Rasperry Pis and PiLight.

The first setup featured some moving heads and a range of LED fixtures, completed by a fog machine. The second consisted of a few LED PARs and two 50-LED WS2801 LED Pixel strings (of which only one was on the DMX bus).

Both setups were running all night, and there were no troubles at all, and I'm very pleased with that. I'd say that this was a very realistic test, and the outcome is very encouraging to say the least. I even had some time to work on the PiLight core software and the Android app.

Here's a short video of the big setup in action (and yes, I cut the audio... it was pretty bad):

The DMX Experience (Part 5 - the build)

So... since I did have to wait for my parts longer than expected this time (and I still wonder how that postal code got messed up on the parcel) and I couldn't really prepare anything ahead for this, it took me a little longer to finish.

After I finally got all the parts I needed and verified their board footprints (yes, those optocouplers are really that large, they seem like DIP-8 with cut leads) I etched and drilled the prototype board and started populating it. I started off with the microcontroller section so I could try to flash the firmware, but I was unlucky: I simply couldn't get the bare controller to show up in the USB device list. Thus, I was unable to flash any firmware over USB. Well, I'm happy I included the ISP header as a backup, because at least that one worked without a hitch.

While testing the DC-DC bridge I measured that the secondary power on my board was not really working as expected, and noticed that the IC was getting really hot. After some debugging I found out that I had accidentally reversed the polarity on the converter outputs. D'oh! The best I could think of was to unsolder the output pads and cross them over with some wires to properly power the circuit, which turned out to be an acceptable fix (at least for a prototype).

After populating the rest of the components, I hooked it up to my Raspberry Pi et voilá - it worked right away, at least the output (I'm still not done programming the input side).

So, with all that done, here's a little update on the Todo List of part 1:

• Testing: Well, that is pretty much an ongoing task. My two LED PARs work perfectly, but that hardly counts as extensive testing.
• PiLight Integration: Works perfectly as an output, but no work has been done on the input side.
• DMX Input: no progress so far, except for the fact that the hardware has been included in the build.
• Configuration: I can receive the configuration in the firmware by now, and I have started interpreting it with the AVR timer. Parameter storage to EPROM still needs to be done.
• Galvanic isolation: Included and seems to work (at least I got rid of that nasty ground hum the first prototype had). I still need to evaluate if it really is effective against a few hundred to thousand volts.
• Packaging: Well, I still need an enclosure :)

To round things up, here's a few pictures of the result:

Close-up view with LED PAR

Up and running with my new Raspberry Pi 2

The DMX Experience (Part 4 - new design)

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!

The DMX Experience (Part 3 - the real world)

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:

Stay tuned for more!

The DMX Experience (Part 2)

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):

To be continued!

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!