If I Only Had a Brain

Among the things that got cut from "The Wiz" before they were installed -- but not before I had spent money and time on them -- was lights in the TINMAN.

Artistically, this is a good choice.  It would have been fun to have lights in him, but the costume works fine without.  And it is less for the actor and the stage crew to deal with.  I'm all about what makes dramatic sense, and what makes sense from a "whole theater" perspective (weigh the cost of doing the effect against how much the audience will appreciate it).

Oh, look -- more context-free pictures of circuit boards!


This was the TINMAN's brain.  Re-using once again the minimal Arduino I'd built on Adafruit perma-proto board, with ISP header for programming, 7805-based power regulator, and a ULN2803 Darlington array for switching banks of LEDs.

The program was another iteration of the pseudo-RTOS I've been doing of late within the Arduino environment; a master system counter, and timed events triggered at mathematical fractions of the counter value rather than via delay() commands.

The button was a black-out button that toggled all the costume lights off.   The ribbon cable was to drive LEDs in several different states; constant on, slow blink, fast blink (in a pattern-of-four), and pulse (power button style).  Only the PWM of the latter leveraged the internal timers and interrupts of the ATmega328p chip.

The most complex part of the code was the boot sequence.  Since this was never in an Arduino, there is no bootloader on the chip.  Instead it enters with no perceptible delay into a program cycle that only runs once (and can still be interrupted at any moment by hitting the "blackout" toggle.)

That program turns on the various LEDs in sequence, flickering several of them as it does so, to mimic a power-up sequence.  The intent was to trigger this as the TINMAN is "oiled" and would reflect him coming back to full activity.




The EASY part would have been to run that ribbon cable up the costume and to the various LEDs that were already embedded in the various found electronics and e-waste adorning it (including dead proto-boards built long ago by both me and my dad!)

But that's the point at which it was decided (and properly so) not to light the TINMAN.



And, really, the only legacy of the TINMAN lights is the two rolls of light pipe I had already bought by the time it was cut, which found their way into the WIZ's costume instead:

How Do You Do....

I'm entering a new round of teaching and I'm really asking myself what are the skills necessary to create the kinds of electronic gadgets I've been creating.

From my perspective, a lot of it is boilerplate; parts and circuits I already know and can plug in to a new project.  I have intentionally kept this collection of known elements small and controllable -- even as each new project I undertake intentionally includes learning and adding at least one new element to the set.

Another large part is the analytic method.  Iterative design, modular construction, testing and empiricism and, as I am able to do it, quantification and calculation.

The hardest part to teach is that kind of instinct you get when you have done similar stuff for a while.  When you understand not the specific wiring of a part, but the way that wiring is similar to a host of other parts.  Like knowing that basically all 8-pin dips will want ground and vcc, and they will often be found on corners of the chip.  Like having a sense for the current rating of a part from how physically beefy it is.

And, yes, a large part of it these days is looking for help online.  Whatever circuit I'm tinkering with, the chances are good someone else has done something similar.  The trick there is being able to sort signal from noise.  To know where to look, to be able to navigate in those places where the information might be, and to be able to rate the trustworthiness of what you find.  And that also seems to be something that just requires familiarity; time and exposure and experience.




The analytic method seems the easiest to explain.  Being able to apply it may be another matter entirely!

When I set out to put lights on the WIZ's costume, the first part of the design cycle was working out just what kinds of light.

When I got a little further on I reached a point of calculation; where I knew the wattage of the various things I meant to use, and I could check that against the known capacity of batteries and see if it was actually possible to put that much light on a costume.

But to get there involved a healthy dose of empiricism.  I hooked up lights.  I carried them out to the stage, and set them down on a chair, and went out into the audience and looked at them.  I did this over and over, with "Pirahna" LED's, 3W "Cree" LED's, light pipe, EL wire, lasers, and a few other things besides.

What I was gathering was empirical but quantifiable data; a sense of just how bright each part was, that I could then use to understand how their numerical data (aka wattage, lumens, field of view, etc.) related to actual visibility in stage lighting conditions.

This particular project had a short terminal cycle; from purchasing the intended parts to opening night was a mere week.  I used that time to construct the other circuitry, and make sure I could control an LED strip from an Arduino, but there was no time otherwise to properly iterate and test each element.

The best I could do was to test each section of lighting on the costume before I soldered the final wires.

And although I was able to do a full plugs-out test, the final shake-down under show conditions -- costume on an actor, stage lights on, wireless microphones in use, etc -- was done for the first time in front of an audience.


So the very first part of a project is trying to parameterize what it will take to achieve what you want to achieve.

Say that you are trying to make, as a for-instance, a pair of nekomimi ears.

The two big questions during the first phase of development are then, obviously;  1) what do we need to wiggle the ears, and; 2) how do we control them.

At some point you need to proof the concept.  Put a servo on an ear on a wig block and see if it moves as smoothly and swiftly as you intend.  Hook up a sensor and see if it is sending you data you can parse usefully.

But before that you need to grok just what kind of servo and sensor is necessary.  And for this, calculation (and research) helps.

But we're not talking actual engineering calculation (although I've done that in the past).  I'm talking about the simpler tools science uses; order of magnitude calculations, and dimensional analysis.

Order of magnitude is the justly-famous "Spherical Cow" family of approximations.  Instead of trying to plug in exact numbers to ten significant digits, you are seeing if you are in the same ballpark or not.



Assume cat ears.  Assume they are made out of fake fur and foam.  Assume we can make a fairly smooth pivot for them; so as an approximation, the turning resistance due to mechanical friction will be on the same order of magnitude or less than the torque of moving the ear itself.

Borrowing a page from dimensional analysis, I look up a standard small hobby servomotor and see the torque is rated in ounce/inches.  So to find out if a small servo will work, I need to be able to plug ounces and inches into a calculation.

A brief look online and I find the shipping weight on a pair of crew socks is 2.4 oz.  Assuming the foam and fur is a bit heavier than that (but around the same dimensions) I'd go 10 oz at the outside.  Holding up a hand, I'd say the ears are maybe 5" at the base -- that gives a radius of under three inches.  So the torque to move them would be < 30 oz/inch.

A micro-servo at Adafruit is listed with a stall torque of 25 oz/inch at 4.8 volts.  Which, given my generous assumptions above, is probably enough.

So now let's calculate velocity.  I said "twitch" to myself and twitched my own ears (I am one of the small percentage of people who can do that).  Felt like a bit under 1/2 second.  Assume I want to move the ears from neutral to forward in 1/2 second, that's at least 90 degrees.  So as an approximation, I need to be able to move 180 degrees in 1 second or less.

That same servo lists at .1 second/60 degrees, which is a magnitude faster than I need.  Of course that's probably no-load speed, but again this seems plausible.

Now, if the speed had been too low, I might have to put in a gear train.  Which would multiply the torque by the same factor, plus double it to account for mechanical losses.  Had the torque been too low, same idea; put in a lever arm, and reduce the effective velocity.



The thing of it is, to do this kind of approximation -- Orders of Magnitude and/or Dimensional Analysis -- you have to have a sense for what matters and what doesn't.  You notice I didn't bother actually including mechanical losses.  That is because my experience for machines like this is that torque trumps any losses in the pivot.  But the fact that I brought it up; again, experience that even a simple rod linkage will waste significant energy which has to be accounted for in the design.

And that's the tough part to teach, again.  You have to do this kind of approximation, and do it over and over again, and hold it up against the real world with empirical tests and research (to see if other people have used a small hobby servo on a pair of cat ears -- and, yes, they have.  Which is good enough to proof that this is a method that can work, all else being equal).

And it also required I understood the concept of torque, of angular momentum, of how this is characterized (as mass over a lever arm aka radius.)

And this is physics.  Or other sciences.  Which means that often what is happening is not intuitive.  Your instinct might be, for instance, that a blue christmas tree light of 5 watts is brighter than a blue LED at 1 watt.  And it would be, except that an incandescent lamp puts out a broad spectrum, which is then filtered down to just the blue by a coating on the bulb, with the rest wasted as heat.  So more of that power becomes blue light in the LED.

Which seems to require you have a basic grounding in whatever sciences may be appropriate.  Or at least some basic general science.





And then there's the familiarity with the tools.

I've been using servos for a while.  I am familiar with several things about them; that they make noise when they move.  That they move at a preset rate.  That you need to supply a specific kind of control signal to them (PWM -- pulse-width modulation).  That they require the same 5v as much of your electronics, but more amperage than a typical Arduino will supply.

In the case of the WIZ costume, my known tools were Power Darlingtons, Arduino, XBee modules, and my home-brew Blink code.  I'd already hooked many of these modules to each other in different projects; PWM dimming of a high-power LED via a power darlington, speaking to an Arduino with an XBee, and so forth.  So the interactions were mostly known.

What I did NOT know is if the circuitry -- micro-computer and micro-power serial data link -- would survive in an environment where I was switching several amps of LED on and off.  Or if the whole mess would make radio noise and interfere with the wireless microphones.

Now I know.  And I know simpler ways to build the next similar device, too.  Iteration and empiricism aren't just useful for the project at hand; they are also how you refine the tools you then have available for the next project.

But this makes my teaching project difficult.  I can communicate a set of tools, but the skills to know when these tools are appropriate and the range in which they will work -- that is more difficult.

dont't delay()

Delay() is to Wiring what GOTO is to BASIC.

Sure, for a three-line sketch that blinks an LED, there's nothing wrong with using delay() to control the timing.

But for anything that involves human interaction or sensor data, every moment spent in delay() is a moment the device won't be able to respond to inputs.

Well, unless you are using interrupts.  Which is fine and dandy, but if you've mastered interrupts, then use those same timers instead of adding delay() statements.



About half of the sketches I'm writing these days are in one way or another simulating analog electronics.  The Morrow Project CBR Kit, for instance, had multiple places where it would blink a light two or three times, or display one word on the display for a second or two then switch to another.  Basically trivial in analog electronics (which is what it was simulating), but challenging in a single-threaded micro environment.

The trick is to make something like a real-time operating system.  Instead of spending 9/10ths of the clock cycles sitting in a wait loop, you emulate a counter in code.  The code runs continuously, passing through the sensor and button checks and looking for new serial input and so forth (and running such things as software PWM), and when the counter reaches certain preset values, actions are taken.

For a "flash three times," then, my pseudo-code might be something like:

counter ++;
if (counter % 2 && counter < 8)
  {LED on:}
else
  {LED off;}

Or you can control the timing more closely with a more long-winded, harder to maintain bit of code;

if (counter == 100 || counter == 200 || counter == 300)
{LED on;}
if (counter == 120 || counter == 220 || counter == 320)
{LED off;}

The latter produces a short pulse for each blink.

Of course you can always add a second counter just to control the number of flashes;

counter ++;
flashes ++;
(if counter % 100 && flashes <= 3)
{toggle LED;}

These sorts of strategies allow you to have multiple events which appear free-running, with individual timing; indicators blinking, pulsing, doing patterns, all at the same time.



I will add; I'm using delayMicroseconds() a bit.  Reason is, I've been writing for the ATtinys, and doing things like software PWM where the timing of the code is actually dependent on the actual execution of the opcodes.  So there are a few delayMicro statements in there to balance different sections of code so the machine spends a roughly equivalent time on both ends of the PWM loop.

It is also often very useful to delay just a wee bit after a serial data receive, and for some kinds of sensor data.  The point is; these delays are happening at machine scale, and are taking on the order of tens or hundreds of clock cycles -- little more than an average bit of actual code.  The delays I was talking about in my introduction are vastly longer; up into multiple seconds.

Ten Minutes a Minute

Apparently a sound design is worth about $2/hour these days.

I just checked over how many hours I spend in design and engineering (and in rehearsals and tech) for the last show, and dividing the design fee I got paid into that comes out around two bucks an hour.

Actually running the board comes out a little better; seven bucks an hour.  And if you accept a 5+ hour "service" then it breaks down to almost $40 per service (that's musician talk there).


The old rule (from the game audio community) is that it takes ten hours to create a single minute of final game-ready audio.  Based on the pay rates above, I think I need to get down to a bit more like half an hour per finished cue.  I created about twenty cues for the show of which about half never made it to opening night (one of the longest bits of work that got cut was listening to recording after recording of small dogs barking.  And we never even tried a dog bark in tech.  But it was requested, so I had to spend the time.  Cutting the cue once all the work is done saves me NOTHING.)


But this ignores entirely the engineering.  I once got a thousand bucks a show just for engineering; no mixing, no sound effects.  Because there is literally that much work -- and that much expertise -- in tuning the audio system, figuring out routing, setting up the pit properly, plotting, adjusting (and repairing) wireless microphones, etc.

I spent four hours in the middle of tech doing "nothing" but playing music through the house sound system and tweaking the inter-speaker delays, relative levels and touching up the corrective system EQ.  Which is only a fraction of the time I need to spend on that system some time soon, once I have the right tools (aka SMAART) to do it properly.


So I spent almost four weeks of 12-14 hour days, and am in production for ten hour days Saturday and Sunday (plus some weeknights).......and my bank just hit me with another insufficient funds notice.  Ain't this a fun gig?

Wiz Report II

So.  My first wearable.  We've learned a few things over opening weekend:

-- You can punch a 2.5 gighertz signal through metallic brocade, an actor, and a hundred feet of air, but it takes power.

-- You can dance and sing with an 8-pack of AA batteries on your body.

-- An Arduino, an XBee radio, and a meter of PWM'd LED strip doesn't create enough noise in a good wireless microphone to matter.

-- 60-LED-per-meter RGB is actually overkill.  We were afraid the costume wouldn't be bright enough to be visible over stage lights.  It is so bright I'm thinking of turning it down! 

-- Client-side works, and does permit more elaborate/faster animations, but server-side is more flexible.

-- Digital would be better.  Soldering all those leads for analog RGB was no fun.  Also, the leads on the RGB strips keep coming loose.  Digital is only a few bucks more -- and allows even more elaborate animations, too!

So that's the thing.  This is actually turned down a bit.  The look is simple; LED strips stitched along the edges of the lapels, and 3W LEDs under the shoulder things.

The electronics are in pockets stitched to a vest, which hangs loosely inside the jacket so as not to disturb the hang of the jacket.

Here's the signal chain;

A Processing ap allows the operator to click on one of several programmed "looks" (most of them are animations; pulses, flickering, color swirls).

Processing spits out a serial word to a SparkFun USB adapter holding a Series 1 XBee Pro.

The signal is picked up by a matching XBee on a Seeed Studio mini-shield, and sends the serial word on to an Arduino via Soft Serial. 

The Arduino, running in a form of RTOS, routes through one of several programs to output the three PWM signals.  Which are basically lifted from the "Blink" code I wrote a while back.

These are sent to a second box containing the switches and drivers; Tip120 power darlington transistors switch the LED strip, and "MR16" type constant-current drivers switch the 3W "Cree" LEDs.

Then the wires all come out the back of the neck, under the collar, and are routed to each lapel and to the shoulders.

On each shoulder, a "Cree" with an improvised heat-sink of aluminium channel pushes light into a half-dozen random lengths of plastic light pipe (bought at SparkFun, and probably the most expensive part of the costume electronics).

The final effect is QUITE bright.  (The picture to the left is under work lights.  I had to stop the camera down considerably.)

We only use it for "So You Wanted To Meet the Wizard."  At the top of the song, it glows green (shifting subtly between yellow-green and blue-green).  For the soaring "B" section, it goes to a shimmery blue.  And at the end of the scene, ("I have spoken!") it goes to a rapid mostly-red flicker/flash.

During the dialog scene we're running it at an extremely low setting (analogWrite(green, 8)) just to give the costume that hint of sparkle.

And of course we black it out at the end of the scene.



Next time I do something like this, I'll use either an Arduino mini or similar, or a proper wearable like the new Flora.  Although XBee support is a little minimal on those options.  I'll also go with either AAA power pack, DC-DC boost converters and a smaller set of batteries, or perhaps liPo.

I'll also probably skip the driver board.  You do need a switch for analog strips or the Cree, but for many costume applications Flora pixels or digitally-controlled LED strips are plenty.  And those have internal drivers; all you have to do is supply enough amps from your battery pack.

But for this show...since I'm taking the CPU back after the show, the total cost of the electronics was about a hundred bucks.

This show was very much thrown together during Tech.  And I haven't had a chance to go back and tidy up yet.  Here's the Vox Box, as used in the show; propped up on top of the amp cabinet by the snake, plugged into a Behringer micro-mixer to boost the audio signal it is getting.

Since the lead's microphone is fed into a dedicated mix bus for this effect, I can adjust the response somewhat from the mixing board during the show.  The one thing I haven't been able to do is set the lower trim; that would involve running backstage to turn a trim pot inside that Altoids can there, during the song.

And a good thing I put the heatsink on.  I measured a bit over six meters of platform, and purchased two five-meter rolls and a power supply designed to drive one roll worth.  Then they decided they wanted to extend the LED strip along the ramps leading up to the platform in question.  That makes it the full ten meters, and is well above what a TO-220 package transistor wants to dissipate without a heatsink. 

Soon, though, I will change over to Power Mosfets, which have a smaller voltage drop and hence run cooler (as well as producing brighter effects).

Wizard Report I

It works.

We're in tech, opening this weekend, so I can't spare much time for detail.

The eponymous "Wiz" is wearing a coat with RGB LED strips along the lapels and 3W RGB's in the shoulders, feeding into a small festoon of cut-end light pipe.

Because of lack of development time and budget, his controller is an Arduino, with a Seeed Studio XBee shield attached.  To allow the micro to control the 2-3 amps of up to 12 volts required by the various lights, there is a separate driver board.


CPU, driver board, and an 8-pack of AA rechargeables are each in their own pocket sewn into the back of a vest he wears under the coat.  It worked.  He was able to move, the lights looked good (and bright!) and we could control them from the back of the theater.



Here's the only detail I have time for today; a little "what are the differences between these pictures?" exercise.

Driver board being built:

Driver board in finished form:

Well, besides the Altoid's tin, there are a few subtler (but very important!) changes.

The high side of the constant-current power drivers are now on an independent bus, instead of being tied to the positive lead of the main power supply.  (That gap in the board was to put a 12v DC-DC converter for the 12V LED strips.  Or I could have tapped the battery twice to put 9V across the constant-current drivers.  But in the end I went with simple; a 12V system bus).

And there's an even subtler fix:

The lads and lassies in Singapore assembled one of the constant-current drivers incorrectly.  I didn't realize this until after I'd blown out the red channel on one of my Cree.

Incidentally, some people recommend removing the diode rectifier array completely; they claim it causes RF noise.  I haven't had a problem with the circuit yet.



And that is actually the most important part of this.  Despite the Wiz's microphone being patched into a driver circuit for nearly ten meters of LED strip, and the poor actor being draped with high-amperage PWM circuitry, the Sennheiser wireless body pack has performed without issue or extra noise.

"He Changed the Op in the Middle of the Op!"

So I haven't completed much of anything for the upcoming show.  And we go into tech next week.

But it isn't because I haven't been working on it.  I've been pulling 10, 12, 14 hour days doing electronics.  It has been an extremely productive week or two.

Trouble is, most of what I built is either not going to be used, or is different from what finally got decided on.




I built a prototype POV wand.

Yes, it works, and people were amused by it.  But not well enough to fight to adapt the blocking et al.


I built my prototype DuckNode:

Yes, you can wire an analog sensor -- like a MEMs 3-axis accelerometer -- to an XBee and run it directly off a pair of AAA batteries.  I didn't do any range or endurance tests yet.  But because the XBee is a low-BAUD transmitter and the analog ports are Successive Approximation, the practical sampling rate is down around 1/10th of a second.

"Spider Duck, Spider Duck, does whatever a Spider-Duck does..."

It is still a tight enough sample time that even a simplistic 1-axis read was enough to discriminate a "throwing a spell" motion from random other motions.  I threw together a hand-stitched pouch for that demonstration.  And, yes...the form factor does leave something to be desired (it's the bulk of those batteries; even AAA are not that small, not attached to your wrist).

I promised I'd experiment and see if we wanted in the show, and I got the demo working...and I recommended we don't try to use it this time.

So the benefit is that next show, I already have something in my kit and we can experiment with it early in the blocking and brainstorming.  Well....better if I also had the Processing backbone firmed up!



We had an idea for lighted wires on one costume and spent a while experimenting on that:

Okay, we are still using a couple of bits, but they are a minor element for the costume (the bigger part is going to be wiring up a whole bunch of random LEDs).

We thought about using it on the WIZ himself;

This is actually under desk lights, and I had to force the exposure low by four stops.  This stuff is BRIGHT.  As it turns out, you can make a permanent bend in the plastic light pipe by heating it with a heat gun.  So it is bent a sharp 90 degrees and hot-glued to a "Cree" 3-watt LED.  Then stitched along a mock-up hem -- again, hand-sewing (some day soon I will have a Machine Of My Own.)

But besides being a lot of effort, it wasn't quite as cool a look as LED strip lights.  So that's what we are doing instead.  And because the decision went back and forth so many times, I just got the order in for the stuff we want to use, it will be delivered after the Fourth, and I'll be trying to solder it up like a day before Tech.  Sigh.



Another thing that got cut was the Heart.  It wasn't a complete waste of my time, though.  I cleaned up my soft-PWM code and had a nice "Apple Power Button" fade running on an ATtiny85.  And that gave me the parts to try out fading directly via the constant-current supply itself:

(In the pic; ATtiny85 on hand-made programming board, getting power from USB via the USBtiny ISP on the far right.  The MR16 in the middle is powered by the 9V battery holder to the left, with all grounds tied together.  The PWM'd output is going to the Cree at the top.)

I got the trick from these guys:

Photo by Chris Walsh, Cambridge UK.  Creative Commons Attribution 2.0 Generic license.

Well, maybe not him exactly.  From the First Imperial Stormtrooper Regiment, who pointed out that the cheap "MR16" constant-current supplies were based around the PT4115 step-down driver.  You have to solder to pin 3 of that SOT89-5 surface-mount package, but then you get PWM control from about 25% to full.

And this is something I'm really going to need, because each of the different lighting systems on the WIZ has a different voltage, different current requirements, and figuring out the central control has been a nightmare.  Especially as all of this stuff is heavy current draw, well above what my AVRs can handle on their own -- the WIZ will draw between 2 and 3 AMPS when fully lit.

At the moment, it looks like he will be using a 6-pack of AA or AAA to supply the 9-12 volts required by the MR16's.  There will be a DC to DC step-up to provide the 12 volts desired by the LED strips.  Then on the low current side, probably the internal 5V regulator of a standard Arduino, which in turn can source a measly 50 ma of 3.3 V regulated -- just barely enough to power an XBee in receive mode.

On the controller side, the XBee will talk serial to the Arduino over the UART, without level correction (the XBee's are generally 5V-tolerant on the serial pins even though that is out of spec), which will then  send PWM to a bank of TIP120 power darlingtons (the lovely ULN2803 can only sink 500ma total across all combined outputs, which is less than half of what I need).  And to the PT4115's.



And, lastly, I spent the week working on the VOX-BOX:

Sure, the box will be in the show.  So that part isn't a waste.  The, err, excess componentry is.  If you look at the picture, the first 8-pin socket held the LM741 balanced input stage.  Which didn't work, and is now jumpered over.  The second chip is at least useful enough; using an LM386 as a signal amplifier to boost what would be a reading of 0-40 on the Arduino's typical analog scale to 0-400.  Well, 500-900 -- doing it this way also offsets the signal, as it is in reality a sine wave superimposed on a DC bias.

And, really, the external Arduino was fine.  For that matter, a naked Arduino is good enough; leave off the input stages completely (the AVR inputs already have signal diodes and internal resistors on them to protect them from smaller voltage surges).  Or, for that matter, use a power NPN of some sort and keep the entire thing in the analog domain.  Because, really, there's all this software that is trying to simulate an analog response curve.

So I really didn't need to go through the effort of replacing the external Arduino with that third 8-pin dip you see just before the regulator and the heat sink.

Especially the way I did it.  I had problems just going through the Arduino IDE -- the original code wasn't so great a fit on the ATtiny anyhow -- and I spent several days learning how to do AVC native on the chip.  And discovered lots of wonderful useful things, but ended up going back to Arduino clone anyhow, after what I had learned on the C side let me fix mistakes I'd made in the wiring (for instance, using as a PWM pin the same pin the AVC uses as External Voltage Reference.  Something I could fix in C, but not in Arduino.)

I still have another tweak to make in the software as it isn't quite making full brightness.  And....

Lighting asked for independent control.  So there's one more input on the chip, and I'm trying to write some kind of bogus slow serial that I can send down that wire from an Arduino running at a much higher clock rate.  If I had two pins, I could use an external clock and basically treat it like a register.  As it is, my best idea so far is to do a slow PWM; count the ratio between high and low parts of a pulse that is sent at a crawling rate of perhaps 10 hertz.

But that means yet more time spent prying the chip out to write new software to it and sticking it back in to see if it works.  Because, like so many of the projects I have this week, the hardware interferes with the ISP pins and I can't actually do it in-system.



And....I am a MORON.   

These are battery-powered systems!

I hooked up two 4xAA packs to make a 12V pack, confirmed that would drive the Cree-on-regulator with PWM from an AVR, and the LED strip light.

And then I finally realized....I've got the batteries right there.  I can tap them arbitrarily for 3v unregulated, 4.5 volts unregulated, 6 or nine volts as required.  And everything still maintains the common ground.

Which means, especially if I can find some nice 4xAAA packs, I can do the whole thing with a lot fewer DC-DC regulation stages.