Automation Progress – Light Alarm and Remote

If you haven’t heard about my ‘home automation’ project, you should probably read this first.

This weekend was rather productive. I managed to get my light alarm working! I wrote escheduler, which is something like crond, but calls functions, instead of running programs. It’s also more limited, since it only schedules events on a weekly basis.

Beaglebone with a more 'permanent' radio setup

Beaglebone with a more ‘permanent’ radio setup

Escheduler runs on the beaglebone, which is currently my ‘home server’. The current set-up turns on the light behind my bed a few minutes before I’m supposed to wake up. Eventually there will be a whole fade-in period, but I just wanted to get something working. I left it running overnight, and sure enough, the lights turned on on time this morning!

Previously, the only way to control the lights was to ssh into the beaglebone and run swrite with the radio commands. You might not think so, but ssh-ing into the server and typing commands from a smartphone in bed at 6am is not as easy as it sounds! To make things easier, I decided to make a web interface I can use from my phone.

Simple RGB LED controller in smartphone browser

Simple RGB LED controller in smartphone browser

It took longer than expected, but I ended up using the twitter bootstrap. I haven’t done any web development in several years, so I had to re-learn a lot of things. In the end, I just set up a few buttons to turn the lights on or off. When clicked, there’s an AJAX request in the background to a php file that calls swrite to send the commands via the beaglebone radio. Next up will be controlling the actual colors from the web interface, as well as viewing and editing the alarms.

Here’s a quick video of the remote in action:

Beginnings of Home(ok, apartment) Automation

I’ve been neglecting my projects for a while, but I finally decided to stop being lazy and started working on them again. Several of my old posts deal with msp430′s and cc2500′s, but they’re mostly hardware updates and examples of changing lights to music. Now that I have a semi-stable platform and decent libraries, I figured I might as well do something useful with them.

My ‘end goal’ is to be able to control things like lighting and temperature automatically(and/or remotely) as well as gather data about the environment(temperature, motion, air quality, etc.) As usual, the first thing I did was start designing the whole system in my head and over-complicating things. I wanted to do a fancy server with flexible communications protocols, which got overwhelming pretty fast. After some time without getting anything done, I decided to start fresh and do small, manageable, tasks that eventually will end up being the full working system.

The first task I decided to do was to get my beaglebone talking to my cc2500 radios. I didn’t want to waste time trying to figure out how to get SPI and interrupts working on the beaglebone, so I went for the simpler solution and put an msp430 to control the cc2500. I say simpler because I already had a uart-to-msp430-to-cc2500 bridge working, so the only new thing was figuring out the uart on the beaglebone. Luckily, there are several good posts about it online.

Beaglebone with CC2500

The “Server” — Beaglebone with CC2500

Once I had my ‘server’ talking to the radio, I had to write a program to control it. Again, I could write an entire, complicated, sever application, or I could do something much simpler to start. Since I’m currently only testing with wireless lighting, I don’t need the server to receive data. Instead of having an always running application that takes over the serial port, my swrite program is called from the command line each time a new packet is sent. While limited, this solution is enough for now.

Wireless RGB LED Controller

Wireless RGB LED controller mounted on bike rack

To start testing the lighting control, I mounted two RGB LED strips with controllers in my apartment. One is behind my bike rack in the living room, and the other behind my bed. The one behind my bed will eventually be tied to my alarm clock, so I can start turning up the lights before I wake up. Since my computer is not in my room, I use the one in the bike rack for testing.

Lights on Bike Rack

Lights on Bike Rack

So that’s what I have so far. It’s not terribly exciting, but maybe if I write about it, I’ll be more motivated to keep working on it. Right now I’m writing a program on the server that will allow me to schedule events. A bit like crond, but instead of running programs, it calls my own functions. The first test will be to set up the light-alarm. I hope it works!

RGB LED strip behind bed

RGB LED strip behind bed

Wireless Friend Finder!

The Wireless Friend Finder was my project for the Bring-a-Hack dinner after the 2012 Bay Area Maker Faire. I made it in a hurry, so it’s not terribly well documented.

The wireless friend finder is a device that will start buzzing when another device gets near. This can be used to find a friend in a crowd(or to stay away from someone you don’t like)! Here’s a quick video I did while I was prototyping the project.

The actual devices consist of an msp430 microcontroller a cc2500 radio, and an annoying buzzer. The devices are sending radio messages every second. If a message from another device is received, the buzzer starts going off. In order to make it slightly more interesting, they measure the signal strength of the incoming message and determine how long the buzzes last. The stronger the signal, the longer the buzz. Here’s a video of some outdoor testing. (I had to do it around the apartments to get an ok result. I tried doing it with direct line-of-sight across the parking lot, but after 300ft, it was still buzzing!)

Since the devices aren’t very nicely built, I was slightly worried about the airport security. Luckily, they didn’t even ask me to take them out of my bags!

Even though the project was for the bring-a-hack dinner, I carried it around while I was at the faire. I was surprised at the reactions it received. Many people were asking if I had plans to make these into an actual product!(And suggesting new features) Moms wanting to find their kids, concert goers wanting to find their friends, burning man attendees, etc… The devices themselves are really cheap, under $10 each, so who knows…

Ian from DangerousPrototypes was nice enough to ask a few questions about the friend finder and put it online (along with other awesome interviews!):

So that’s the wireless friend finder… If you’re interested, you can get the code from github.

Wireless RGB LED Board (Part 2)

I finally managed to make a quick video of the build process for my wireless RGB LED controller. I used two cameras to do a time-lapse of the build. Unfortunately, they were using different frame-rates, so it took me a bit to get both of them synchronized. If you’re curious how the setup looked, here’s a (bad) picture of it:

Second Attempt at Dual-Camera Time-lapse

I uploaded the EagleCAD files for the board(schematic and PCB) to github:
I’m not sure what the ‘official’ way of making this open hardware, so I just put the OSHW logo on the latest revision. Here is the video of the build (with a quick demo!):

Wireless RGB LED Board (Part 1)

I’ve been working on my wireless RGB LED boards for a while now. I finally made an all-in-one PCB that includes an msp430, a cc2500 radio module, 3 MOSFETs for driving the LED strips and a 3.3v linear regulator. I know it’s not the most efficient setup, but right now I want to focus on software and need hardware that just works.

Board Schematic

The design is really simple. 12V in are passed through directly to the RGB LED light strip. A 3.3v linear regulator(that gets a bit warm while wasting power) takes care of the msp430 and cc2500. There are two LED’s for rx/tx notification (or anything else I might need). Since the MOSFETS can’t be directly powered by the msp430 (they need to be at +12V to turn on), I added some transistors to drive them.


Other than my human error (plugging in to the wrong place while trying to program), the board worked on the first try! I recorded several time-lapse videos of the build, but I haven’t had time to edit them. I suspect they will be part of a longer, more detailed, post with better explanations, code samples, etc…

Since I’ve already posted many videos of LED strips lighting up with the music, I’ll just leave you with a photo of the completed PCB.

Completed Board

CC2500 Project (Part 8) – Downsizing

I received my PCB’s yesterday (From Laen at, of course!). I spent last night attempting to solder all the surface mount components (and for the most part, failing miserably). I need to get some solder paste and a small oven for the next batch…

These components are tiny!

After soldering all of the passive components and msp430′s, I began the first set of tests. First I checked to see if all of the connections were good with my multimeter. Once I fixed any problems I found there, I tried powering the board and connecting with the programmer/debugger. Surprisingly, it worked almost immediately! (I had to connect power to the correct pins first…)

This is why I like my glass desk.

The next test consisted of flashing the two LED’s. Unfortunately, only one of them worked… I put together two devices, but LED1 didn’t work on either one! I decided to call it a night then. After getting back from work today, I continued my debugging session. Turns out that one resistor wasn’t soldered correctly (my multimeter test worked because I was pressing it down with the probe) and the second was a badly soldered LED.

Entire device MSP430 + CC2500 Radio

I continued the same test by toggling all of the IO pins (Port 1 and 2). I looked at each one with the oscilloscope to make sure it was toggling correctly. As soon as I started, things went downhill. Some pins toggled, but most didn’t. I went back and re-soldered all of the msp430 pins and tested them again. It was better, but half of the pins still didn’t toggle. I decided to probe the microcontroller pins directly, but they weren’t doing anything either. It had to be a software problem. It turns out that I was only toggling pins 0-3, and not 4-7. Once I realized my stupid mistake, I corrected it and everything started working.

New device in front of prototype it's replacing.

The final step consisted of soldering the CC2500 radios. Unfortunately I didn’t think my design through very well, since the radio modules have the crystal oscillator at the bottom, so it kind of sticks out at an angle. I changed the wireless RGB LED controller code to run on the msp430g2412 (which is what these use) and re-programmed them. Amazingly, the radios worked on my first try.

Look at all that free space!

I decided my old RGB LED controllers were taking up too much space on the breadboards, so I replaced them with the newly created modules. They take up very little space and work just as well. I’m thinking of making the switching DC/DC power supply just as small and hopefully integrating it with the current device.

Another device next to the components it replaced.

Now that I have a semi-decent platform, I can start working on writing some awesome radio libraries. (Once I put together more radios of course…) I want to have a full home-automation system going in a few months. I’ll keep posting updates here.

CC2500 Project (Part 7) – More Lights and Power Supplies!

Here’s another quick update (with lots of pictures and a video!) I ordered another RGB LED strip from adafruit in order to test how my system works with multiple devices. I don’t have my PCB’s yet (I shipped them to NY by mistake…), so I had to build everything on breadboards.
My messy work space.

The main problem with my previous design is that it required two separate power supplies. The LED strip runs off 12v, while the microcontroller and radio run at 3.33v. I had a couple of MC34063A DC/DC converters laying around, so I figured I’d make a 12-3.3v converter. I also had an LD33V linear regulator, so I decided to try them both.

Device with linear regulator (left) and DC/DC switching regulator (right).

Unfortunately, I didn’t have the exact parts required to make the switching regulator, so I had to use the closest available. This produced an extremely noisy (± 400mV) output, which resulted in a non-working microcontroller. I was able to temporarily solve the problem with some decoupling capacitors, but I still need to get the right parts to make it more stable. What happened was that the microcontroller would start and then just hang or reset at random. At first I thought it was a code issue, but then I looked at the power supply… I’m glad I bought an oscilloscope, otherwise this problem would have been pretty hard to solve.

That’s a huge 0.33 Ohm resistor (It’s all I had…)

Since the DC/DC converter was not behaving too well, I decided to use the linear regulator with the other circuit. Dropping 12v to 3.3v with a linear regulator produces a lot of heat. I had to get a heat sink, otherwise I would burn my hand if I touched it. It’s a huge waste of power, but it works for now…

Dropping from 12v to 3.3v generates a LOT of heat. (Thankfully, I had a heat sink)

In order to drive the second LED strip, I had to put together another RGB LED driver board. It’s just three MOSFETs, along with some resistors and BJT’s to drive them. I connect the 12v power supply directly to these, and then connect it to the microcontroller board’s power supply. The next thing to do will be to have them all on the same PCB…

RGB LED Driver (There are some surface mount resistors and transistors on the other side)

So what did I end up doing with these? Well, I put one on top of a shelf, and the second under… Ok, I don’t know what it’s called. It might be a kitchen counter-top, but I’m not sure. Here are some photos that will hopefully make more sense.

Shelf plus LED strip.
I’m not sure what that is called(counter-top?), but that’s where I hung the second strip.

I tried getting a video of the whole setup, but my camera doesn’t seem to like low light situations. It looks much better in person!

CC2500 Project (Part 6) – Reorganizing

This post is mostly about software, so I’ll keep it short.

I re-arranged most of the code so it hopefully makes more sense. My goal is to make the main code hardware agnostic. That way if you want to use a different device, you just change which drivers you’re using, but your main code stays the same. Eventually I’d like to be able to support multiple devices from multiple manufacturers.

For a much better description, check out the page (and code) on github here:
(The README file should have some information)

To keep things interesting, here’s a quick video on what I was able to do with the current setup. The RGB LED controller(msp430g2452 + cc2500) is wirelessly connected to the PC(msp430g2533 + cc2500 + usb-to-serial converter).

CC2500 Project (Part 5) — SPI Problem Solved!

So I wrote last week about getting UART working on the MSP430G2533 but having major problems with the SPI interface… I was so frustrated that I caved in and purchased a Salae Logic analyzer. It finally arrived today, and I had a chance to test it.

Salae Logic in action!

As soon as I opened the box, I connected it to sniff the SPI lines between my msp430 and cc2500 radio. It took me maybe 10-15 minutes to set up everything, including the Salae software to decode SPI on the fly. I ran my radio-setup code and observed the logic output. It seemed like something was happening, but it wasn’t quite working.

First capture with msp430g2533
To get a better idea as to what it should look like, I connected my msp430g2452, which had a working SPI link with the radio. The first thing I noticed was an error saying that the clock polarity was inverted. Aha! So the SPI clock on the 2533 was low when idle, while the specification says it’s supposed to be high.

So I went into the datasheet and figured out how to fix the clock problem.

‘Correct’ capture with the msp430g2452

I tried it again and, not surprisingly, it failed. Looking more carefully at the MISO/MOSI lines, I realized that they were backwards! Turns out that the SPI IO pins do not match between the msp4302533 and the 2452. I swapped two wires and everything started working!

While I was really happy I fixed the problem, this means that my previously mentioned PCB will only work with one of the two devices. My plan is to use the more expensive 2533 as a PC-to-radio bridge, since it has both a hardware UART to talk to the pc and hardware SPI to talk to the radio. The cheaper 2452 only has one SPI to use the radio.

Launchpad with cc2500 Radio and Salae logic

In the end, I’m still happy. The Salae logic was extremely helpful and easy to use. It took me less than an hour to solve a problem I hadn’t figure out in two days! Now I will be able to focus much more time in coming up with good radio libraries, instead of debugging silly problems.

CC2500 Project (Part 4)

I haven’t been working on this project lately, but I finally got back to programming yesterday. I got the MSP430G2533 which has both hardware UART and SPI. This one will act as a bridge between the PC and the CC2500 radio. It could also be used to drive a serial LCD.

I managed to get the UART working, but for some reason I’m having trouble with the SPI communication with the radio. I’ve been wanting to get a Saleae Logic analyzer for a while. Now I have a reason!

On the hardware side, I put together a breakout board for the MSP430 and CC2500. It only has a few passives and two LED’s along with the MSP430 and a header for the CC2500 module I’ve been working with. I put them on opposite sides to save space, but that caused some problems.

I want to have the radio and antenna exposed, which means the MSP430 needs to go on the other side. Unfortunately, this means that the pins are all backwards(Top-right is pin 1.) I’ll just have to keep that in mind while breadboarding.

Hopefully I’ll get the Saleae Logic soon so I can iron out these SPI problems. Once that’s done and I have these boards, you should start to see some much nicer projects (and better code!)

1 2  Scroll to top