Way Hot

The delightful image above is from a lightweight but not completely horrible 1993 version of the venerable Journey to the Center of the Earth; another failed series opener released as a stand-alone TV special. It is much, more more Pelucidar than it is anything from Verne, but anyhow.

Weather is starting to cool but I'm walking to work. I'll see how long I can take this. Come the first of October, my boss is going to talk to his bosses about trying to get me a raise to something a wee bit higher than the new minimum wage.

The holocircuit has passed all tests.

Even with a mere 150 mAh lithium polymer cell I got seven and a half hours at the nominal/bright setting. That's plenty long enough. Unfortunately I'm down to scraps of acrylic...and Tap Plastics is inconvenient to public transit.

(No inconvenient to get to, per se. But inconvenient to get back from while holding unwieldy sheets of material that is quite capable of giving you nasty cuts. Bad enough riding BART with the things. Walking a mile in the heat with them is an experience I'm not longing to repeat).

The Internet of (Theater) Things

I was at Maker Faire this weekend, and like so many other parts of the inter-tubes it was all IOT, IOT, IOT. And I'm wondering if it is time to rethink the usual objection to using Wifi in a performance context.

The old assumptions were that wifi wasn't reliable enough for performance. But then, we used to assume computers weren't reliable enough. I have seen the pleasant glow of the Blue Screen of Death from a sound booth or two, but I ran into many, many more people over the years who insisted on using tape, cassettes, or (eventually) CD's for effects playback because they didn't trust that a computer wouldn't break on them.

Well, I think most people have moved past that. Computers have become the default for sound playback as well as video playback. Crashes still occur but they tend to get ironed out in Tech; the show-stopper failures I have personally observed have been due to the batteries running dry on a production laptop.

I've seen a slow movement towards acceptance of iPad links to sound boards. I remember when the Yamaha board was iffy at best, but now that Wifi link is considered reliable enough for use in the time-critical environment of Tech and Sound Check on a professional-level show.

(On the other side of the technology-adoption bell curve, I've personally run numerous productions with laptop and software tools due to not having the budget for rack-mount equipment. Sub-mixed drums for one musical on the laptop, and that worked well enough that on a later production I few all of the sound reinforcement through it, using freeware plug-ins within Reaper to achieve a graphic equalizer for the house speakers. My last show, I was running sound effects, projections, and even running lights from the one laptop. And I've seen a lot of this sort of exercise in similar improvised micro-budget shows.)

After all, some of the oldest documented theater technology was borrowed and adopted methods from Elizabethan-era sailors; rope rigging, counterweights, whistle codes. It's a natural path from there to modern techs using cell phones to communicate to back stage (instead of trying to come up with the money for the old-school hardwired headset systems). And a lot of people are using DAWs for sound manipulation or MIDI hosts for live keyboards, or (again on the other side of the technological bell curve) personal music players or similar software like iTunes for backing track and effects playback.

In fact, at some levels of theater it is considered ordinary and natural to plug an MP3 player into the sound board and hit one of those little fiddly buttons at the exact instant called for in the script. (Putting the sounds on the hard disk of a computer with sound playback software that was specifically written for performance use is the more reliable alternative now!)



Which brings us to a segue. Effects -- or more broadly, all the possibilities of both the established ideas of theatrical lighting properties and scenery, and the less widely accepted ideas of interactive technology -- are not exactly called for in the script. One even suspects that in the golden age of musicals and old chestnut standards, the Annie and the You Can't Take it With You, the writer brought the same awareness of what could be practically done with multiple settings in scenery and quick-changes in costumes to what could be achieved in the way of on-stage telephone calls and so forth.

Which is to say, most shows don't require really clever technology to get a sound or lighting effect to happen in the right spot. Between the way the script makes the timing of the effect non-critical, and the way the presentational aspect of the box set with the missing fourth wall et al makes playing a telephone sound out of a speaker appropriate and sufficient (or at least sufficiently appropriate), there isn't a need for something more elaborate.

At least, not there. When you get to more modern works, and better yet, to those experimental works that straddle worlds of dance, improvisation, performance art, et al, there are plenty of spaces to explore more complex interactions than "play back a sound effect at a specific moment in the dialogue."

Of course, these also tend to get worked out in development. Sometimes I have had a performer or a puppeteer or a musician or whatever come up to me and ask, "I'd like to have this happen when I do this; is it possible?" But mostly, a choreographer or a props person or someone sees something interesting that's already out there in the world, and the performance is designed around how that existing thing functions; designed to accommodate the existing advantages and the existing flaws.

(Specific case in point; in a production of Wizard of Oz we used light-up globes extensively. Each time these were brought out, there was specific choreography to allow each performer to turn their back to the audience and page through all the available colors in these off-the-shelf devices until they got to the desired effect for that moment in the show.)

So it seems to me that the process of using the kind of effect modern electronics makes possible starts from the Designer. Instead of problem-solving something that the rest of the design team would like to happen, you become the one to suggest an effect. Which means you are effectively working out of what already exists or is known to be possible, rather than working from something that wants to happen on stage and developing a solution to it.



For that reason among others, I'm not that interested in the experimental end -- in the kind of process that puts accelerometer-controlled LED strings on a dancer, or whatever. Because as I pointed out above, this is more a process of adoption than design. You more or less start with available consumer products, and you develop a way to use them over rehearsal.

My interest from pretty much when I started using electronics in theater (where the height of my technological output was sticking leaf switches around a motor-driven cam to create a hardware string light chaser), is to, well, I'd call it "sweetening."

Here's a conceptual framework from another industry. A movie is more-or-less filmed MOS. In the older days this was a technical necessity, these days it is an artistic choice. Dialog may be taken from the shoot, but the totality of the sound environment in the finished product is a created thing. This is for focus and nuance; the noise is stripped away, and the only sounds still there are those that tell the story -- and they are pushed, too, for artistic nuance and emotional effect.

And this process has already begun in theater. We can't pan, zoom, or cut; we don't have that control over what the play-goer watches. But we do control lighting and we build and even paint scenery to place the eyes and the attention where we want it and to make essential story-telling and emotional points.

And artificial sound has entered. Even in smaller spaces, even in opera, subtle reinforcement and other acoustic shaping is already taking place. In larger houses and in the musical dialog is already passed through processing to make it larger than life in the same way Hollywood takes the best the boom mics and hidden lapel mics can carry back from the live stage, marries those with ADR done in the studio, and presents the final honed and processed mix to the audience.

At the very simplest level, I think we can now have the sound issue naturally from an on-stage walkie-talkie or phonograph or bugle (or appear to), and we can have the light from a television or cell phone (or the lights of other items of technology) doing what seems natural for them to do. The history of technical theater is full of examples of sticking colored lights in empty TV cabinets and sticking speakers under chairs and otherwise producing these illusions. Well, we can do them better now -- even if that means just pushing actual video out through a length of VGA.

But at the more complex level, I think we can have a gunshot sound "right." I think we can have a sword fight with the exiting (and thoroughly fake) sword sounds of a movie. And more subtly, I think we can treat voices and footsteps so the actors sound like they are walking a marble hall instead of wooden platforming.




But many of these require wireless control. Props move. Actors move even more. Cheap wireless is one of the necessary parts to make it possible to bring this sort of realized environment, this sort of naturalistic (or hyper-naturalistic) stage environment. And it may be that Wifi and the IOT has reached a point of maturity where it can be trusted in a production context. And not just on experimental theater pieces with fourteen people in the audience, but in staid professional theaters where your equipment breakdown is seen not by mostly your own circle of friends, but by hundreds of people paying thirty-five bucks a seat.

Tilt

Ah, this is the point where it becomes engineering. I've threshed out options for the Holocron to come up with a compromise that meets the primary requirements of being cheap and easy to assemble. Now it is just about nailing down the specifics as I generate the final files; EPS files to cut the shell, Eagle files for the PCB, and of course a BOM for all the parts and materials.

Paper-doll trial layout in Fritzing

But it doesn't mean that discoveries have stopped. Far from it. First there was the discovery that USB can't safely deliver the power to run my first-choice of LED. Then more exploration; if downstream devices negotiate for power, what is the typical draw of a USB thumb drive (and is it going to interfere?)

Yesterday I tried to look up the typical value for a pull-up resistor on the RESET line of the AVR chip I was using. And after scrolling though several massive threads on StackExchance and AVRFreaks, I've learned that resistor is hotly contested but, in the end, omitted as often as not.

And today I was looking at options in tilt switches and discovered that the previous holocron I made was running said part well outside of spec. Typical current handling of these devices is 1 to 5 mA! So basically you use them as sensors, not as a power switch.

I want to do all this one did, but with a lot less mess.

So I thought a little about building my own (several Instructable pages are out there showing this), or about putting a weight on a lever switch. But, really, it seems an equally sensible design to leave it off entirely, instead tasking the capacitance sensor for turning the lights off and simply letting it run the battery down (until you plug it into a USB charge source again). Okay -- I might put a toggle on the inside anyhow.

Oh, yes, and there was a long bit of research to see if 1-pin capacitive sensing, with or without ATmel's own libraries, was going to work. The Capsense library in the Arduino Playground uses up two digital pins, and with an ATtiny45 I was already scarily short of pins. Which also meant yet more reading up to see what the drawbacks were of putting circuit loads on the MOSI, MISO, and other programming pins. (And yet more long, heated discussions to read at StackExchange).

From ArduinoCC

But in the end, it makes more sense to provision with the ATtiny84; not only does it separate all these pins, not only does it provide some extra pins for the end-user to get creative with their own sensors. but it then becomes more of a legitimate fork of the ATtiny84-based Cree driver board I was working on before.

Eagle file of the prototype Cree driver board. Which is also used in the Retro Raygun!

Of course it isn't necessary to go through all this merely to light a holocron. You can just stick an LED on a resistor and either put some batteries inside or cut up a USB cord. The intent here is for full RGB light which is selectable and animatable (aka pulsing, flickering, color swirl effects), and for operation fully unplugged with painless recharging. Oh, and the option to add a user-supplied USB memory device inside, making it a practical desktop accessory.

To achieve all that and keep the costs down, I'm pushing what was hand-wiring and various (mostly Adafruit) boards on the prototype into one custom PCB.

Another sideline I keep wandering down is the temptations of a custom-written GUI to control the thing. I only discovered recently that the HID standard is bi-directional, allowing the host computer to send messages to the hosted device. Which can be done even on the through-hole AVRs (even ATtinys) via V-USB, saving you from having to go through surface-mount soldering. Even though SeeedStudio offers that as a service now.

(Actually, I may go surface-mount with more parts than the necessary Lithium Polymer charge management chip, to save space. But the cool thing about the HID fork of the USB standards is HID is allowed to be low-speed without breaking the USB standard. And they are driverless!)

In any case, I'm going with the dreaded VCR Programming paradigm on this one. Because I can put three or four buttons in a small space and set them up as Select, Enter, and Decrement/Increment. And the advantage of this over an analog potentiometer is that this has memory; you start from wherever the value was last set instead of going to wherever the potentiometer was left. (And the advantage to me is I can tie them all to a single analog input pin with a simple resistor ladder).

(And as I wrote the above, I realized a rotary encoder would also serve. And you can get a quadrature-encoded one from Bourns for about a buck fifty. Hrm. Yet one more thing to make a determination on as I try to move to final PCB layout.)

Fish and Chips

The Irish pub near me does a decent fish and chips. I've been making a semi-regular Tuesday thing of that. On Saturday, went to see the show I lit, and at the end of curtain calls the producer came out and made me stand up to be acknowledged. That's neat. At my previous theater (the one I mixed shows at for over five years) they had a "nice" habit of giving special thanks to all the designers at the big opening night bashes. Except for sound. They never mentioned us. Once again, I'm reminded of how well I am to be rid of those people.

This week has been slow. I've been putting in a solid forty as I wait for the new hourly position (and the pay raise and benefits) to start up. Wouldn't bug me so much, the waiting, if they hadn't gone ahead and promised it. Four months ago. I want to stay there. I'm making the schedule work, and I can see retiring in that job. I mean, against the rather unlikely chance that WETA workshop will suddenly phone and tell me to catch the next flight down to New Zealand. But still being on the Temp Agency and still getting only a little over minimum wage is really starting to irk.

And that's the news from Lake Woebegone.*



Sometimes I think engineering is about knowing the right questions to ask. I've been complaining recently about black boxes in modern electronics. There's so much imbedded intelligence in everything now. Take the "humble" lithium polymer battery. You'd think you'd look at the chemistry, check out graphs of charge and discharge curves versus internal resistance and heat dissipation and so forth. Well, not exactly. Tucked beneath the foil jacket on any decent LiPo is thermal monitoring and overcurrent protection and a nifty little voltage monitor that won't let you bottom out the charge.

So it becomes a lot more about looking at lists, of truth tables instead of graphs, where digital switches will be thrown inside the black box when certain conditions are met. And not everything is documented, so this has a lot of what old-school programmers will call the Deep Magic or other Incantations; little tidbits of information passed hand to hand like secret rituals.

But then, a lot of engineering is about how to make use of existing solutions. You don't want to design a wheel every time you need to build a cart; you go out and find a wheel that someone else has already done the heavy lifting on, and compare the final tested performance of the thing against the requirements of your project.

And even when you are working down to raw materials, there are rules of thumb and working formulae and other places where someone has done the measuring and the tabulation and the algebraic manipulation and the empirical results for you, so you can apply an industry-standard calculation instead of having to sit around in a lab discovering melting points and so forth for yourself.

Anyhow.

This is all sideways to my latest work on the Holocron. It occurred to me to take a closer look at the current draw. And there I hit a big snag. The rule of thumb for LiPo cells is maximum current draw is the same as maximum charging current; half the capacity (in milli-amp-hours), expressed as milli-amps. (A safer working value is .2 C) Well, that's fine; the cell I had in mind is a 2500 mAh battery, meaning I can draw up to 1250 mA off it, and two channels at 350 mA is only a little more than half that.

However. The design is that it will run stand-alone on rechargeable battery, or it will run from a USB port and charge the battery while doing so. And anything above 100 mA breaks the USB standard. (Sort of. It's actually rather complex. The USB standard permits current draw of 500 mA if negotiated by the device. But not all computers and certainly not all hubs can supply this safely. Off the standard, devices can and have drawn as high as 1.8 amps -- but this is nonstandard and unsafe.)

Even if I accept 500 mA as the cut-off, I can't power the LiPo charge circuit and still be able to push two 350 watt LEDs. And even if I shave the power requirements; run the LEDs at half the rated current and a 50% duty cycle, it still ends up exhausting the battery in a mere four hours.

So, yeah. Somewhere down the road I'm going to need or want a gadget that can push that 1-2 watts of LED, but the Holocron is not the appropriate project for it. Nor do I think it needs it. So I'm back to neopixels. Especially as I figured out the easy assembly for them; use the through-hole mode and simply bend the pins 90 degrees so they all face out in a wheel.

And here's the math there; 20 mA each (per channel, that is). At a single color and four of the units, the MCP73831 will handle them with a little bit left over to recharge the battery, and the draw is only a little over the 100 mA USB standard.

Of course some colors are best achieved through running two channels wide open. That would be 160 mA and I'd have to push the MCP73831 up to a 250 mA charge rate in order to ensure there is enough current. But that still beats trying to come up with 1400 mA.

And four neopixels worked fine in the first one.

The big trick in the Holocron -- all of the design, not just the electronics -- is to make it as cheap as possible and as easy a kit for the customer to assemble as is possible. So I'm happy to avoid needing surface mount components, but I'm willing to spend a little extra to keep from having either of us have to fiddle with hand-soldering micro-USB connectors.

And this applies in force to the programming. Yes, there are ways to provide computer control for customization. But even the best of these require dealing with drivers for a huge variety of operating systems and even if I could handle the programming I'm not up for the support. So the only user customization I can support with this go-around is on a primitive "VCR Programming" level; walk through menus with one button and change values with another one.

But I think I can do it within an 8-pin ATtiny, which means I don't have to play with a surface-mount component for the main CPU. It is tight, especially when I add a general-purpose "sense" pin (probably tied to a capacitive sensor, like I did with the first Holocron).

Now I just need time to Eagle out the new circuit board, and Inkscape the new design elements. Oh; I made one other bit of progress. I checked scale, and I'm happy staying with 4" outer dimension. Which means my already built and tested outer shell files can be re-used.



*It somehow feels deeply meaningful that Apple's spellcheck is still staggered by basic scientific and engineering terms but has no trouble with "Lake Woebegone." It also passes, without comment, "Darth Vader" and "Frodo Baggins."

New Instructable

I put up an Instructable on the raygun, mostly to collect the basics of the build in one place. And it got an editor's pick.

I'm of two minds about that. My first reaction is the world is being unfair in my favor. I look at the other work people are doing, and I look at all my mistakes and my sloppy, unhelpful Instructables, and I'd say pick someone else to honor.

But then I did a search for other people doing AVR projects. And a lot of good work, but it is odd that so far every single LED fader project I've seen continues to use power darlingtons as switches (well, sometimes MOSFETs), and usually resistors as current limiters, and the clock-cycle hog of Arduino's digitalWrite() function when doing software PWM (instead of direct writes to the port). And nary a one of them includes a gamma function.

Okay. I've seen a better gamma; I'm using a crude, hand-drawn look-up table. I've seen someone who calculated it properly -- and if running on a fast enough processor, you can do the calculation on the fly. My current gamma table is also hand-optimized for "Piranha" RGB's and doesn't look right on the 1- watt-and-up "cree"s.

Also, I'm probably the only person crazy enough to calculated fractional changes using a long INT, allowing a single gradual fade from one specific color mix to another. (Which makes the key line a rather daunting "if (gamma[BYTE(long INT)] == PWM_clock)) ...")

Gah Software

In Star Wars (the first film, the original film, which is to be known as "Star Wars," period) a small farming homestead purchases a droid that can speak Bocce -- purchases a functional AI because that's easier than learning the computer language some of their old evaporators use.

Meanwhile on Next Generation and later, everyone can use everything that has microcircuits, and there's never even a moment of realizing the docs are all in Klingon or whatever. I think Star Wars gets it a lot closer.

Anyhow.

I've been really sick for a couple of days. And spent it delving into some software I haven't used in far too long. Still learning my way around GIMP, getting better with Inkscape -- and flipping back and forth between those two with great rapidity as I develop the most recent iteration of the Holocron:

This image is watermarked because the art for this one I want to keep exclusive to the client that ordered it.

And I'm pretty much volunteering the design time, but aside from the vector on the center image, it is all re-purposable for the holocron kits I'll be offering soon at the RPF.

I'm going to be able to offer a fair number of customization options right off the rack, plus option to do new design work as I find time.

Perhaps I'll even some time solve the assembly issue. I've seen some Holocron designs that use a staggered outer edge to hide the way the shell has to be assembled: and those would not need to be sanded and painted.




Anyhow. Figured out an option for the DuckLight battery issue and rigged up a quick test with the prototype; hooked the main circuit to regulated 5v, and plugged the Cree into a separate 4-cell battery pack. It seems to deliver almost the output I achieved with an overall regulated 500ma power supply.

So the scheme now is to add a 3.3v LDO to the PCB. It won't be that wasteful of space; I already need to add the filter capacitors to stabilize the ATtiny.

Pity there's no easy way to cram that in to the current PCB so I could do some proper in-place prototyping. But the boards were only ten bucks.

For completely random reasons, I spent most of my sick time messing around with a software I'd started to forget. Poser. Poser 9, to be precise, which saves all the parts of the interface that worked badly in Poser 6, and adds flash-driven menus that work poorly, non-scalable interface fonts, and other nice little details that make it excruciatingly inefficient and frustrating.

It's worse than that. I also flip into Poser 6 when I'm rigging a prop, because it is simpler to work in and makes cleaner files.

And for some stuff, DAZstudio is a little easier. At least the camera is superior. But of course the interface is entirely different, in almost every way it can be.

I'm really not looking forward to having to go back into Carrara, but I have some modeling projects in the pipeline that need it. Well, that or Blender...and I'm still having terrible trouble coming to grips with Blender.

Even Fusion 360. Some of the specific curves and edges I need out of it are far too difficult to
achieve inside the interface. So like pretty much everything else I do, I need to flip the meshes into another application to do some work, then re-import them.

And I just realized it has been several months since I last used that software. They've probably changed the entire thing by now!

At least EagleCAD was a relatively small learning curve, and shouldn't take too long to pick up again...

Knot Working

I still need another job.

The props stuff is keeping me busy, but with only a sound op gig, a small lighting design, and some microphone rentals I'm just barely going to scrape by.

I was messing around with knotwork today -- or more specifically, looking at a lot of stuff about Islamic interlace patterns. The idea was to work up something for my new Jedi Holocron project that takes the "Millennium Falcon Circuitry" pattern of the last one and moves it to more of a repeating decorative pattern...and the religious-art connotations don't hurt, as this is a design for a Jedi Temple.

Not sure why I thought of going in that direction. Maybe memories of the fantastic clockwork facade of the Institut du Monde Arabe in Paris.

So I'm slowly getting used to both Inkscape, and GIMP. Flipping back and forth between them is still...interesting...however, as the key commands are completely different for each. In fact, because Inkscape is running on Xquartz via a Java VM, it remaps command (Mac standard) to control. So something as simple as saving the file takes an extra little bit of concentration.

I still have no idea how to proceed on my power issues with the DuckLight. Seems like I need to live with the idea of larger battery packs if I want the full output power, and add on-board regulators. Which not only adds parts, and footprint, but also means you'd have to change jumpers or something for all those applications where a smaller battery pack is more appropriate. 

Hrm. Maybe regulating the ATtiny down to 3.3 volts regardless of battery source makes the most sense. 2xAAA just doesn't light anything but a red LED anyhow, and that's the only set that would be too low for even an LDO. And with a powerful enough regulator, it could supply an XBee, meaning I wouldn't really need a custom daughterboard for those.

One thing I have figured out is what I want to do with those flexible USB lights I picked up for a buck each at Wallgreens. Make little Steampunk-Tiffany task lights out of them. Add a laser-cut acrylic clip/magnet on one end, paint the flexible rod up a nice brass, stick a super blue LED in, and pull some painted/dyed PETG over a hand-carved buck to make a shade.

Now if only I had some sketches I liked for the Raygun. I need to start getting client approval and move into the next design phase!

Jaffa, Cree!

Oh, did I make that joke already?

Internet is back, BTW. It took eight phone calls, an hour of navigating phone "help" menus, three service calls, and over a week...but they finally figured out the modem was dead. You'd think they could ping it and find out, but apparently that particularly modem typically fails in a way that looks like a bad line from both ends. Funny thing is, not even the service techs...two of them, lugging bags of electronic gear from their van...had tools to see if the line actually connected. Only a DSL modem will actually tell you anything, and because of the secure installation procedure it is non-trivial to swap in a test unit.

Only good side to the affair is it gave me the excuse to yank my old desktop and monitor and all the associated cruft and clean up under my work table. It looks much neater and cleaner now, and I can use my scanner without getting a back injury.



Discovered a puzzling problem with the DuckLight board. I noticed it was much brighter running off the 5v regulated supply of a USB port than it was off the 3xAAA battery pack. I thought this might be an amperage issue but a little more experimentation shows it to be voltage related.

Which is odd. The forward voltage of green LEDs is under 4 volts (3.7 seems typical). The voltage drop of the AMC7135 chip is a mere 0.12 volts. A 3x battery pack should thus be quite sufficient.

Oh, but wait. Calculating with the smaller voltage of nickel-metal hydride (the Sanyo Eneloop rechargeables I use almost exclusively) brings the 3x battery pack to a mere 3.6 volts. Which is far enough into the curve to experience a significant loss of luminosity.

And I had already discovered that on 2xAAA (my designed footprint for the first board) only the red LED lit properly; the green was obviously not getting sufficient voltage.

Well, shucks. The rated output on lithium polymer packs is 3.3 to 3.7 volts -- meaning once again that the most common green LED chemistry won't light at full power. Especially not if I try to run a 3.3 volt bus (to allow direct connection of certain sensors and XBee radios).

So what are the options? Switching to alkaline is not actually a help. Alkalines drop very rapidly in voltage from full charge. In addition, their nominal rating is given in no-load -- unlike NiMH's, which give the nominal voltage rating under design load (due basically to lower internal resistance).

Going significantly over and regulating down to 5 volts would make sense for a more complex project. At a draw of 1 watt or more, though, that's a hefty regulator -- and a lot of heat from wasted wattage. A dual NiMH pack, for instance, regulated to 5 volts, would have to burn off over five WATTS. That's at the peak of what a TO-220 package can handle with a bolt-on external heat sink.

Splitting the difference, a 4x battery pack delivers 4.8 volts nominal -- that's pushing up to 1/4 of the wattage into the regulator, which has to burn it off -- and at full charge can get pretty close to 6 volts. Which fortunately is while out of spec still within the range of what the ATtiny can tolerate! It is also twice the footprint of the board in flat pack and basically annoys me as a form factor even in quad.

(And in case you are wondering, all those Cree flashlights get away with it because "white" LEDs have a lower voltage drop than the common green ones.)

And, bah -- four fully charged eneloops are sufficiently above the voltage spec that the ATtiny shuts down. Which means I would need to include an LDO in order to operate the green LED at full efficiency.  Or....regulate just the ATtiny, perhaps at 3.3V for sensor and XBee compatibility...well, according to the literature the AMC7135 really likes to be between 4.5v and 6v. Gets way too hot above that. Like most LDOs, the highest efficiency is when the voltage in is very close to the voltage out.



Well, I still have to finish porting my "blink" code to the new board, and see if there is even possibly enough space left over in program memory to do any of the other tricks I want. One issue from the old Piranha board that the Cree makes a lot more of a problem is the stair-stepping at the low end of the intensity scale. With only 255 steps in my pulse generator, the difference between 1/255 and 2/255 is a little too obvious in LED intensity. So I'm reading up on dithering techniques.  (I can't simply increase the PWM bit depth, as I'm running at 8 MHz on internal oscillator and the PWM frequency is already close to critically low).

I also need to do a bake test to make sure the system can handle being ran wide open for a significant interval. I've already noted that 3W is at the low end of theatrical viability. Fortunately, a lot of applications can be served without full RBG -- instead hanging a 3W or even 10W single-color LED on the board and running the current regulators in parallel mode.

Another change that's on the horizon. The old RGBs are slipping in the Chinese suppliers to make room for new cheaper RGBW's. So far no affordable RGBA, but I have my eye on a few affordable RGB-Warm White already. Which is why my board is a four-channel. And why the ATtiny84 -- to give enough extra I/O pins for external sensors/controls. Although I still may end up just going into an ATmega eventually. Especially if I chose one with native USB support. Those are nasty little surface-mount jobbies...but at least they aren't BGA!



I'm also seriously contemplating revamping my headers completely and making the duckNode Trinket compatible. There's a LiPo backpack in that format, for instance. And in the obverse, I could make my XBee shield cross-compatible. The downside is I want to achieve everything possible from the ICSP header alone -- plus a stand-off, which the current iteration omits -- so there is no need to solder header pins to the board in order to program it or even to integrate it with radio link or power regulation. Having pins soldered on is one more thing to work around or to have to remove when cramming the final board into a prop, and the whole purpose of this exercise is to produce the most minimal footprint, lowest parts count and cost to bring full PWM control of 4W RGB/RGBW LEDs.

(So many TLAs there, I'm starting to feel like I work at NASA!)

Dead Head

Ran out to the Rose Garden to take some pictures, but the roses are very much not in bloom at the moment. Whoops. We stayed until it got cold and dark anyhow. Yes; a sheet of foam-core works very well at providing a nice diffuse fill light....when there's enough direct light falling on it.

Ran the prototype current-controlled DuckLight for about four hours without any sign of overheating or the LED being overdriven. Next I think is an acid test; put a minimal heatsink on the LED and run it full-out for an hour or two. Those AMC7135's are totally the ticket!

The Holocron enquiry got one response. I'm working up a new Holocron design for a Jedi Academy now. Have in mind a combination I think will work, but haven't actually gotten into Illustrator (rather, InkScape) yet.

HP is now on my "nice" list. The scanner software I was using demanded I upgrade, told me upgrades were no longer free, and threw up its hands when presented with a 64-bit OS and what was apparently a 32-bit scanner driver. "Go call HP and see if they have any drivers," was all the software could offer. So I did, and HP had...a completely free and compatible scanner package I'm using now instead.

And I finally got off one sketch of the "art gun" direction for the raygun commission that I actually like.

Sure, I have to work on the proportions some more, and I have no idea how to machine some of it, but it in my mind finally achieves that blend of looking like the shape came out of art school but the details and machining are tight and quality.

It may not be quite period-looking enough, though. (Especially since to my mind the perfect combination would be stained and varnished wood furniture, and aluminium parts anodized in a pale green.)

So continue the sketches. Eventually I'll stumble upon a few that are decent enough to show to the client.

Nile Project

Started the school tour (9 AM performances!) That show is open now, so another plate is quietly spinning...

Also shipped the next eight M40 grenades. That makes 35 of the things I've sold now. The new
processes didn't work quite as well as I wanted, and I still need to purchase some new tooling, but it got down to under three hours of labor each -- less than two for the machining.

Someone asked for the files on the Holocron and I've gone ahead and indicated I will produce a kit if requested. Perhaps I should start an INT thread at the RPF as well?






That makes the prop priority the Raygun. Although the final ship deadline is a ways off, it would be better business if I got it done a lot sooner -- soon enough for other "space tiki" fanatics to decide they want one, too.

And the AMC7135's I've been waiting on finally showed up. I enquired at a couple local stores for solder paste and checked prices at some online suppliers, but I was able to solder up the first SMD with a regular iron and some nice Kester silver solder I picked up at Al Lasher's Electronics.

There's a few mistakes on the PCB. I expected that. The trimpot sits too close to the ICSP header, and I'd managed to mis-identify the correct external clock pin for programming. Well, that's what jumpers are for.

The main purpose of the board was, after all, to test the AMC7135's. And after I fixed my screw-up with the ICSP wiring, it came through. I had to stop the full-power test because the LED needs a heat-sink if it is to be operated all out, but the AMC7135's appear to be limiting the current quite nicely, AND are responding correctly to the ATtiny. After a couple of hitches I have software PWM running. Seems a wee bit unstable -- so when I make the next version it will have a filter cap across the power lines of the DIP, and perhaps something on the RESET pin as well.

But before I get deep into revamping the PCB, I have software to write.

Begosh

The first PCBs arrived from OSH Park:

I partially populated one (nothing's soldered yet) to check if the footprints I designed in Eagle matched the parts I ordered from Digikey. So far, so good. Except that the key part -- the current limiters -- are coming via "International Airmail" from Fasttech and there is no tracking available.

Assuming the AMC7135's work -- which is really what this board is intended to test -- I already have a few ideas towards the next iteration. Probably drop the breadboard spacing for the outer pins, go to a lower profile trim pot and switch to SMT for the LEDs as well (so I can add more blinkenlights -- serial data, the traditional "pin 13 LED" of Arduino compatibles, and of course keep the power light.)

And I haven't quite figured out the best format for the XBee backpack (plus I keep searching for more budget-conscious alternatives to the XBee).

Here's what the board replaces:

That's the quick-and-dirty vero board version I made for the radio light. Only two channels on this one, as I was mixing red and green LED for a sort of amber light. That toggle you see is hot-glued to the side of a AAA battery pack. At least this iteration had the ICSP header, making it a little less annoying to tweak the software.

It was sitting inside this prop:

(Dress rehearsal photograph made by Anna Kaminska for Actor's Ensemble). Also taken before I replaced the ailing previous circuit with one that could reliably generate a decent amber.

So, sure, the new circuit is smaller, and as fast as I am with the vero board (or, rather, the somewhat expensive but totally worth it "Perma-Proto" stripboard from Adafruit) having already wired and partially programmed versions should make it a lot easier to add it to productions.

But more than that -- with wiring and programming already in place and basic options available just by turning a knob and hitting a button, this should be useable by people who don't have the time and experience to learn all this stuff themselves.

Laser Rifles and Dying Fairies

Not, not "Wizards, The Musical" (which one day, in some other life, I would love to have a part in producing).

I took a short job in The City -- for low enough pay a third of it is going to pay BART fare -- and once again an application came up for a DuckLight. Which is currently in the form of a PCB being manufactured in China. That is, the prototype board is. I figure there's about a 50% chance the first board will actually work correctly.

Once again, I would have saved a lot of time if I could have just reached into my kit and pulled one out. But also, once again, I hadn't imagined anything like this application until it came long.

Tinkerbell. There's a spot in the musical where Tink needs to go into her little house and stay there for a while. I had already planned for one of the default animations on the DuckLight to be a flicker or shimmer, but I didn't even know why I wanted that. Now I do. Dial up a nice Tinkerbell green and the effect is half-way there.

Only half-way, because this production is children's theater. No onstage actor is going to be able to hit a switch. So it needs the next element, the next board up in my Eagle-and-fab list; the XBee backpack.

Well, I did pull a morning of very swift soldering, and set up a single-channel AVR-controlled Cree and attached an XBee to it in line-passing mode. There was some strangeness going on with lines floating or automatically resetting or something but by adding a double-click detect I finally got it reliable enough to use it over the closing performances.






Otherwise Tink is being played by a laser. Which still makes me uncomfortable, even though I opened up the beam focus until the power is much spread out. To hit his targets the follow-spot operator went and attached the laser to three-foot long stick of wood that he braces against his shoulder. Naturally I took to calling this contraption his "Laser Rifle."


Being one of the bargain bulk optical goods from the industrious young engineers in Shanghai, this particularly laser diode is not stable enough, cooled enough, or otherwise suitable for leaving on for longer than a few seconds at a time. As a stop-gap, I put an AVR-powered switch on it that randomly blinks it off for half a second or so every few seconds. That seems to help, but I'm betting I'll still be out a laser diode before the show closes.

The blinking looks quite natural and Tink-like. Particularly tonight's performance. Right after Wendy said, "Wouldn't you say so, Tinkerbell?" the light blinked several times in quick succession as if Tink was making an acerbic reply.

Here's the full circuit in better light, by the way:

The 8-pin dip is the ATtiny85 running the random blink routine. The Tip-120 switches laser power, with a blinkenlight wired in parallel as a status monitor. Another one monitors the battery connection, which is switched on and off by the momentary button. That's the nice thing about these AVR's; supply power, and it boots up softly in milliseconds and starts running the program loop.



This was all in all another informative show. I need that serial Xbee connection for reliable triggering, and this makes twice now that 3 watts of RGB was a little marginal. Unfortunately the jump to 10 watts of LED power brings in a whole new level of current regulator and thermal management complexity.

CAD Woes

Trying to get the PCB ordered on my prototype "DuckLight." The first Eagle layout looked pretty good, but it seemed possible to shrink the board's footprint until it was only 2xAAA wide. Which you can run on, but it runs the LEDs a little cold.

Anyhow, I shrunk the layout and ran traces by hand. I was also conscious of the potential difficulties in soldering SMDs so I made a point of holding the traces far outside of the pads of those parts. So that took a couple of evenings. But got it down to one via (well, I also ended up omitting a duplicate VCC on the second header. It would have required multiple vias in order to get the connection.)

I used a part with internal connections (a tactile switch) as a jumped in one spot, and Eagle kept flagging it. So I went to the forums for the first time with a question. And it turns out not only have lots of people asked about this, there is no current solution.

But then I went to order the parts to make sure the ones in the CAD were actually available stock. I'd used the SparkFun Eagle library in several places, and you'd think this would be a shoe-in, right? But no. The part in their library doesn't actually have an analog in their store.

They did have something in their store that I could modify the package to, however. And after a bit of struggling re-routing around the new (and larger) dimensions, I had confirmation of available parts.

The final DRCs, and Eagle starts throwing up mask errors. Turns out that, yes once again, many of the library parts I was using have a silkscreen that goes over the copper traces. Which can be a problem at smaller fab houses that don't have the software to fix this on the fly. So back once again to the package designs, now to edit all the silkscreens.

Nice of various people to make libraries available to everyone, but really, could they adhere a little closer to reality?

Wanna Flyyy with the Eagle, Make PCs...

...Try out the Eagle 'cause the non-profit version's free!

After reading that Fritzing was not recommended for SMT components, I loaded up EagleCAD again to give it a proper try this time. And I like it. Fritzing is still low-key, friendly, and amusing, and the graphics for the Breadboard mode are excellent for things like Instructables and also for working out gross component arrangement. But Eagle is serious CAD, with lots of good tools.

The organization of the parts libraries still confuses me, but I was able to at least create the custom parts I needed and place them in a directory where I could find them again. Above is the first attempt by the auto-router -- it looks surprisingly good, but I suspect I'll be hand-routing some traces.

Now that I've seen it is rout-able, I can work on the footprint a little more. I'm hoping to get it to the same width as a 2-pack of AAA batteries (even though my optimum design is now 3xAAA -- and that is also the version which is getting tested in a currently-running show).

The SOT-89 packages for the AMC7135's are the only SMDs on the board. I may turn some of the other discretes and blinkenlights into SMT components, but the big footprint hog right now is the I/O pins. I have them spaced right now for breadboard compatibility, but it may make more sense to move and condense them.

I'm also tempted to run off a 3-channel version with an ATtiny85 CPU. Smaller, sure, but also less parts to get wrong on my first venture into getting a board fabbed, and soldering my first SMDs.

Computer-AIDED Design

There's still a trend in some circles to think of 3d printing, CNC, et al as being "too easy." That instead of all the work of carving and sanding and machining, you just "press a button."

Well, like the story of Basho and the Fish, getting to the point where you press that button is actually a lot of work. What these new tools are, is just another form of jig (or "tooling," if you want to use the fancy aerospace term).

I used a lot of jigs when I was a full-time theater carpenter (that is, a set builder). We'd spray-paint them red so they didn't get thrown out by accident. One show I had to make a whole bunch of fake bolt heads as decorations for some massive girders. Underside of a bridge or something; I don't remember now. Ripped down 1x to 2", cut it into 2" squares, cut off the corners to make a hex shape, then routed around the top. I spent most of a day making a complicated jig that would hold the thing in place for all the cuts and routes.

Which is the thing, here; if you save any time with 3d printing or CNC machining, it is when you are building multiple copies. The savings, if any, are one of those economies of scale. I could have scratch-built a V150 armored car in less time than it took to make the 3d model. But since the model was made, we've printed four or five of them (plus there's at least two others out in the world).

And, well, you'd think -- for all that computing power you have to throw behind the design process, it still takes horrendously long.



On the 3d side, I've been working on my M57 "Clacker" model to make it 3d-printable. Apparently, some people have used them to make an e-cigarette! Seems like it would be useful anyhow to work up as some sort of general-purpose button-powered prop. But low priority project. Also working on the V150 model again. Someone over at Shapeways has an interest in seeing it in 1/18th scale. Which requires a higher level of detail than is currently in the model, but I have also slowly been working it up as a Poser version anyhow, so that's been happening already.

My old penlight finally died and I thought of yet another project that would be very cute. To wit; a penlight in the shape of a Sonic Screwdriver. But not any of the existing ones; a very small one built around a single AAA cell -- not the dual AA versions which won't fit in a pocket, or the ones using weird rare batteries that are a pain to replace. AAA, with a boost circuit driving half a watt of narrow-beam colored light (we almost always use colored light backstage. Tradition.)

But that requires going into the CAD software and figuring out a casing that can be printed or machined that fits the available components and looks at least something like the sonic of choice (I'm partial to a War Doctor sonic, myself, which is basically a Tom Baker sonic with a different top).

Also back on one of those rear burners is the Jubal Early CNC model. And a turned flash hider for a "King of the Rocketmen" pistol.



I just got another order for "Aliens" grenades. And since I'm overdue for it, going to revisit the process and some of the measurements. And purchase some new lathe tools. And that's not (mostly) on the computer, but I still think about building my own versions of some of the variant ammunition, and that's probably best done in a CAD application. With an eye towards printing, casting, or even perhaps injection molding custom caps.

Although I need to order metal and tooling now, the priority machining task is finishing up the Suomi. I have been reading about silver solder and I think I might fill some of the smaller remaining voids with that and deal with the way it will alter the finish in those locations. They are mostly hidden anyhow, so I think it may be okay. Most of the work on this is pretty primitive, though. I did a lot of the milling entirely by eye. Heck -- I didn't even calculate my feeds and speeds, but just set up the mill by ear and instinct.



I've been really pushing on the DuckLight PCB -- working it up in Fritzing at the moment, which seems to be working and saves me the time of learning Eagle properly. Using the prototype in another show helped a lot. I'm getting excited about this thing and think it may be a very useful little trick for the prop-maker's arsenal.

I'm going with an ATtiny84 now. Four channels of software PWM current-controlled to 350ma means you can run a cheap RGB "Cree" LED, an RGBW, or a single-channel LED of up to three watts in bridging mode. ICSP header for the experienced programmer, software serial I/O...and there's enough I/O pins left on the '84 to put in a Program Select button. So the end-user can dial up a bunch of basic effects right on the board, without needing to connect up a computer. The XBee option will be on a daughterboard, though; there's just no space for the pin footprint.

I fully intend this to be offered in kit form. And at this point I've solved enough of the electronics and programming issues I really am ready to make up the first batch of PCB's.



If that wasn't enough light, I have a second order for the LED stage lights I built. Now I just need to get the client to pay a little better piece-work for assembling them...

Flash! Aaaaah....!

Between shifts over the run of Nutcracker I've been getting a lot of work done on my RGB light. Finally tracked down a constant-current driver that seems nearly perfect; the AMC7135.

Back up a hair. LEDs are current devices. Once forward voltage is achieved, current flow will increase near-logarithmically over only small increases in voltage; a runaway process leading to overheating and breakdown. Thus current limiters are needed.

The most basic is a series resistor. Basically, the resistor is chosen so that the current across it (calculated assuming the voltage drop across the LED is constant), is the same as that desired for the LED. Pick the right resistor, the loop current remains under the limit. The problems are two; all the voltage above the necessary forward voltage of the LED is transformed to heat in the resistor, and, the resistor is only of the correct value when the voltage is stable.

The better regulation is essentially a transistor that uses the current flow in a feedback loop, thus holding the current at a desired point. With the right components, these circuits will compensate for a range of voltages and, as well, react thermally in the correct direction to compensate for the changing behavior of LED and circuit as it warms up.

However, the typical packages I was finding were a couple bucks each and required up to a dozen external discrete components; capacitors, resistors, signal diodes, zener diodes, even inductors. Which was a lot of parts to be adding to a small board especially when I wanted to control three channels or more of LED.

But the AMC7135 is the ticket. Unlike many current limiters, it is preset internally to 350ma. It requires essentially no external components. And it may be a usage that's out of spec, but it can be successfully PWM'd. There are in fact high-end flashlights that use this exact circuit.

Again to step back; LEDs require a minimum voltage, and when this voltage is achieved will consume as much current as you let them. This makes them poor candidates for resistance dimming. The best way to control their intensity is to turn them on and off quite rapidly. By varying the ratio of time on to time off, you achieve a nice control of intensity.

Do this to red, green, and blue LEDs and you can achieve a decent range of colors as well.



Which is what I've been trying to do for over a year; to create an extremely cheap, small, high-power colored light that can be used inside props, on costumes, and in other theatrical applications. There are a lot of commercial packages that are similar, but few offer two of the things I find important for this application; tight control, and battery power.

Control turns out to be the sticky issue. What I really don't want is all those cheap LED toys; things you have to hold down a button and scroll through different colors to get to the one you want. This is non-optimal for theatrical use. It should be able to be set so when the actor (or the light board operator) hits a switch it lights up the right way the first time.

Proof-of-concept; ATtiny controlling two channels of a 3W LED via darlington transistors, on a 4xAAA battery pack. When you hold down the button it does a candle flicker.

There are also commercial products that allow you to dial up a preset -- from infrared controllers to full DMX-512 wireless solutions to the pretty-durn-close BlinkM. Where all but the BlinkM fail for me is that they are fiddly (or expensive). We don't want a lighting controller gaff-taped to a nearby wall with sticky tape pointing at the right preset. That's just another kind of over-complicated work around. Again, we want a user-programmed preset. After the light is set, it just plain turns on.

The only real failings of the BlinkM for me is lack of power for theatrical use, and some lack of flexibility in the existing controller software. Which might just be a conflicting paradigm thing (they went with a drum machine model for animations, I went for a flexible event-based system for mine).

The BlinkM from ThinkM.


So...I've had the high-power, hard-programmed RGB working. I had it on a costume in a show, and over the show it did exactly as required. The problem is, setting the desired look was a programming task. It was done with the skills, the knowledge of the circuit's behavior, and the programming tools I own.

The "Wiz" jacket, switching between free-running light animations when commanded remotely from the simple GUI shown on the laptop beside it.

What I want is for anyone to be able to purchase a kit or make the open-hardware light, set it to a theatrically useful look (oil lamp, say), and be done with it. But I am having no luck making the power I desire accessible to the end-user I envision.

Also, on the hardware side, if I make each individual light capable of simple stand-alone programming, it increases the unit cost. It makes too much sense to offload as much as the hardware as possible even if that does mean the end-user needs a minimum of two things to get started instead of one.



Hardware USB is the most transparent option. To put it on each individual light, though, increases their cost excessively. Plus the varied solutions are non-optimal in different ways. USB is a complex protocol, and there are no all-platform open definitions for producing a virtual COM port from it -- which is what is needed to allow one to write a nice user-friendly front-end (or even to surf in to the device via Terminal and program it on a command-line basis).

The older Arduinos used a translator chip from FTDI to handle interface to the user's USB port -- which also required a driver to be installed to show up on some platforms. There are AVR chips that are USB-native, but like the FTDI they are surface-mount devices and add considerably to the cost and effort of putting together each light.

HID is actually a lot easier; you can get a class-compliant HID with out-of-spec modeling of proper USB behavior, and it will still be recognized by most computers as a keyboard. There is even a clever hack that translates extra characters on this virtual keyboard into a fake serial port. But it requires multiple pieces of helper software and probably doesn't work on Mac yet.

Clever Arduino compatibles like the Trinket get by because the programming port used by avrdude is not per se a serial port. Basically, you can program an AVR using another non-USB compliant AVR (or even program itself with a clever enough bootloader) but it can't be made to show up as a serial port.

So, unless I want to write a wrapper for avrdude that presents a simplified GUI to the end-user but invokes the avrgcc toolchain behind the screen (too many pitfalls there I'm afraid), the best option is to move the expense of this USB-to-serial translation off the light and into a second board.

The BlinkM does it quite cleverly. It is programmed via a I2C connection, which is done using the soft serial code on an Arduino. Simply put, you plug the header of the BlinkM into matching pins on an Arduino header, run the provided Arduino sketch to turn the Arduino into a I2C to USB translator, then run the BlinkM programming software.

Somewhat similarly, you can once you have the complete Arduino software up and running, use an Arduino (with or without invoking soft serial -- in the old days it was done just by prying the ATmega itself out of the socket) to patch you though to the AVR you want to program. You could even use the Arduino IDE to write and upload the program.



And that's what I'm going to do. Only with an additional wrinkle. The power user can and should write their own software into the light. But for someone who just needs to specify the exact color it boots up into, or how long it takes to fade out when turned off, I am going to provide a space for user presets in non-volatile memory. So the end-user will use either FTDI cable (which are widely available in Arduino circles), or an Arduino with the appropriate software, to plug into the light node. They will try out different looks and then commit the look of their choice to one of the slots of user memory.

If and when I get that far, I can wrap this in a proper GUI. But before then, this behavior of going direct to looks or presets and setting the boot preset is also exactly what I want for inter-node communication.

Because the other thing I want to put on these lights that doesn't exist in any cheap, easy-to-use, prop-and-theater-friendly option is remote control.

The proof-of-concept for a accelerometer-based effect; this combined accelerometer, XBee module, and AAA battery pack to detect a throwing gesture and play a sound effect from a remote receiver. 

At the base of it is a protocol to let each node communicate bidirectionally. I'm doing it this way, instead of using existing buses like I2C, for transparency as I program. The BAUD rate I envision may be low, but I can still afford to send ASCII nouns rather than cryptic hexadecimal sequences.

I envision a complex prop that might have several lighting nodes each playing canned animations in free-running mode, and a single controller just telling them when to switch on and off. This is also how we will interact wirelessly; you won't control a candle flicker in real time, you will command it to light, then blow out.

A sticking point at the moment is the RF option itself. I'd like to provision each lighting node with the basic circuitry, omitting only the expensive transceiver. But between level shifting and LDO and of course a couple status lights, it may add too much to the individual cost and complexity.

This is worse when considering the transceiver options. Now, there are a lot of cheap, off-the-shelf 434 kHz, Bluetooth, etc. options. But all of them are inadequate for theater. They offer fifty feet of transmission in line-of-sight. Theater requires shooting two hundred and fifty feet through set walls and a fifty-member dance ensemble.

The leading options I have now are the Hope RF chips -- particularly the RFM69W and HW chips -- and the XBee series.

Trouble is, the Hope chips appear to require four digital pins to communicate with them properly, and the code to navigate their communications protocol eats up a full 8K of program memory. Which makes them pretty much impossible to run from an ATtiny, and pushes them up into "requires a late-model Arduino to operate" territory.

The XBees are simple and transparent and I've been using them in actual theater situations. Their major drawbacks are frequency and price. They are 2.5 GHz devices, and shorter wavelength radio has poor penetration of obstacles. The "Pro" models, which have the necessary power to punch from light booth to backstage, are upwards of forty bucks each.

So down the road, I hope to get the Hope chips working for me, but for now I'm going to have to hope that only a few of the more expensive transceivers are needed by the typical end-user.



And as for interfacing with the worlds of DMX-512 and MIDI; I'm holding off there. I see this as happening via software (aka a laptop with a DMX-512 dongle) even though it would be a lot more turn-key if it was a single stand-alone DMX-512 module. But getting one of those up to spec and robust, it would end up costing pretty close to the commercial models that are already available. So not really something I need to explore at the moment.



But, at last, I'm nailing down the specs on the basic light module. I should be able to get the first order out to the fab house for printed-circuit boards this week. Maybe even assemble one in time for my coming lighting design.

Here's the major parts. Power supply 3.7V to 5v; aka lithium poly, 5v wall wart, or 3x "penlight" batteries (AA or AAA). The latter is my preferred choice for theater due to the ease of swapping in freshly-charged cells (rechargeable or otherwise).

I have a bunch of 3W RGB's to start with, but I've found RGBW's available for about twice the price and those will provide a much nicer mix for typical theater applications (candles, lanterns, headlights...) Unfortunately RBGA or RGB+ "Warm" White (4,000 K) are harder to come by at budget prices.

The buck driver on the right there is there to illustrate mostly the SOT-89 surface-mount footprint of the AMC7135's, of which I'll be provisioning four of. A nice additional quality of these things; you can run them in parallel to drive higher wattage LEDs.

The controller chip looks at this point to be an ATtiny 20-pin, probably the attiny861A because of its 8K of program memory. I do love the 25/45/85, but there just aren't enough pins. Even the ATtiny84 is pushing it for sufficient pins -- and doesn't have the nice UART of the larger, more expensive chip. The various chips to the lower left are standing in for that footprint. I'm going through-hole and socket for ease in assembly and replacement.

I haven't decided on the header; whether to go with the 2x3 ICSP type or the 6-inline format shared by the FTDI cable and other similar devices. And I'm still pondering whether the XBee will be on the main board or have a daughterboard (for which the Adafruit board at the top right is standing in). The trade-off, as always, is between a compact footprint and lots of out-of-the-box functionality, versus price per item. Because I have to anticipate situations in which you'd want a dozen of these things scattered around as part of a more complicated lighting effect, and that would be a lot easier if I could keep them under $10 each.

Pan With a Real Handle

...which was a mildly clever pitch I heard some years ago from a pan-handler in The Haight, near the "pan handle" of Golden Gate Park.

Anyhow, I'm getting into a lighting design now. Nice little space, about twenty dimmers to play with (but some LED pars that should take up some of the slack).

And once again, I learn more about the goals for a circuit I'm designing when an actual application comes along. There's an old-style radio in the show and the dialog makes a point of that nice tube glow.

Seems like a good application for the Duck Light; dial up a good "glowing tube" red-amber, rig it to a button....wait. The current version is color-programmed off-line. There's no provision for real-time adjustment of the color.

Right. So I really do need to set up a software chain that, at the least, allows real-time dialing of a color selection and pushing that into permanent flash memory.

And in the nature of this play, I'd really want the effect to be both remotely controlled, and DMX controlled. I had envisioned running complex effects off a laptop, but for this show, it would be nice to have a modular, turn-key, DMX-512 solution instead.

So this is once again something the BlinkM already does, and one better; it has a primitive sequencer built in, and uploads fresh code via its own custom GUI-based IDE. It makes it nearly trivial for the end-user to select color and simple animations the will operate in free-running mode.

I'm still caught on how to offer programming flexibility without the overhead of FTDI or other USB toolchain -- since I'm not really up for adapting any of the open-source serial-over-USB code bases myself!

Dynamiting Fish

Was just helping someone at the RPF rig up a Cree LED to "pulse" for a prop they'd built. Used an Arduino, because we had one.

Which is like dynamiting fish in a bucket. It is a deceptively simple problem; detect a trigger button, turn on an LED then dim it out. If it were an incandescent bulb, a capacitor would do it all. But LEDs can't really be dimmed that way. You need to PWM them; that is, you switch them on and off too rapidly to see, and you change the ratio between the time it is on and the time it is off.

Which you could do with the old 555 -- possibly the most-used IC ever after the 741 opamp, and certainly one of the most elegant chips ever. Use an external capacitor to change the timing as it discharged. I used to do that trick when I had 555's as sound generators. Even hooked one up to a resistor ladder attached to a binary counter. Made a wonderfully complex sound.

But you'd have to hold the button in until the LED turned "off" completely. So use the 556; the dual timer in a 14 pin DIP. One is operating in one-shot mode and detects the button and then holds the circuit "on" until the next button press. The other is switching the LED on and off rapidly, while a capacitor discharges to change the pulse ratio.

In the old days, you'd set it up on breadboard with a bunch of potentiometers while you dialed in the behavior, then start pulling pots, measuring them with the multitester and replacing them with fixed resistors. Which wouldn't quite work the same, because of all sorts of capacitive leakage between the various elements and other parasitic effects, so you'd pull those and randomly test a bracket of values until it worked again.



The last complex circuit I did in the pre-micro days, I didn't even use a 555. I used a hex inverter chip (which isn't an anti-magic shield, but six digital inverters in one package). You could make a pretty decent oscillator out of two or three inverters and the right discretes. If I remember correctly, it was a "power up" thing for a friend. Had a big rocket switch, and when you switched it a bar graph would crawl up to the top while a whine from a small speaker rose in pitch. All of that driven by a single beefy capacitor.



And these days, it is all micros. Because especially with the ATtinys, you are paying about as much per chip as you would be for the old integrated circuits -- or a pair of transistors, if you want to be really old-school -- and you tweak the timing in software instead of by trying out different resistors from your parts box. And they aren't any bigger; you can run the things basically naked, with their internal oscillator instead of adding an external crystal. And of course the program is stored on the same chip in non-volatile flash.

It is still dynamiting fish, but at least it is a bigger bucket. The example above, we had to fade the LED and latch the trigger button. That's just enough to make it easier to use a micro. The picture to the right, I soldered that up quick for a fire effect, using code to generate a random flicker on the red and green channels of the Cree (which, combined, make a more-or-less amber color).



And this episode reminded me once again, I really should get that PCB made. Ignore the RF for now; that's been distracting me too long. Just three MOSFETs, an ATtiny, some arbitrary ballast resistors, and a terminal or two to connect button or sensors. I just picked up some Chinese RGB's for under five bucks each, and I should be able to make the PCB for about another $5 even at the prices of a limited run at a fab house. So I could offer the complete kit for $15; a digitally controlled 3W RGB that could be user programmed and used in props or cosplay.