This is the protocol spec and PIC10 firmware download for Das Blinkenlichten (1.2). This version improves handling of the ‘Identify’ command by end devices. Backward compatibility to 1.1 is not affected.

I don’t have pretty datasheets, application notes, timing diagrams, or much example code / pseudocode, but I’m sick of sitting on this thing until I get around to those :-P So I figured I’d just stick it on the internet and see what happens. The rest might be filled in in my future spare time (or by some nice person in the comments)…

Description:
Das Blinkenlichten is an open-source RGB LED lighting system and protocol written for the PIC10F200 microcontroller. A complete node consists of this chip, an RGB LED, three current-limiting resistors and a small capacitor for power-supply smoothing. A single chain can have up to 255 unique nodes (or as many non-unique ones as the wires will carry power/data for, without burning up!). Everything is coordinated by a single master device, which can be any low-cost microcontroller or equivalent with a free I/O pin. The beginnings and goals, etc. of the design are described on this page.

Pretty Pictures
Pic: Blinkenlichten in melty, icicle-like resin
Pic: Swirled around by a girl dancing
Video: Very simple random-color-generator demo
Video: Cool video of blinkenlichten who react to music

Features / Commands in brief:

• Cheap! At 34 cents each (qty:100), the PIC10 is probably one of the world’s cheapest and simplest microcontrollers. Complete parts cost can be less than $1US per node.
• Fast 1-wire data bus – complete operation with only 3 wires (power, data, ground)
• 3 colors (R,G,B) can each be set to one of 9 intensity levels – total 729 possible colors
• Set Group Address command: control groups of LEDs at a time with a single command
• Deferred Update command: Allows simultaneous color changes even with a large number of devices.
• Identify command: Discover the addresses present on the bus.
• Power Save command: Stop all clocks and enter low-power mode until the next command

Arduino/Wiring library and example
Library and example sketch showing common usages (move to /hardware/libraries in your Wiring folder, close and re-open Wiring. The example will then appear under Sketchbook -> Examples -> Library-Blinken). This library is released under the GPL.

Firmware and source code (PIC10 assembler)
Version 1.3 (“It’s Log!” edition) can be donwloaded in this zip file. A few lines at the beginning will have to be set according to your hardware configuration (see below). The “#define MYADDR …” line contains the address the chip should respond to – change this and rebuild for each chip you program. This version adds a logorithmic color table so that the color intensities you specify will appear linear (evenly-spaced steps) to the human eye. Adding this meant some idiotproofing had to be removed – sending an invalid (>8) intensity value will cause undesired operation. Starting with 1.3, this code is released under the GNU General Public License v3.

Version 1.2 (‘dumb’ linear color table) can be donwloaded in this zip file. A few lines at the beginning will have to be set according to your hardware configuration (see below). The “#define MYADDR …” line contains the address the chip should respond to – change this and rebuild for each chip you program.

Hardware/Schematics:

Basic schematic for an individual node. The schematic shown uses a common-anode LED (common is connected to VCC); for a common-cathode, tie the LED common to Ground instead and change the appropriate #define at the beginning of the code. Different LED packages have different pinouts; test and make sure of them before wiring it up – or especially making boards. (The R/G/B connections to the LED can be easily remapped in software, but you have to get the LED’s common right the first time!)

Basic wiring diagram for a complete string with several nodes and a controller. There is a pulldown resistor between the data wire and ground (recommended value 100k ~ 1Meg). This is necessary for the ‘IDentify’ command to work, and it also helps prevent your string of lights from going haywire if the controller takes some time to start up and the voltage on the line is floating.

The maximum cable length, and maximum nodes reliably driven on it (or maximum speed), depends on how strong your controller drives the data line. As you add length and extra loads (inductance and capacitance) to this wire, the voltages on it will take longer to rise and fall, and be more difficult for the nodes to reliably consider a ’1′ or ’0′. I’ve run them with 6+m of cable without incident, but if you run into problems, reducing the data rate should help. If you don’t care about the IDentify feature, you can add a beefy buffer here to drive the data line harder. If driving long strings, you might also want to add decent-sized electrolytic capacitors between the power and ground wires at intervals along the string.

PCB and Parts List (Bill Of Materials)
This file contains a parts list for both DIP/breadboard and tiny surface-mount versions. Also included is an EAGLE schematic and Gerber files for a miniaturized, wearable board using surface-mount components. These data (schematics, BOM and Gerbers) are released into the public domain.

A picture of the finished SMT boards (panel) is shown below. With a jumbo 10mm RGB LED, the board is almost completely concealed behind the LED and only the sewable connections stick out.

Programming the chips
To write the firmware to these chips requires access to a PIC programmer. The official ones made by Microchip Inc. are quite expensive; fortunately there are many clones out there that work just as well, and some open-source designs you can build yourself. Just make sure that the programmer supports the PIC10 devices; some very simple/cheap designs (e.g. direct to PC serial port) may be designed only for “low voltage program” devices and won’t generate the +13V or so necessary to program this chip. The DIP variants can be programmed in or out-of-circuit; for the SMT variants, you will probably need to solder them to your board (with an appropriate pin header / etc for the programming lines), program the chip, and THEN add the LED (since it shares some of the programming pins and will interfere). For the ready-made SMT circuit board above, the following drawing indicates the pinout of the programming header on the edge of the board. For this, I soldered the wires from the programmer to the “wrong” side of a 5-pin 1.25mm connector (such as Molex 53047-05), then just press the other end into the PCB during program.

Command packet format: (forgive the horrible ASCII art)

     <start> <addr[7..0]><cmd[7..0]><stop>
_____- - - -. . . 16 data bits . . .______

The bus idles low.

Start condition: Bus goes HIGH and stays high for longer than the longest possible loop run (min. ~ 17uS), so that all devices are guaranteed to catch it.

Data bits consist of a low period (low half) followed by a high period (high half). A 1 is denoted by making the LOW half longer than the HIGH half, and a 0 by making the HIGH half longer. Ideally, all bits should total the same length, but since the low half sets the baud rate on a bit-per-bit basis, this is not required. However, any half should be a minimum 18 device clocks (18/1MHz=18uS) for most accurate timing, and should not exceed 255 device clocks (255uS).

Stop condition: Give some time for the cmd to be processed before sending a new one (bus idles low). If you’re in a hurry, this time depends on the specific cmd. Otherwise, you can just wait about 90uS (time for the longest 1-way cmd, activate_deferred, to complete) and not worry about it. (*See special timing notes for Identify cmd.) This is the preferred approach, but you could also just make the START condition longer.

Address BYTE format:

bit <76543210>
AAAAAAAA

where AAAAAAAA is an 8-bit device address (or group address). Address 0 is the broadcast address. Since the ‘Group Address’ cmd only supports addresses up to 64 (0×40), I recommend a handful of low addresses (0×01 ~ 0x0F) be set asdie for group addresses if you plan to use this feature.

Cmd BYTE format:

bit <76543210>
ERGBIIII

E: Extended Command flag. If ’1′, decode remaining bits as Extended Cmd as described under Extended Commands. Otherwise,
RGB: Which color(s) cmd applies to (set ’1′ for each color this intensity applies to)
IIII: Set intensity (0 ~ 8)

Extended Commands

11xxxxxx : Set Group Addr to value xxxxxx
10XXyyyy : Poke "Virtual reg" XX with contents yyyy (see below), where XX is the address of a virtual 4-bit reg and yyyy is the value to poke.

Vreg 00: Flags [x identify activate_deferred power_save]
Vreg 01: Defer buf R
Vreg 02: Defer buf G
Vreg 03: Defer buf B

Detailed description of the virtual registers:

Vreg 01 ~ 03 allow a deferred update to be sent for the R, G and B channel respectively. The new intensity value(s) are stored in memory, but the old intensity values continue to be displayed until an activate_deferred command is executed, at which point the new intensities are displayed. This will be particularly useful for trickling new values over the bus, then sending a single activate_deferred to all devices (addr 0) to give the appearance of a simultaneous update.

Vreg 00 is a virtual register among virtual registers: Rather than writing a value to it, you write to it setting an individual bit to perform the requested action. Once the action is performed, the bit can be considered automatically cleared.

• Unused (bit 3): “No-Op” – Dummy command, doesn’t do anything.
• Identify (bit 2): On receipt of this cmd by a given device address, this device shall pull the data line HIGH (internal weak pull-up) for a period of about 512 device clocks (or whatever, plenty long enough for master device to see it). Normal operation is then resumed. (Note that this may disrupt other devices on the bus, who interpret the pullup signal as a new START command. If this is bothersome an Identify command may be followed immediately by a dummy command if a device responds. The device’s response will be seamlessly eaten by the dummy cmd’s START, so it just looks like an extra-long start bit to all devices.)
• Activate_deferred (bit 1): Replaces the currently displayed intensities with the contents of the Defer (R,G,B) regs if they contain a valid update.
• Power_save (bit 0): This command will effectively stop the CPU and any pulse modulation activities and enter a low-power SLEEP mode. The device will remain in SLEEP mode until the next bus activity occurs, at which point it will re-awaken. Technically it will be waking up occasionally due to WDT, but these activity periods will be brief.

Quick Examples

Set device id 02 Red to max (8):
<start><02><01001000><stop>

Set device id 02 to bright white (Red, Green, and Blue to max):
<start><02><01111000><stop>

Set device id 02 to arbitrary color (Red 8, Green 2, Blue 3):
<start><02><01001000><stop>
<start><02><00100010><stop>
<start><02><00010011><stop>

Set device id 07 off (Red, Green, and Blue to 0):
<start><07><01110000><stop>

Clear all group addresses to 0 (default):
<start><00><11000000><stop>

Assign device id 0x9F to group (address) 05:
<start><9F><11000101><stop>

Set all devices to power save:
<start><00><10000001><stop>

Advanced Examples

Identify all the devices on the bus (pseudocode):

for (id = 1 to 255)
{
    Send1Wire(id, b'10000100'); // Extended cmd: Identify
    Delay(100); //delay 100 uS, to give device time to respond
    DATA_WIRE = 'INPUT'; // However you switch this pin to an input on your preferred platform
    gotResponse = DATA_WIRE; // read the data line to check if anyone is responding (pulling the data line high)
    DATA_WIRE = 'OUTPUT'; // Switch it back to an output (retaining same value as was read)
    if (gotResponse == 1) // Was there a response?
    {
       print("Found device " , id); // do something with this information, e.g. store active IDs to a table
       Send1Wire(0, b'10001000'); // send dummy command if there was a response.
                                        // Or you can just wait a few hundred msec for the other devices to reset
    }
}

Specific firmware points of interest

The intensity of the LED colors is controlled using pulse width modulation (PWM). The basic operation is that the intensity value for each color (0 ~ 8) is converted to that many ’1′s and stored in a register, and this register’s contents are continually rotated in circles. Each time, the last bit is used to determine the on/off state of the LED. So with 8 bits in a register, it can be on 0/8 of the time (off) or 1/8 of the time or … 8/8 of the time (full brightness).

To provide the fastest possible update rate, it’s necessary to squeeze as much performance out of these cheap tiny PICs as possible. The PIC10 supports only a handful of instructions, no interrupts, and only a rudimentary 8-bit timer. For the PIC10F200, the entire program is limited by memory to 255 instructions. Therefore we can’t afford to be too sloppy.

The code uses look-up tables in place of any loops/math wherever possible. The chip does not support table-indexing operations in ROM (Flash), so this is done using computed GOTO: In many microprocessors including this one, the Program Counter register (which acts as the processor’s bookmark in the code’s execution) can be modified by the program directly. Thus, by writing a new value to the Program Counter you can force the processor to lose its place, resuming program execution from the address you just wrote. By performing math operations directly on the program counter, this method can be used to index a lookup table nearby. In the example below, the intensity value is added to the program counter to make it an index into a table stored just after it. The ‘retlw’ instruction returns from the function with a specific value saved in a register. This code snippet converts the (0 ~ 8) value to a value containing that many ’1′s, using only a few clock cycles.

; Want to return a value containing the number of '1's specified in the intensity
; value. But want to spread them out for faster switching and less perceivable flicker.
setpwm:
    movf INDF, w ; cmd value
    andlw B'00001111' ; mask off bogus bits
    addwf PCL, f ; skip that many instructions
    retlw B'00000000' ; 0x00
    retlw B'00000001' ; 0x01
    retlw B'00010001' ; 0x02
    retlw B'01001001' ; 0x03
    retlw B'01010101' ; 0x04
    retlw B'01010111' ; 0x05
    retlw B'01110111' ; 0x06
    retlw B'01111111' ; 0x07
    retlw B'11111111' ; 0x08 ; last valid value

This same method is used to allow the PWM loops to keep running while receiving data. Each time a bit is received, the PWM loop “jump table” is called. The count of the number of bits received is used as the index into the jump table; instead of a list of data values, each table entry contains a jump (GOTO) to the address of either the red, green or blue updater.

Determining between ’1′ and ’0′ bits on the data wire also takes just a few instructions. For each bit, the line is held low for some amount of time by the controller, then held high. Whether the low or high half was longer determines whether it was a 1 or 0. The way to measure this can be thought of as a stopwatch that counts up during the first half, then down during the second half. If the count goes negative, the second half was longer and we record a ’0′, else we record a ’1′. The ‘stopwatch’ here is the chip’s 8-bit counter/timer register. But it can’t count down, it can only count up! So a little cheating: when finished timing the first half, we complement (invert) the contents of the timer register. Now it’s still counting up, but if the original count was 7, now it’s (256-7) or 249. If the 2nd half is longer, the timer will reach its maximum value (255) and roll over to zero again like an old car odometer (and ending at a low number again, the Most Significant Bit will be a 0). Otherwise it will be a high number, and the Most Significant Bit will be a 1. So, at the end of one up/down cycle on the data line, the timer’s MSB will automatically contain the correct bit as it was sent on the data wire.

You might also have noticed that the PIC10 only has 3 pins that can function as outputs; according to the datasheet the 4th (which I’ve used for the data wire) is input only. The 3 output pins are already being used to drive the 3 LED colors. So how does a node send data back to the controller in response to an IDentify command? There is a register setting that enables weak pullup resistors (~10k-20k) on all the pins. On the output pins this does nothing, but on the input (data) pin this applies voltage to the wire, overpowering the even weaker pulldown resistor (~100k) added to the controller side. (The controller stops driving the I/O pin briefly to await this response.) So by toggling the pullup resistor on and off, we can send data the ‘wrong’ direction :-)

Version History and Compatibility:

• v0.x (2005) Nora Nightlight edition. Quick n dirty hack with hardcoded timer to distinguish 1/0 data bits. Set Group Address is the only valid extended command. Didn’t get around to touching it again for a long time.
• v1.0 (2007) Beloved edition, demoed at VNV Nation concert April 07. Changed from fixed-frequency to variable baudrate data encoding/decoding; re-ordered some bits in the command packet format to make more sense.
• v1.1 (2008) Proper edition; first public release. Implemented remaining Extended commands: power save mode, deferred update stuff, and device identification.
• v1.2 (2008) More-Proper edition. Improved handling of IDentify cmd; now can avoid flashes during identify as non-responding devices on the bus reset. Compatibility with v1.1 devices is not affected.
• v1.3 (2009) It’s Log! edition. This version implements a logorithmic color scale in order to better match the human visual response (intensity steps now appear evenly-spaced). Compatibility with v1.1 and v1.2 devices is not affected, unless you are sending invalid (>8) intensity values, which you shouldn’t be!

v1.1, v1.2, v1.3 are backward / forward compatible and can be used on the same bus. V1.0 supports only the basic command set (Set Colors and Set Group Address). Versions prior to 1.0 are not compatible at all…luckily, they basically don’t exist in the wild.

For a project at work I had to mold some things in this hard clear polyurethane, so my Mechie ordered a giant kit of the stuff – more than the project ever will need (and it has a very limited shelf life). So I mixed up a little more than necessary and used the leftover to pot some Blinkenlichten (intelligent LEDs).

The material used is Smooth-On brand “Clear Flex 95″. This is mainly sold as an industrial product, although smaller quantities (highly recommended! See below for why) may be availble from art supply houses. It comes in 2 separate jugs of syrupy liquid marked PART A and PART B, which are mixed together in a specific ratio by weight.

Clear Flex 95 (casting resin) and mold release spray

For every part, the general process is:

1) Make a mold (basically a pool that is the inverse shape of the part you want to make). A wide variety of shapes are possible, but the shape must be such that you can remove it from the mold again once it’s hardened. Complex shapes with convexities or overhangs might require the mold to consist of two halves that can be clamped together and later pulled apart to remove the finished piece. One good mold should be good for many, many parts. (The Smooth-On site also provides a moldmaking tutorial.)

2) Liberally spray down the mold with a “mold release” agent. This looks, feels and acts pretty much like PAM non-stick cooking spray. Same idea – it keeps the piece from sticking to the mold. (It’s possible that grease or cooking spray could work as well on some materials, but it’s disrecommended by the manufacturer and I haven’t tried it.)

3) Thoroughly but slowly mix up the liquid, being careful not to stir in air bubbles (unless that’s the effect you want – but in general air bubbles are bad news since you can’t easily control where they end up or how they are distributed). Scrape the sides of the mixing container in the process to be sure everything is getting mixed. If you want to add any colorants or other stuff (confetti, metal flake, etc.?) to the mix, now is a good time to do it.

4) Pour the mixed goo slowly, aiming for the bottom of the mold (containing any parts to be encapsulated, if any), letting the material seek its own level and chase out any trapped air. It may help to fill it partway and tilt in different directions to release any air bubbles before filling all the way.

5) (advanced stuff for perfectionists*)

6) After it hardens (see the “demold time” spec on your chosen casting material), open the mold (if applicable) and pull the piece loose. If the mold was designed smartly and mold release was applied, it should come out easily. To finish the hardening process, and clear up any remaining tackiness on the surface, it’s typically baked in a low-heat oven for several hours or left out at room temperature for several days.

Obligatory Warnings: Although you can pick this stuff up at art-supply houses, don’t let this detract from the fact that this is still a nasty industrial chemical product and should be handled with due respect. Wear gloves for mixing and handling (if you get some on your skin, you’ll know within a few minutes by the burning sensation…), and long sleeves. Use in a well ventilated area, or ideally outside. Don’t get it in your eyes, don’t mix it in your favorite beer mug, don’t bake the parts in your food oven.

Aluminum mold for USB gadget (failed unit shown, it’s the one that was handy)

USB gadget (successful unit shown)

For the USB gadget, a 2-part mold was cut from a small block of aluminum to be a bit larger than the board all around. Both pieces were sprayed with mold release. After wrapping some tape around the USB connector in case of drippage, the board was stuck into the aluminum mold block with the connector sticking out. The mix was slowly poured in until the level reached almost to the top of the main part of the mold, then the cover plate was screwed on. The complete mold was then turned upright (USB connector pointing up) and filled to just above the top of the PCB, tilting gently side to side to get the air bubbles out. After sitting like this overnight, it was removed and baked for a few hours at about 150degF in a cheap toaster oven.

Ice cube tray "mold". The first cube in the tray bears a plastic recycling logo, which now appears on one of the molded cubes (whoops!)

Single cube. Note extreme refractive index(?) resulting in multiple reflections of the hardware inside.

Cubes with power/data applied

The LED cubes were done exactly the same way, except instead of a complex aluminum mold the circuits were stuck in a plastic ice cube tray, and the cubes filled with the casting material. The first batch (2 cubes) turned out awesome! About a week later I mixed up a new batch and tried it again…

Fail!

Not sure what went wrong with this 2nd batch, but it remained about the consistency of pine sap (and flowed very slowly, e.g. over the course of a day or two), and after a few days it bubbled up like crazy and stayed that way. Once I returned from a 2-week trip (3+ weeks curing in air), they finally seemed to be hardened. Current theories are a) I mixed it wrong (confused the Part A and Part B) – although I checked and doublechecked… b) it really does go bad that fast after opening, or c) the leftover goo from the fat lip on top of the can (exposed to moist March air for some several straight days) helped poison the mixture. I hope to try it again sometime reasonably soon, but in the meantime it seems like a good idea to get this stuff in as small containers as possible and use it soon after it’s opened. Blowing some dry inert gas into the cans before closing could extend its life a bit.

After the unsuccessful attempt to demold them from the cube tray resulted in “melting” all over my table, the above is the mostly unsucessful attempt to get them back into the cube tray. Each step represents about 2 days’ worth of melting. This could potentially be reproduced intentionally for artistic effect, IF there is some way to force it to harden up at the desired time (such as immersion in straight Part A/B, if it resulted from a bad mix ratio). After several weeks’ exposure to open air, the stuff shown seems to have finally hardened. Comparison of the melty results to the original cubes also shows that they started out completely bubble-free; the massive amount of air bubbles present in the end result most likely formed as the result of some slow chemical process in the dud mix. Small bubbles began to appear by the day after pouring and continued growing until the material hardened. (It may even be continuing still – I’ll find out one day if one of these melty cubes suddenly explodes.)

Bubbles where there were no bubbles before

Being blinked, top side

Being blinked, bottom side

After some days of continuing to melt around in the tray, I looped them over a rod and let them just melt freely. Here is how they finally hardened.

Actually, when lit the melty ones kind of look badass!

* if you really, really don’t want air bubbles, one way to get rid of them is to build a vacuum chamber (the compressor from a discarded cube fridge or dehumidifier, etc. makes a good hobby vacuum pump and compressor). Basically any container you can place the still-liquid mold into and pull a vacuum on it, thus causing any trapped air bubbles to swell and burst (or become buoyant enough to rise to the top and escape). Then, by reversing the pump (positively pressurizing the chamber) until the mix hardens, any small remaining bubbles can be compressed to nearly invisible size :-)