The LED Node presented yesterday needs some software to make it do things, of course. Before writing that sketch, I first wrote a small test sketch to verify that all RGB colors worked:

That’s the entire sketch, it’ll cycle through all the 7 main colors (3 RGB, and 4 combinations) as well as black. There’s some bit trickery going on here, so let me describe how it works:

• a counter gets incremented each time through the loop
• the loop runs 200 times per second, due to the “delay(5)” at the end
• the counter is a 16-bit int, but only the lower 11 bits are used
• bits 0..7 are used as brightness level, by passing that to the analogWrite() calls
• when bit 8 is set, the blue LED’s brightness is adjusted (pin 5)
• when bit 9 is set, the red LED’s brightness is adjusted (pin 6)
• when bit 10 is set, the green LED’s brightness is adjusted (pin 9)

Another way to look at this, is as a 3-bit counter (bits 8..10) cycling through all the RGB combinations, and for each combination, a level gets incremented from 0..255 – so there are 11 bits in use, i.e. 2048 combinations, and with 200 steps per second, the entire color pattern repeats about once every 10 seconds.

Anyway, the next step is to write a real LED Node driver. It should support the following tasks:

• listen to incoming packets to change the lights
• allow gradually changing the current RGB color setting to a new RGB mix
• support adjustable durations for color changes, in steps of 1 second

So the idea is: at any point in time, the RGB LEDs are lit with a certain PWM-controlled intensity (0..255 for each, i.e. a 24-bit color setting). The 0,0,0 value is fully off, while 255,255,255 is fully on (which is a fairly ugly blueish tint). From there, the unit must figure out how to gradually change the RGB values towards another target RGB value, and deal with all the work and timing to get there.

I don’t really want to have to think about these RGB values all the time though, so the LED Node sketch must also support “presets”. After pondering a bit about it, I came up with the following model:

• setting presets are called “ramps”, and there can be up to 100 of them
• each ramp has a target RGB value it wants to reach, and the time it should take to get there
• ramps can be chained, i.e. when a ramp has reached its final value, it can automatically start another ramp
• ramps can be sent to the unit via wireless (of course!), and stored in any of the presets 1..99
• preset 0 is special, it is always the “immediate all off” setting and can’t be changed
• to start a ramp, just send a 1-byte packet with the 0..99 ramp number
• to save a ramp as a preset, send a 6-byte packet (preset#, R, G, B, duration, and chain)
• preset 0 is special: when “saving” to preset #0 it gets started immediately (instead of being saved)
• presets 0..9 contain standard fixed ramps on power-up (presets 1..9 can be changed afterwards)
• the maximum duration of a single ramp is 255 seconds, i.e. over 4 minutes

Quite an elaborate design after all, but this way I can figure out a nice set of color transitions and store them in each unit once and for all. After that, sending a “command” in the form of a 1-byte packet is all that’s needed to start a ramp (or a series of ramps) which will vary the lighting according to the stored presets.

Hm, this “ledNode” sketch has become a bit longer than expected – I’ll present that tomorrow.