Computer Controlled Christmas Lights

Brought to you by Jason Malinowski, Justin Beck, and Chris Meyer

Getting it Running

The obvious problem with trying to do something like this is, well, controlling the lights. For most people this sounds impossible, but as long as you have a little knowledge about electronics it's really not that hard to do. The bigger problem we had was the time limit; we just didn't have time to build some sort of a control board. However, it just so happens that Justin already has a board, called a relay board. For the uninitiated, a relay board is simply a piece of hardware that is essentially a bunch of switches that we can turn on and off automatically.

However, as mentioned in the summary, this board isn't intended to be used as a relay board. Instead, this is an old piece of equipment from the late 80s that is designed to control locks. You can think of this as a device that runs those locks that you unlock by holding up a security badge to a little panel by the door (although this particular piece of hardware probably predates this.) So, we really give it LOCK and UNLOCK commands, which are equivalent to opening and closing a circuit.

So, the first challenge was just trying to get the board to even turn on and being able to communicate with it. It only took a few minutes to fire up HyperTerminal, remember the hardware communication options, and to get a prompt up from the board. However, the prompt wasn't the prompt we were expecting: YOUR PASSWORD? Remember that this is a device intended to control security systems, so imagine what would happen if somebody could simply connect to the board and suddenly unlock all the doors in a building! So, Justin called home, and his mother was able to magically find the manual (mothers are like that), which told us the default password was "new". How clever.

Who in their right mind solders in batteries?So, after finding the password, we were off to the terminal, where we could start to issue commands off to the relay board. Success! One other little problem was in the way. We were currently accessing the board at 300 baud, which basically means "slow." So after a little digging around (at 300 baud) we found the command to change the rate. Of course, we have to reboot the board for the changes to take effect. But, after rebooting, the settings magically changed themselves back to 300 baud. Strange. After a bit of digging around in the back of the board, we realized why this was happening. Settings were preserved in memory by a 3.6 volt battery that was soldered directly to the circuit board (so evidently this predates flash memory!) This was easily fixed by simply duct-taping two AAA batteries in series and putting this contraption in parallel with the battery. So, this time our settings finally saved, bringing us up to a 9600 baud connection. Amazing how fast it is!

So now that we could control the board, it was time to do a bit of testing! We grabbed a small 3V motor just to turn on and off to make sure it works, testing each of the channels that we can control. So, then time to test a string of lights! Since we simply must connect lights through wire contacts that we must screw down, we had to cut the plug off of a set of Christmas lights donated by Justin so we had raw wire to work with (which was covered up with duct tape for safety...we didn't have any electrical tape yet.) The cut off end of the plug was then used as our power source, which we also attached to the contacts. The wonderful picture of this mess is to the right, but in the end, it worked!

Eventually the system was improved as Chris brought in extension cord ends that we could cut to attach to the board; this lets us plug in strings of lights directly without having to cut them (which is both safter and also allows us to reuse the lights in the future.)

Part Three: Exploring the Software Side >