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 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!

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.

Getting started with Arduino

Today I came up with another nice little contraption:

Now you're probably wondering what that is. That question is pretty easy to answer: From bottom to top, that's a Raspberry Pi driving an Arduino driving a PWM board driving a 10-LED-bargraph board.

Not satisfied with this answer? I can understand that. There's more questions behind that. Let's start with the less obvious things. Why the bargraph? It's a simple component that was readily assembled and was designed to be connected to the PWM board. It's a nice visual indicator of what's going on.

Why the PWM board? Again, the answer is: because I had one at hand. I could have used something else, but in combination with the bargraph again it gives a nice visual representation of what I was trying to accomplish.

So then the real deal is in the Arduino? From my previous projects I already know that I can directly interface the PWM board from the Pi. So basically there's not a real point in passing signals through an Arduino, or is there?

Yes there is. This is the first time I'm trying to build something Arduino-related at all, and this might actually turn out to be a nice advantage to future builds.

It's the connection between the Arduino and the Raspberry Pi that I will actually try to improve upon in the next days. So all this basically is going to be my testbed with a known-working state.

Right now I'm researching ways of replacing the connection with some kind of bus (RS485 seems very promising, and from there DMX is not far away) or even make it wireless (but most solutions appear to be rather expensive). If my idea works out, this could mean that I will no longer need a dedicated Pi for each of my devices, but instead a cheaper and smaller (think of the Mini!) Arduino would be sufficient. I might event manage to integrate the microcontroller directly onto my own boards!

And now this is an answer that hopefully gives you an insight on what really lies behind a few simple lights.

Oh, almost forgot, there's also a small video. Enjoy!