In my previous post, I elaborated on how I reverse engineered the low level protocol the GE Color Effects G-35 strings used. It seems to have been quite popular, and several people have taken that information to hack their own G-35 strings to do cool and amazing things. But what about me? What am I doing with my strings?

Well, it's a bit late in the year to start putting together some sort of advanced choreographed light show, so I'm staying somewhat simple for now. No music, just a few different algorithmic patterns. And here's the kicker: I want to be able to control them with the web browser my phone too. Sounds like a job for… the ybox2.

Behold, the networked Christmas light controller in an Altoids tin:

In short: it works great. See for yourself:

I went to Costco the other day with my wife to pick up some Christmas lights. While there, I found the most awesome christmas lights ever: the GE Color Effects G-35.

This string contains fifty "bulbs". Each bulb contains a red, green, and blue LED—allowing for any color to be produced. The biggest drawback is how you control them: there are 14 pre-set "programs" that you can select, and they are all pretty lame. However, with a little reverse engineering and an Arduino (or any other microcontroller) they can be made into the coolest Christmas lights on the block. If you buy several strings, you could easily make a large 2D LED array. The possibilities are endless. At $59.99USD for a string (A tad over $1 per node), these things are a steal for what you can do with them.

I wanted to share my efforts so that other people can give this a try. At the end of the post I have a link to the code I'm now using to drive my Christmas lights. Feel free to use it for your own hacking endeavors.

So far I've reverse engineered both the radio protocol and the protocol used on the LED data bus. Of the two, the LED data bus protocol is by far the most interesting. So that's where I'll start…

UPDATE: See follow-up post here.

This is an experimental capacitive soil moisture sensor I am working on. Just thought I would share.

These images are actually a little old, but I don't feel like making new ones. The new revision uses a slightly different mechanism for measuring capacitance that should be more accurate.

I'm using capacitance to measure the moisture instead of resistance because it allows me to void having any metal directly touch the soil. Resistive moisture sensors are not practical for semi-permanent use due to electrode corrosion. This moisture sensor should work indefinitely with no corrosion.

Assuming it will work at all, that is. We shall see.

I plan to have several of these daisy-chained around my yard. At the end of the chain will be a solar-powered wireless micro-controller unit which will allow me to read any of the sensors from the wireless home automation network I'm building. The goal is to use the moisture information to help the irrigation system know when it should water less than it normally would.

My hobby is complicated.

I made the mistake yesterday of attempting to do a firmware upgrade on my AVR Dragon from my Windows XP virtual machine running on VMWare Fusion. VMWare Fusion hadn't given me any trouble with USB devices up to that point (quite the contrary), so I didn't think anything of it.

Boy was I wrong. Bad idea. For whatever reason, it does not work. I keep getting the same error after about 11 seconds:

Firmware upgrade failed while preparing write.

I'm going to try using a real Windows machine from work today and see if I can get this thing working again. In the mean time I'm reduced to using my USBtinyISP. Unfortunately it doesn't do JTAG programming, so I can't update my RZUSBsticks until I get my dragon working again.

—*sigh*—

Update: Found a Windows machine here at work and updated the device with no problems. Back in business. I think the dragon update program was expecting the device to appear back on the USB bus rather quickly after a reset, but with the VM in place it takes a about 100-200ms. I think this was confusing the firmware update program, making it think that something had gone horribly wrong.

Nothing quite celebrates one's geekdom like showing off pictures of an OLPC XO-1 using an RZUSBSTICK 6LoWPAN network adapter. I couldn't resist sharing.

Don't give me that look. I needed to test my CDC-ECM additions on a Linux box, and it was the closest one handy. It's all in the name of science. SCIENCE.

You can see it actively (and successfully) pinging ff02::1 on the XO-1's screen.

The Contiki distribution comes with some very useful firmware that turns the RZUSBSTICK into an ethernet interface. This firmware is informally called "Jackdaw".

Unfortunately, out of the box it only supports RNDIS and CDC-EEM (Ethernet Emulation Model) USB protocols. There is no RNDIS driver on the Mac (and likely never will be). There is no usable CDC-EEM driver either.

There is a standard protocol for USB ethernet devices, and that is CDC-ECM (Ethernet Control Model). In order for the Jackdaw firmware to ever 'just work' on a Mac, someone is going to need to add support for CDC-ECM to the firmware.

I've been intending to do this for a few months now, but only recently managed to scrape up the time to put all of the pieces together. After a good 8-10 hours of work this weekend, I am now pinging my RAVEN board directly from my Mac using a RZUSBSTICK running my updated Jackdaw firmware.

I'll be sending my changes upstream so that they can hopefully be included in the next Contiki release. If you are curious or just impatient, you can grab the changes from my private subversion repository here.

Update: I've moved the changes to their own branch here. I'm also working on merging the changes into contiki-2.x, (which you can find here), but that is still a work in progress.

Additionally, you can find builds here that are ready to upload to a RZUSBSTICK.

I have been using Parallels for most of my Windows and Linux virtualization needs, but it's shoddy USB support has driven me over the edge. Time to cut my losses and give VMware Fusion a try.

The majority of software supporting tools (like low-level hardware debuggers) are unfortunately Windows-only or Linux-only. This means that if I want to use, for example, the CC-DEBUGGER, I need a virtualization system that does USB well.

Parallels has given me nothing but grief so I'm hoping that VMware Fusion does a better job. I'll post my findings.

I just wanted to share some pictures of another aspect of the same home automation project.

What I'm doing here is connecting a TI CC2520 802.15.4 transceiver to a ybox2, using a break-out board that I designed a few months ago. I'm in the process of developing the CC2520 driver for the Propeller now, and hope to have it working in a week or two. After that, I'll be developing a 6LoWPAN stack for the propeller chip. Fun times.

So what are the possibilities?

• 802.15.4 tunnel, for connecting two Zigbee networks in different locations.
• 6LoWPAN to ethernet bridge.
• 6LoWPAN border router.
• TV-based 802.15.4 network monitor

I'll be exploring all of these options in the weeks to come.