Slashdot Mirror
Linux, Apache, Perl, X10, Webcams... and Christmas Lights
An anonymous reader writes "Clement Moore writes
'Twas the night before Christmas,
and while not a creature was stirring (not even an optical mouse),
/.'ers were posting & moderating with squeals of delight.
When out on the Internet there arose such a clatter,
I sprang from my keyboard to see what was the matter.
I knew in a moment it must be Alek's Controllable Christmas Lights Webcam.
But remembered in previous years it was a hoax - /. said damn.
And then, in a twinkling, I realize Alek has done it for real — W'OH!
With 20,000 lights plus giant inflatable Elmo, Frosty, Santa, SpongeBob, and Homer Simpson — D'OH!
The X10 controls and 3 live webcams provide such clarity,
that it has raised over $70,000 for Celiac charity.
'Merry Christmas to all, and to all a good night!'"
'Twas the night before Christmas,
and while not a creature was stirring (not even an optical mouse),
/.'ers were posting & moderating with squeals of delight.
When out on the Internet there arose such a clatter,
I sprang from my keyboard to see what was the matter.
I knew in a moment it must be Alek's Controllable Christmas Lights Webcam.
But remembered in previous years it was a hoax - /. said damn.
And then, in a twinkling, I realize Alek has done it for real — W'OH!
With 20,000 lights plus giant inflatable Elmo, Frosty, Santa, SpongeBob, and Homer Simpson — D'OH!
The X10 controls and 3 live webcams provide such clarity,
that it has raised over $70,000 for Celiac charity.
'Merry Christmas to all, and to all a good night!'"
My string of networked RGB Christmas lights: http://www.youtube.com/treegeergb
The first attempt was in 2006 (ATTiny2323s, each controlling 4 RGB LEDs, wired together with an unholy amount of wire-wrap wire, with the controller chips soldered "dead-bug style" and wrapped in heatshrink.
The first decent-looking prototype was 2007. The first music-choreographed video was from 2008, with another one from 2009. I haven't made any new music videos since then, but the lights still work fine. My goal for next year is to assemble a bunch more, and redo the controller to use an Android tablet (or old Android phone) and Arduino ADK for the controller.
The design is pretty simple... Atmel ATTiny25, 4-resistor array, RGB LED, and a linear regulator capable of delivering 5v@~100mA from 9-12v. The code is 100% assembly, the serial protocol is bitbanged and vaguely inspired by the way infrared remote controls work. The onboard voltage regulator is so I can use three thin (AWG22) wires instead of doing something brittle/dangerous, like rectified 120v in series, or be forced to use thick wires to keep the voltage drop down.
I learned a lot about serial bus design while developing it. The original design (and in fact, the circuit boards) was for daisy-chained serial (with each module regenerating it), but it ended up working well enough at ~2kbps with everything wired in parallel to do it that way. Daisy-chaining and regenerating bit-by-bit caused bit-stretching and distorted the timing too badly, and trying to regenerate it byte-by-byte caused delays when the string got to be too big (because each light module delayed the 9-bit "byte" for one full byte before passing it along). The other catch with daisy-chaining is the fact that if one light died, everything downstream from it would have died, too. In an ideal world, it would be implemented with multidrop RS422 (485?), but AFAIK, neither Atmel nor anybody else makes a MCU that can output balanced serial without additional driver chips (though I DID contemplate trying to power the chip with "ground" = -2.5v, and "Vcc" = +2.5v, on the theory that it would still act like 0 and 5v, and let me transmit the serial with -2.5v and +2.5v by bitbanging two pins with opposite values; not sure whether it would actually work, though. I don't particularly understand analog electronics very well, least of all things like negative DC acting like "ground" relative to Vcc).
The light modules themselves are fully autonomous, and have their own mostly-complete semi-assembly language (kind of like the quasi-assembly used by the Cosmac Elf/Studio 2, or the TI-99/4A, or other systems of the 8-bit era). Most of the opcodes translate loosely to "transition [now|slowly|quickly] to color $x, then [continue|pause|delay|stall]", but I also have opcodes to implement for/next, subroutines, if/then, random numbers, etc. The lights are addressed by individual ID (192 max without resorting to segmentation) and by row/column (7 rows, 7 columns). In other words, I can direct commands to "All lights in row 6", "all lights in column 5", "All lights in row 3, column 4", or "light number 97". The row/column addressability compensates for the slow serial protocol (2kbps) and long datagrams (9, 18, or 27 bits), as does the fact that I can send opcode-arg-address, then modify it for other lights by just sending arg-address if opcode remains unchanged.
Anyway, enjoy. By the way, the treegee.com domain name has long-since lapsed and is probably a porn site now, so don't bother trying to go there.