Recently I’ve been playing with something I think is somewhat of a holy grail in LED enthusiast circles: the addressable RGB LED strip.

Non-addressable RGB strip (meaning you can turn the whole strip a particular color but not any individual LED) is becoming easier to find in the market but a RGB strip where you can actually control each LED individually has only been the subject of geek fantasy. Every time I’ve done something public with common RGB strip, someone has come up to me and said “oh wow man, can you control those LED’s individually?”. No, sorry, with those strips you couldn’t — but with this strip you can!

So where do these fabled strips come from? Well, the one I’ve been playing with fell into my lap a few months ago — tossed there by my friend Dan who got it from a shady-looking factory in China while there evaluating LED video wall products. I’ve asked him for the name of the factory but he’s so far been drawing a blank.

At the time he assumed (as did I when I first saw it) that the strip consisted nothing more of RGB LED’s hooked up to standard standard shift registers, similar to how I built my single-color LED serial strip. This turns out not to be the case and that the chips driving the LED’s are actually packed with a bit of smarts to them.

This became evident when I built a simple test program which treated the strip like a common shift register but failed in confounding ways to work. Eventually I had to cut away some of the silicone liner on the strip to get a closer look at the driver chip. The chip turned out to be a “HL1606″, nothing I’d ever heard of. A few hours of online research left me with a datasheet for the HL1606 written only in Chinese and a single posting by one “John Cohn” from September 2007 looking for anybody who had more information on how to drive the chip. The posting didn’t get any useful replies.

I tried running the datasheet through Google translate which was somewhat successful but left me scratching my head over the precise way to interpret sentences like this:

When a data bit for the Road 10 (D2D1 or D4D3 or D6D5) and latches valid, the corresponding LED driver output state for Prescribed changes gradually, when the change to keep the brightest light of the state, until the new data is entered and effective latch.

It *sounds* like english, right? Yeah, anyways, trying to decipher the datasheet lasted for only so long before I got pulled away to more important distractions and the RGB strip sat on my bench untouched for months.

Then Maker Faire happened and, by some freak chance, while I was chatting to people about the MonkeyLectric bike wheels, a guy came by wearing a most eye-catching headband. The headband was constructed out flexible circuit board material on which RGB LEDs were mounted and were clearly being controlled individually. Obviously, this was a guy I had to talk to. After a short conversation I learned that he had found the strip from an electronics booth in China, the strip was built using HL1606 driver chips, and he too had had a heck of a time (and only partial success) figuring out how to drive them. We exchanged contact info and a pledge to get in touch after the faire to share data and geek out on the strips. It wasn’t until after I had gotten home did I piece it together that this guy was none other than the “John Cohn” whose lonely, unanswered call for help in 2007 was the only evidence I was able to find that anybody else in the world was playing with these strips.

Maker Faire rocks.

Anyways, shortly after we got to our respective homes, John sent me a copy of the datasheet in Chinese which I had already found earlier as well as the PIC code for his headband. The PIC code was the missing key to the puzzle and by studying it in conjunction with the machine-translated datasheet I was finally able to get my head wrapped around how the chip worked.

Below is a short video showing off a basic rainbow-scroll (the “hello world” of addressable RGB strip effects):

So that nobody has to ever go through what John and I went through to get these strips to work, I wrote an Arduino library for the HL1606 and open sourced it. It’s still a bit unpolished and under-documented but it’s feature-complete in the sense that it can control all of the features of the HL1606.

Oh, and before anybody asks, I don’t yet have a solid source for more of the strips but I’ve found them being sold online. So far I’ve only been able to find them being bundled with a controller and I’d like to find a source selling them without one (hopefully at a reduced price). To hunt them down on your own, the keywords to look for are HL1606 and 5-volt operation. The 5-volt operation is actually the key distinguisher, as all of the non-addressable RGB strips run on 12V or higher.

Update 6/18/09: I see John’s posted an Instructable on his Too-cool Rainbow Headband. In it he documents more what you need to do to drive the chip and even suggests some possible suppliers for the strips. Check it out (and if you like it, give him a vote for the ‘Get the LED Out’ contest he’s entered it into

So part of the reason that I’ve been so slack with the postings this year has been because I’ve been collaborating on this project as well. We’ve been sorta pseudo-hush about it as we’ve been developing it but, now that we’ve shown it in its full glory at Maker Faire, the cat’s outta the bag.

They’re in! I’ve finally gotten back the first factory run of serial LED strips and they look awesome. 50 meters of LEDs on a string and I’m really quite happy with them. I’ve tested about half of the batch and so far haven’t run into any build-quality problems. They just seem to all work.

In particular I’ve been impressed with how flexible the strips have been and how resilient (so far) they’ve been in the face of bending. Most LED strips that are available on the market now are coated with a rubbery like clear flexible coating which protects them from the elements and gives them additional strength. The factory was able to apply such a coating but I opted out of it since my intended application was indoors-only and I didn’t want the additional bulk. Also having them uncoated lets me change the color of the LED’s later if I need to. Thus without the coating these strips are significantly more fragile than your typical LED strip and yet they’ve put up with all the punishment I’ve dished out to them so far.

I actually didn’t receive these till about a week and a half or so before Maker Faire 2009, leaving me little time to put together any sort of serious demonstration since I was focused on making sure the 4-spoke monkeylectric wheel was running solid. However I brought them to the Faire anyways and at the very last second put together a primitive demo by stringing a couple 5-meter rolls around our tent with zipties and packing tape and driving them with an Arduino. I thought it all looked really gimpy but I got some nice comments on them anyways.

A surprising number of people asked me if I were was selling the the strips or if I was planning to. You know, that’s one of those interesting questions that the more people ask it, the more I’m inclined to say yes.

Someone else asked me how I was driving the strips. For the demo, I hacked together a simple controller using an Arduino with a Proto Shield.

As far as how you drive the strips (asked by a commenter in a different post), here’s what you need.

   Pin 1 = V+ (4 to 7 volts)
   Pin 2 = LATCH
   Pin 3 = CLK
   Pin 4 = DATA
   Pin 5 = V-

LATCH, CLK, and DATA are used just as with a typical shift register. DATA gets latched into the shift register on the rising edge of CLK but the state of the shift register doesn’t affect the LED output pins until LATCH is driven high. Thus if you tie LATCH high all the time (as I do for the chasing-LEDs effect), then on every rising CLK edge the whole chain of LED’s will shift down by one. If you want to have more control, you can keep LATCH low and clock in a whole chain’s worth of new data before driving LATCH high again. Do this fast enough and you can give the illusion that you’re controlling the LEDs individually.

My friend Ian Hanschen (aka Furan) has been doing a number of impressive projects involving LED’s and electronics. If you enjoy the sort of material I write about here, definitely give his blog a visit too.

This year I gave my sweetheart a LED Valentine.

16 LED’s surface mounted onto flexible circuit-board material and driven by a small microcontroller. The LED’s animate a pattern which pulses (approximately) to the beat of my own heart.

The circuit incorporates 2 STP08DP05TTR constant-current shift registers (so I didn’t
have to try and place 16 resistors for the LEDs) driven by an ATTiny45V microcontroller.

The circuit itself was toner-transfer etched onto DuPont Pyralux flexible circuit-board material. The Pyralux is pretty cool stuff; it feels like a tough plastic tissue-paper that crinkles when you flex it yet stands up to a reasonable amount of ham-handing (lucky for me and my particularly ham-like hands). The circuit traces were only 11mil wide and yet they stood up to my hand-soldering on this material without breaking or lifting off. The stuff is quite handy when you need a printed circuit but don’t want the bulk of a standard PCB.

The software pattern consists of two sets of chasing LEDs sliding past each other at different speeds. This results in a visual pulse harmonic which I tuned to the approximate speed of my own heartbeat at the time of coding.

The card was presented alongside a tasty breakfast-in-bed and was well received.

Since my last posting, Synoptic Labs has been transplanted to new, larger digs in Sacramento, CA. As a feature of the new location, we now find ourselves with a full garage which has substantially increased our storage and work area. However, this garage opens up onto a busy downtown street with a lot of foot-traffic and a bit of that traffic is from scavengers — people who routinely comb the neighborhood (usually early in the morning) looking for recyclables or, frankly, anything that isn’t nailed down.

The door is opened by remote control and, as we’ve found on numerous occasions already, it’s all too easy to inadvertently hit the remote and open the door without realizing or just forget to close it. More than once we’ve woken up and found that the door has been wide open all night long; the fact that we haven’t lost any tools or equipment because of this astounds me.

Knowing that our luck wasn’t going to hold out forever if we keep leaving the door open, I decided something had to be done. So I hacked together a internet/mobile-phone enabled garage door monitoring system which will notify us if the door is left open during the night.

Using a simple push-switch from my electronics junk box and the parallel port on my FreeBSD server, I was able to wire the switch into the parallel port and write a very simple program to check whether or not the switch was closed. This was the first time I’ve ever hacked with the parallel port so it took me a little bit to figure out the pinouts. However, I was delighted to find that FreeBSD had the awesome ppi(4) interface for the parallel port and that it was already installed and running on my server. It only took me a couple minutes to write a simple program which could check the status of my switch and thus report on the state of the garage door.

Once that was done I whipped up a simple shell script which would run out of cron every minute and log the status of the garage door. I also whipped up a simple CGI script to so the status could be queried on the web and incorporated that into a live-status page on our private wiki. This makes it easy to check on the garage door from our mobile phones.

The final touch was setting up a Twitter account for the garage door and posting updates to that account. Now we’re able to get SMS notifications whenever the garage opens or closes. To minimize the chatter, the SMS notifications are generated only if the door is opened at night.

And thus with about $0.05 worth of parts and an afternoon’s worth of work, we now have a mobile phone/internet-enabled garage status monitoring system to alert us if we ever leave the door open again.

garagelog.sh — run out of cron every minute

#!/bin/sh

./garageis > status/garage.now

# Hour past which we'll report updates to twitter
twitstart=22
# Hour before which we'll report updates to twitter
twitstop=6

username='yourtwitteruser'
password='yourtwitterpass'

hour=`date +%H`
minute=`date +%M`

if [ ! -f status/garage.then ] || ! cmp -s status/garage.then status/garage.now; then
	if [ $hour -ge $twitstart -o $hour -lt $twitstop ]; then
		/usr/local/bin/curl -u $username:$password \
			  -d status="`cat status/garage.now`" \
			  http://twitter.com/statuses/update.xml > /dev/null 2>&1
		echo `date "+%G-%m-%d %R:%S garage: "` `cat status/garage.now` "(twittered)" >> garage.log
	else
		echo `date "+%G-%m-%d %R:%S garage: "` `cat status/garage.now` >> garage.log
	fi

	mv status/garage.now status/garage.then
elif [ $hour -eq $twitstart -a $minute -eq 0 ] && grep -q open status/garage.now; then
	# make sure we send a twitter if the garage is open when our
	# sensitivity window starts
	/usr/local/bin/curl -u $username:$password \
		  -d status="`cat status/garage.now`" \
		  http://twitter.com/statuses/update.xml > /dev/null 2>&1
fi

garageis.c — report status of garage door

#include <fcntl.h>
#include <errno.h>
#include <stdio.h>
#include <dev/ppbus/ppi.h>
#include <dev/ppbus/ppbconf.h>

int fd;

int
main()
{
	uint8_t  val;

	fd = open("/dev/ppi0", O_RDONLY);

	if(!fd) {
		perror(NULL);
		return(1);
	}

	// turn on data bits
	val = 0xff;
	ioctl(fd, PPISDATA, &val);

 	// read status flags.  if nBusy is 1, then garage is closed.
	ioctl(fd, PPIGSTATUS, &val);

	if ( val & nBUSY )
		printf("Garage is closed.\n");
	else
		printf("Garage is open.\n");

	// turn off data bits
	val = 0x00;
	ioctl(fd, PPISDATA, &val);

	return(0);
}

Progress continues on the Serial LED strips project. I’ve assembled a fair number of the prototype strips and have been experimenting with a few ideas. I’m really excited about this project… I keep thinking of new projects I can do with these little strips. However for now my focus is on testing the ones that I have in prep for a larger scale production run.

Also I got a lot of positive feedback from people at the Bay Area Maker Faire on the prototype strips I brought mounted on black acrylic (slapped together at the *very* last minute).

Today I set about testing the resistance on the power and ground rails. The resistance on these rails imposes a maximum length of serial strips that can be chained together before power needs to be re-tapped into the chain. Much to my pleasant surprise, the resistance that I measured closely matched my predictions. I had predicted a resistance of 5.70 mOhm on VCC and 6.48 mOhm on GND and I measured 5.79 mOhm on VCC and 6.42 mOhm on GND respectively. Not bad.

Video of the prototype strips in action after the jump.

My prototype boards for the striplight came in this week, woohoo! Now starts the process of putting the design through its paces and making sure it works but before that can begin the boards have to be first assembled.

According to the guys over at SparkFun there’s no better way to do bulk surface-mount soldering in the home than with skillet reflow. According to universal truth, there’s no better use for a skillet than for making delicious fluffy pancakes. Thus it follows that any activity combining the two must be a doubleplus good.

Besides, heavy metals poisoning is the sweetest sauce.

Seeing as this was my first foray into the world of skillet reflow I have to say that so far I’ve been impressed with the results. The only tricky part is placing the little components on the board without bumping the ones that you’ve already placed. Once you have the solder paste down and all of your components placed on the board, there’s nothing more to do than simply place the board on an electric skillet, turn it on, wait until all the solder has melted, then turn it off and let it cool. That’s it.

The biggest obstacle was finding the soldering paste. A number of places sell it but a lot of them insist on overnight shipping with cryo-packing and the shipping often comes out to be more expensive than the paste itself (which is already quite expensive since you’re forced to buy far more than you’ll ever use). Phil was so kind however as to point me to Ameritronics who will gladly sell you solder paste in small quantities at a reasonable price and the stuff they sell is formulated to have a greater shelf-life without refrigeration.

I’ve now reflowed two complete boards and already I found the second one substantially easier to do than the first (which already wasn’t that bad). I do still seem to have a problem in putting too much solder paste on the IC pads resulting in solder bridges. However a little touchup with fluxed solder-wick fixes this. I’m probably using too wide of a needle for dispensing paste.

Rob and I have recently been talking about doing some wireless projects. A friend loaned us a Cypress CYM6935 module which is an evaluation module for the CYWUSB6935 chip and today we attempted to hook it up. We chose an Arduino board simply for convenience though connecting the module to it actually took the bulk of our time today since the 2mm pitch pin headers on the module won’t fit into a breadboard. Also, the Arduino runs at 5V and the Cypress chip can’t tolerate voltages that high so we had to drop the 5V signals from the Arduino down to 3.3V. Fortunately I had a Futurlec 5V to 3.3V level shifter board on hand so that problem was easily solved.

Once we got the module wired into the Arduino we had to figure out how to communicate with it. Thankfully, that work has largely been done already and we borrowed code written by Lars Englund (available here) to test the communications with the chip. This code was written for an ATMega8 so a few of the port definitions needed to be changed to make it run on the Arduino’s ATMega168, but this was fairly painless.

It should be noted to avoid possible confusion that, while we used the Arduino board, we did not use the Arduino programming environment to compile and run Lars’s code. His code is not compatible with the Arduino framework and would require significant porting. (this is not a criticism of the code but rather a disclaimer intended for those who may find this post. It’s not commonly understood that the Arduino hardware is perfectly happy functioning without its development environment).

Anyways, once we got the code to compile and talk back to us via the USART and once we got the Cypress module wired up to the board, we were pretty much done. Much to our surprise the software found the chip and was able to talk to it on the first try. Honestly, we had expected to be chasing stupid wiring mistakes for another few hours so this was a pleasant shock.

That’s pretty much where we left it. We got the software to recognize the chip and talk to it and we called it a productive day. Now what’s left to do is get it to scan the wireless spectrum and send that data back to the host computer for analysis and display.

(Note: these photos were taken not by me but by my friend David Lindes, who has a ton of other amazing photos on Flickr)

It’s 3 a.m. and a phone rings in the White House…

Or actually, it was about 3 p.m. and a phone rang in my pocket. By luck the phone happened to be mine and on the other end of it was 3ric asking if I’d be able to help with a project that evening. Seems he had acquired about 10 liters of liquid nitrogen and among other things was hoping to use it to do some high-speed flash photography of frozen things shattering into a million pieces upon being shot with a pellet rifle.

All was well and good and according to plan, except for the flash trigger, which was stuck in the mail somewhere. Could I hack one together by evening? Thus is how I got my project for the day.

A flash trigger for high-speed photography is a really simple device. Basically all you need to do is take an audio signal and use that to trigger a flash if the signal exceeds a certain level. Rather than muck about with $10 worth of op-amps, transistors, voltage dividers and a bunch of so-called “electrical engineering”, I splurged for the $2 solution and threw the equivalent of a mid-1980’s personal computer at the problem… i.e. a microcontroller. Specifically, a AVR ATMega168 (mounted on a $30 Arduino).

Long story short and after overcoming two rather significant obstacles (#1 being not having a microphone, #2 being not having a flash) we were able to kludge together a workable flash trigger in just a couple hours. With the flash trigger in place and David at the camera, by the end of the evening we had walked away with some decent shots.

(and made one *hell* of a mess)

(our peep torture from last year)

Ok, short story long, about those obstacles:

I didn’t have a microphone for the audio part of the trigger and was taking apart various junk devices I could find looking for something that could be used. I tried a a headset from a cell phone, a mouthpiece from an old telephone, and the miniature microphone from a junked CVS-brand single-use video camera. Unfortunately I wasn’t able to get any of them to make any meaningful wiggles on the oscilloscope but that’s probably because I had no idea how to properly drive a microphone (and little time to research it).

Thankfully, Jon boldly came to the rescue and brought in a couple of microphones, one of which was perfect. Also 3ric picked up a old guitar amp from a pawn shop which had a mic in port as well as a headphone out port so that took care of the problem of driving the mic and amplifying the signal. The mic went into the amp, and the amp fed directly into the Arduino via the headphone-out port. The oscilloscope showed that shouting into the amp resulted in a signal ranging between -2.5V to 2.5V on the headphone port. Since the Arduino can’t stomach a voltage below -0.5V on any of its pins, I had to bias the input +2.5V using a capacitor and a couple resistors.

The flash proved to be the stickier wicket. By around 7 p.m. I still hadn’t located a flash and the one in the disposable camera I had planned on using turned out to have been already destroyed through previous mischief. Thankfully Jon once again swept to the rescue by running out to the store and bringing back a new disposable camera. Taking it apart, we quickly discovered a new challenge: the trigger circuit requires you to short two wires that have a 300V potential difference across them. The common approach I’ve seen in other circuits people have made is to use an SCR to gate the flash pulse, but of course we didn’t have one (see a trend yet?). To the rescue this time was Phil who picked one up from Fry’s on his way in.

Since I already had my hands full integrating the audio signal and writing the firmware, Phil stepped up and took a swing at the problem of hooking up the SCR to the flash. The first attempt resulted in the unfortunate destruction of pin 7 on the Arduino. Apparently a significant negative voltage (-10V) had developed on the gate of the SCR and, as mentioned previously, the Arduino couldn’t stomach it. Unfortunately in the chaos I can’t remember Phil’s explanation of what went wrong but he quickly got to the bottom of it and the flash was soon triggering perfectly off of a different pin.

Don’t ask me why the universe works this way but at just the moment when the flash situation had been resolved, David walks into the lab and hands me a professional type flash. His flash will not only trigger with a 5V signal but will fire 10-20 times before the little disposable flash has recovered from firing once. Hooking this up to the Arduino was no harder than making a two-wire cable so we went with this flash instead.

Because I promised David, here’s the schematic for the circuit I wound up with.

The rest of the night was spent blowing to frozen smithereens anything we could get our hands on.

Here’s a screenshot of the simple GUI I wrote to control the flash trigger, written in Processing. The red lines signify trigger events. The white dots signify the audio level being read by the Arduino and the green line is the trigger threshold (adjustable by dragging with the mouse).

… and, for completeness, the source code for the firmware for Arduino and the GUI, in case anybody wants to horrify themselves with the abomination that is my rushed code.

simple_flash_trigger_src.zip