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 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.
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 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.
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.
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.
No comments:
Post a Comment