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

Average energy usage in 15 minute increments from all of the days in the data set.

 Average energy 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.

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

CC2500 Project (Part 3)

Here's an even smaller update!

Since the MSP430G2452 doesn't have a hardware UART, it's not very useful in communicating with the computer. I could use the bit-banging method to get 2400baud, but I didn't feel like figuring it out.

For my thesis, I implemented a serial-to-radio repeater using the EZ430-RF2500 and a USB-to-serial converter. I was able to modify the code to get it working. It ends up being a 19200baud link. For some reason, I can't get the processor to run at 16MHz without it giving me problems. Since I don't wan't to figure those out now, I'm running it at 1MHz, which prevents me from doing the usual 115200baud. (Not that I really need that speed.)

I then wrote a quick processing sketch to capture audio and send RGB values out the serial port to the microcontroller.

In short, I can now sync the lights to the music wirelessly!

Here's a quick video demo (As you can probably tell, I'm really happy it worked!):

CC2500 Project (Part 2)

Here is a quick update on the project's progress.

Today I was able to get the radio libraries working better and actually set up constant radio communications across a room. I also wrote an RGB led controller using PWM and combined them together.

Here's a brief video of the result:

So far it's just one microcontroller generating RGB values and sending them to another one. Now I need to work on getting the PC to talk to the first microcontroller so I can control the lights with my computer.

Here's a demo of what I want it to do later. I have it working in the video, but it's fully wired and uses an ARM Mbed for control.