Small Update

I'm in the middle of a six-performance weekend and what little free hours I have are being consumed in repairing microphone elements and re-writing some sound cues.

(Actually, changing over from QLab to VSamp for some camera shutter and chop-socky effects I am improvising live during performance.  I was doing them in QLab using the ability to hot-fire a sound from computer key or MIDI keyboard, but putting them in VSamp -- a low-profile, shareware software sampler for the Mac -- means I can play multiple "notes" as fast as my fingers can move on the keyboard.)

Anyhow.

My XBee Pro came in the mail, but so did a BlinkM.  I have to take apart a prop that is featured in the current show in order to interrogate the XBee node inside it and then program and replace it with the higher-power Pro.  So I'm holding off on that until after this weekend's performances!

Which gives me time to mess with the BlinkM.

First impressions; tiny form factor, no power conditioning needed (well, within the somewhat narrow range of voltages).  Bright, but that's on the scale of small LEDs; I think it is just barely bright enough to do a candle effect on stage (stage lights are fierce competition).  Fortunately, there is the MaxM (or you could break out the PWM lines and Power-MOSFET them into some of those 5-watt monsters they make now.)

In the raw form, you use an Arduino as a serial-to-I2C converter.  I had a bit of an issue when my current version of the Arduino IDE wouldn't run the BlinkM communicator, and the latest version of the Arduino IDE wouldn't run on my computer, but regressing to version 0023 solved both problems.

The programmer/sequencer is cute and runs smoothly but is painful to use.  Most of the kinds of things one would want to do would be smooth fading from color to color (or color to out).  What you'd want is the ability to express those mathematically, or graphically in the form of spline curves.  Instead you have a 30-step piano-roll that you fill in manually.  Fun to play with, but hard to construct smooth fade curves on.

The worse problem, from my perspective, is that although turning two of the PWM outputs on an Arduino into a I2C interface is simple enough, and I2C protocol allows multiple units on the same line, and the built-in instruction set is large and well thought-out, most of the applications that spring to my mind would be better suited by 8-n-1. 

Such as connecting to an XBee to allow streaming of new instructions via wireless link.



Well, with the extremely simple online instructions and my Adafruit "TinyISP" it took only a few minutes to upload a new program from the Arduino IDE.  This wipes out the installed boot, but as far as I know it doesn't install an Arduino-type bootloader -- I'll probably have to use the ISP to continue programming.  But aside from that mechanical detail, the experience becomes exactly like putting code on an Arduino.

Some reading of the schematic from ThinkM (and comparing it with the ATtiny45 datasheet from ATmel!) shows that -- given that the ATtiny45 only has two PWM pins -- this is controlling the three LEDs by strobing three digital pins.  The way the BlinkM breakout is built, one unused digital I/O is brought out to the front of the board, as is a copy of the PWM/I/O pin used for the blue LED.

Anyhow...there are enough pins being brought out to implement soft serial, which is my next experiment.  In the meanwhile, though, I'm writing up my own version of a code for the thing.

Or, rather, working on how to best use program cycles to handle the different and changing pulse-width requirements of three different LEDs simultaneously -- a task that really is better suited to the internal timers and PWM outputs. At the moment my experimental code is running through a 0-100 integer loop, and turning each LED off at the appropriate "slice" along that loop, from 1% duty cycle (a barely visible flicker) to 100%. However, my current code appears to be running so slowly the maximum smooth fade (aka incrementing one "slice" with every pass through the loop) consumes around half a second.

Which sounds like a deep error in my test code -- at 8 MHz, even running on compiled C code the RISC chip (which executes most operations in a single clock cycle) should be WAY faster than that (according to my calculations, in fact, over 1,000 times faster).

Grafting on the entire front end of the BlinkM is more than I want to handle.  But, fortunately, I think I can make do with a limited capability to either go to select colors, or to go to various off-line programmed "useful" sequences (like candle-light).  I may, though, now that I think of it, add to the instruction set something like "RandomColor( baseR, baseG, baseB, rangeR, rangeG, rangeB, rate )."

Once I get the basic PWM and fade code working right, that is!