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: https://github.com/alvarop/eagle/tree/master/wirelessrgbled
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!):

CC2500 Project (Part 9) – Debugging

I just spent several hours debugging my cc2500 radio libraries. What changed you might ask? Two lines of code…

My Wireless RGB LED driver had been using the msp430g2452 microcontroller. So far it has been working great! Someone emailed me asking about the msp430g2533, and how it wasn’t quite working. I currently use the msp430g2203 (which is a cheaper variant of the 2533) as my PC-to-cc2500 interface, and it has been working for a while (or so I thought!).

I decided to begin testing the 2533 with the rgb led radio code. As you might expect, it didn’t work. I quickly pulled out my Salae Logic analyzer and connected it to the msp430-to-radio interface to see what was going on. To have an idea of what the signals should look like, I used the 2452. I spent a few hours comparing the two signal captures, measuring timings, read data in the microcontroller, etc… This is a ‘quick’ summary of my findings.

Difference between 2452 and 2533

The first thing I noticed was that the separation between the address and data bytes was different between the devices (Circled in red). The 2452 had about 1.58 µs separation while the 2533 only had 0.5 µs. I looked in the cc2500 datasheet and realized that as long as that separation is greater than 55 ns, everything should work, which meant that was not the problem.

Another thing I noticed was that the 2533 misread some of the radio settings. For example, it would read 0×03 instead of the actual 0×07. This suggested something was wrong with the bit timings. After some more messing around, I saw this:

Clock Edge Configuration

The 2533 was starting the byte transmission half a clock-cycle too early! This also means that it is trying to sample incoming data at the wrong time (which is why some of the data reads were wrong). After digging around in datasheets and code, I found the source of the problem to be this line in the SPI configuration:

UCB0CTL0 |= UCMST+UCCKPL+UCMSB+UCSYNC+UCCKPH;    // 3-pin, 8-bit SPI master

The problem was with the Clock phase select bit (UCCKPH). It was set to capture data on the first clock edge and change on the following edge. Clearing that bit configures it to change data on teh first clock edge and capture on the following edge.

So that fixed the communication problem, but there was still a problem. The first setting written to the c2500 after reset was not being saved. Looking at the earlier capture (Blue circles in first image), the cc2500 returns a status byte of 0×87, instead of 0×07. The MSB in this case means that the radio is not ready. The problem here ended up being in the cc_powerup_reset function. Turns out the function wasn’t waiting for the device to actually reset (just sending the reset command), so that first setting write happened while the radio was still restarting.

You can see the actual fixes in this git commit.

Not sure if you noticed, but I did mention that the msp430g2203 was previously working with the same (broken) code. My theory for this is that all it ever did was transmit data, so it never ran into the receive problems. Also, the mis-aligned data might have been read properly by the cc2500. Another thing was that the first setting that wasn’t saved wasn’t really important, so I never noticed. I’m glad I figured this out before trying to receive any data on the 2203…

Now that my radio library works with both devices that have USI (msp430g2xx2) and USCI (msp430g2xx3), I can start using them to make some more interesting gadgets.

 

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.

PCB

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

Migrating Blogger to WordPress Permalinks

I recently migrated my blog from blogger to WordPress. The migration was extremely easy with the automatic importer in WordPress. The only problem is that every single link on the web is pointing to the blogger generated permalinks, which do not match the new WordPress ones.

Since I still get some traffic from other sources, I decided to come up with a method to have the old links redirected to the correct new ones. If you have a list of the old url and the new url, you can use apache’s mod_rewrite to automatically redirect the pages without the user ever noticing. The problem here is coming up with that list of equivalent urls without spending hours doing it by hand.

The first problem dealt with getting a list of all the old blogger permalinks. Luckily, I found a ‘plugin‘ that generates a table of contents with links to every post. Unfortunately, it does it with JavaScript, so you can’t just right-click the page and view source to get the links. The way to do it with chrome is as follows:

First right-click over the generated links and select “inspect element”.

Inspect Element on Chrome

Once the inspect element window appears, right-click on the top HTML tag and select “Copy as HTML”. This will let you copy the JavaScript generated HTML. (If you had just clicked view-source, it might not have included that.)

Copy as HTML

Paste the HTML onto your favorite text editor. I saved it as “toc.html”.

The next step is to get all the ‘new’ links from the WordPress site. You can export an xml file with all the information in the WordPress settings. I saved that one as “wpexport.xml”.

Export XML from WordPress

Now that there are two files with the links buried in them, we need to extract them and match them. I wrote a quick perl script that reads both files, takes the urls, matches as many as it can, and spits out a csv file.

$ perl blogger_to_wordpress_links.pl > links.csv

Most of the urls were automatically matched, but a few were not, so I opened up the csv file in excel and filled out the rest. (It puts all of the unmatched urls at the bottom of the file so you only have to cut and paste, not re-type).

Example of CSV File with Links

Ok, so now I have a csv file with URL’s, but what I really need is a .htaccess file to actually do the work. I wrote another script to do that.

$ perl csv_to_htacces.pl links.csv > .htaccess

The .htaccess file should now redirect any traffic pointed at the ‘old’ blog and send it to the correct page on the new WordPress one. I did have to manually add a rule for my ‘about me’ page, but it sure was easier than manually doing 90-something posts! The .htaccess file should end up looking something like this:

RewriteEngine  on
RewriteRule 2007\/05\/first-week-of-summer-part-1-of.html http://alvarop.com/2007/05/first-week-of-summer-part-1-of [R]
RewriteRule 2007\/05\/first-week-of-summer-part-2-of.html http://alvarop.com/2007/06/first-week-of-summer-part-2-of [R]
RewriteRule 2007\/05\/mid-exam-week-update.html http://alvarop.com/2007/05/mid-exam-week-update [R]
RewriteRule 2007\/05\/new-phone.html http://alvarop.com/2007/05/new-phone [R]
RewriteRule 2007\/05\/one-down-four-to-go.html http://alvarop.com/2007/05/one-down-four-to-go [R]
RewriteRule 2007\/05\/slow-weekend.html http://alvarop.com/2007/05/slow-weekend [R]
RewriteRule 2007\/06\/5-days-left.html http://alvarop.com/2007/06/5-days-left [R]
RewriteRule 2007\/06\/boring-friday-and-rest-of-week-update.html http://alvarop.com/2007/06/boring-friday-and-rest-of-week-update [R]
RewriteRule 2007\/06\/early-morning-update.html http://alvarop.com/2007/06/early-morning-update [R]

That’s it!

CC2500 Project (Part 8) – Downsizing

I received my PCB’s yesterday (From Laen at dorkbotpdx.org, 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!

Smart Meter Fun (Part 1)

My current apartment has one of those ‘smart’ electric meters that can communicate with the power company directly over the power lines. A few months ago, I found out about a smartmetertexas.com, which lets you register and get logs of your power usage in 15 minute increments. I thought that was really awesome and signed up. The concept is really cool, but unfortunately, their user interface isn’t that great. It does, however, allow you to export all of that information in one large csv file.

After getting the file, I decided to write a small python script to get some more information about my usage. Right now it doesn’t do much, but it shows me information like daily usage, hourly (ok, 15 minute-ly) averages, and weekday averages.

Total energy usage per day in kWh
Averageenergy usage in 15 minute increments from all of the days in the data set.
 Averageenergy usage per day of the week

From looking at this data, I use the most energy on Saturdays (Washer, dryer, more tv than usual, etc…). It also seems that I use the most energy from 7:30-7:45am. That’s usually when I’m making breakfast and using the stove.

The next step will be to figure out how to automate the graphing process. Right now, I export to csv files and then plot with excel. Maybe I can use gnuplot or some python extension to do it all at once.

I’ll be putting the code I’m using up on github: https://github.com/alvarop/smartmetertexas_reader

Flying Experiments

I managed to go flying last Friday after work. Since no one else was able to come along, I decided to do some experiments with the camera.

Last time I mounted the camera on the rear window pointing out. This time I pointed it toward me, instead of out the window. I did a time-lapse of the first half and later on an actual video of the landing.

Not too interesting, but I figured I would share them  here.

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: https://github.com/alvarop/msp430-cc2500
(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.

1 2 3 10  Scroll to top