I'm in the middle of a six-performance weekend and what little free hours I have are being consumed in repairing microphone elements and re-writing some sound cues.
(Actually, changing over from QLab to VSamp for some camera shutter and chop-socky effects I am improvising live during performance. I was doing them in QLab using the ability to hot-fire a sound from computer key or MIDI keyboard, but putting them in VSamp -- a low-profile, shareware software sampler for the Mac -- means I can play multiple "notes" as fast as my fingers can move on the keyboard.)
Anyhow.
My XBee Pro came in the mail, but so did a BlinkM. I have to take apart a prop that is featured in the current show in order to interrogate the XBee node inside it and then program and replace it with the higher-power Pro. So I'm holding off on that until after this weekend's performances!
Which gives me time to mess with the BlinkM.
First impressions; tiny form factor, no power conditioning needed (well, within the somewhat narrow range of voltages). Bright, but that's on the scale of small LEDs; I think it is just barely bright enough to do a candle effect on stage (stage lights are fierce competition). Fortunately, there is the MaxM (or you could break out the PWM lines and Power-MOSFET them into some of those 5-watt monsters they make now.)
In the raw form, you use an Arduino as a serial-to-I2C converter. I had a bit of an issue when my current version of the Arduino IDE wouldn't run the BlinkM communicator, and the latest version of the Arduino IDE wouldn't run on my computer, but regressing to version 0023 solved both problems.
The programmer/sequencer is cute and runs smoothly but is painful to use. Most of the kinds of things one would want to do would be smooth fading from color to color (or color to out). What you'd want is the ability to express those mathematically, or graphically in the form of spline curves. Instead you have a 30-step piano-roll that you fill in manually. Fun to play with, but hard to construct smooth fade curves on.
The worse problem, from my perspective, is that although turning two of the PWM outputs on an Arduino into a I2C interface is simple enough, and I2C protocol allows multiple units on the same line, and the built-in instruction set is large and well thought-out, most of the applications that spring to my mind would be better suited by 8-n-1.
Such as connecting to an XBee to allow streaming of new instructions via wireless link.
Well, with the extremely simple online instructions and my Adafruit "TinyISP" it took only a few minutes to upload a new program from the Arduino IDE. This wipes out the installed boot, but as far as I know it doesn't install an Arduino-type bootloader -- I'll probably have to use the ISP to continue programming. But aside from that mechanical detail, the experience becomes exactly like putting code on an Arduino.
Some reading of the schematic from ThinkM (and comparing it with the ATtiny45 datasheet from ATmel!) shows that -- given that the ATtiny45 only has two PWM pins -- this is controlling the three LEDs by strobing three digital pins. The way the BlinkM breakout is built, one unused digital I/O is brought out to the front of the board, as is a copy of the PWM/I/O pin used for the blue LED.
Anyhow...there are enough pins being brought out to implement soft serial, which is my next experiment. In the meanwhile, though, I'm writing up my own version of a code for the thing.
Or, rather, working on how to best use program cycles to handle the different and changing pulse-width requirements of three different LEDs simultaneously -- a task that really is better suited to the internal timers and PWM outputs. At the moment my experimental code is running through a 0-100 integer loop, and turning each LED off at the appropriate "slice" along that loop, from 1% duty cycle (a barely visible flicker) to 100%. However, my current code appears to be running so slowly the maximum smooth fade (aka incrementing one "slice" with every pass through the loop) consumes around half a second.
Which sounds like a deep error in my test code -- at 8 MHz, even running on compiled C code the RISC chip (which executes most operations in a single clock cycle) should be WAY faster than that (according to my calculations, in fact, over 1,000 times faster).
Grafting on the entire front end of the BlinkM is more than I want to handle. But, fortunately, I think I can make do with a limited capability to either go to select colors, or to go to various off-line programmed "useful" sequences (like candle-light). I may, though, now that I think of it, add to the instruction set something like "RandomColor( baseR, baseG, baseB, rangeR, rangeG, rangeB, rate )."
Once I get the basic PWM and fade code working right, that is!
Saturday, April 28, 2012
Wednesday, April 25, 2012
Not So Easy
Well, I wired my Easy Button with an XBee. After all that hassling over reading serial data in Processing, I realized it was more appropriate for this project to use the simpler I/O Line Passing Mode of the 802.15.4 "Series 1" XBee nodes.
The way I/O line passing works, the status of any enabled digital or analog inputs on the transmitter will be echoed by the corresponding digital pins or PWM pins on the receiver.
At that point it was an easy matter to stick the programmed XBee node inside the Easy Button, and wire it to the original button.
I experimented a bit with power supplies as well. The XBee nodes are designed to run on 3.3V although the I/O pins are 5V compatible (which is handy for interfacing with micros with a 5V bus). They are radios, and thus sensitive to voltage fluctuations, but according to the datasheet they can handle a range of 2.8V to 3.4V -- this meant I could use the nominal 3.0V of the pair of AAA batteries the Easy Button was already provisioned for.
(Alternatives ranged from sticking a hard-to-get to battery pack inside to installing a complete charge circuit for a lithium-poly battery. However, the LiPo's run as high as 4.1V when fully charged, meaning to protect the XBee you'd need to add a voltage regulator. The regulator provided on the commonly available XBee breakouts from Sparkfun and Adafruit drop about a volt, however, meaning the usable charge of the LiPo is severely limited. I have ordered a low-dropout regulator from Digikey, but I'm not sure I want to spend the time wiring up an LDO as well as LiPo charge manager!)
(Yet another alternative is to use a 3.3V boost power converter, that ramps up and regulates the output of a pair of AAA cells...all the way down to the output of one nearly-discharged cell (something like 0.8 volts) before it finally gives up. I have one of these on order as well!)
Oh, and I already had the other end:
My venerable Arduino-based MIDI event generator had just finished a show connected to the Easy Button -- at that time, the button was hard-wired via the terminal block you can see in the photograph. Since the terminal block presents both +V and ground, it was simple to power an XBee Explorer off it (which has an onboard 5V to 3.3V regulator), and when my pin D0 is pulled low on the transmitter (internal resistors pull the inputs high), it pulls one of the digital pins of the Arduino low via the XBee link.
And it all worked great on the bench, and I soldered up everything and closed up the button.
And then I did the plugs-out test and it failed.
Battery usage was fine...it went past twelve hours on a fresh-charged pair. But the transmission was very much line-of-sight; at ten feet, it couldn't even transmit through my own body if I held it behind my back.
This is as against the original proof-of-concept, when I got 120 feet of range through several set-pieces. The primary flaw appears to be the nature of the I/O Line Passing Mode itself. It appears to transmit only when the status of the digital input line changes (which makes for great battery life, at least). This means that not only is there no re-try, but the I/O pins can lose synchronization and have to be "reminded." Which is NOT good behavior for a theatrical effect.
However. I've gone back into the transmitter and set IR to FF -- that is, forcing the node to take a sample of its inputs (and transmit the results) every 255 milliseconds. And I'm reading up on sleep modes, which should accomplish the same thing with a better power economy. This has increased the robustness of the transmission enough to where I can transmit reliably at 20 feet and through one wall. I probably need to juggle settings on the receiver as well to make sure it resets the outputs within a quarter-second of any break in radio contact.
I don't know yet if the batteries can handle this greater transmit volume, but as of this moment I've been operating for one hour and 7 minutes on the same pair of batteries.
I believe the more robust option is going to have to be full serial transmission, for which I need to add an AVR (and which means I finally have to learn how to use the UART on an ATtiny). Other options are going to regulated power (and supplying the transmitter with the full designed 3.3 volts), using wire antenna instead of chip antenna XBee models, and upgrading to XBee Pro (which have much greater output power and spec at over twice the effective range).
In the meanwhile, I could try to use this current unit, by locating the receiver close to the stage. But the show has been rehearsed already with a visual sound cue instead of an actor-operated one, and there's no real point to changing now (and even less reason to introduce the risk of new technology).
The batteries made it past ten hours in the new mode. On further reading, and tentatively confirmed in testing, when IR is set at other than the default of "0" the node does wait for an ACK and re-try up to three times if it doesn't get one. And I lowered my sample interval to about 100 millseconds. And also set a 100 millisecond automatic reset interval on the receiver's pins using the Tn command so if it loses contact with the transmitter it won't "hang."
In the theater, it made it from the stage to the back of the house but only when there was a clear line of sight. Next step, then, is to swap out the existing node with a Pro node instead.
ADDENDUM TWO: with an XBee Pro node installed, I was able to achieve reliable trigger from stage to sound booth. In fact, it triggered semi-reliably from all the way back in the dressing room. My first test was actually from orchestra pit to lobby -- I had the parts spread out on the Concessions counter while I was putting in the Pro node, and I draped a wireless mic over my laptop computer then went down and listened to the computer through the band vocal monitor!
As I said in an earlier post (Theater Should Not be a Hackerspace) although it works and the actor admired it very much, it will not be used in this show. We are already rehearsed with taking the sound cue manually. But now the button is ready for any application down the road where I need to hand a button to an actor or band member or Stage Manager to trigger an event wireless-ly.
The way I/O line passing works, the status of any enabled digital or analog inputs on the transmitter will be echoed by the corresponding digital pins or PWM pins on the receiver.
(Alternatives ranged from sticking a hard-to-get to battery pack inside to installing a complete charge circuit for a lithium-poly battery. However, the LiPo's run as high as 4.1V when fully charged, meaning to protect the XBee you'd need to add a voltage regulator. The regulator provided on the commonly available XBee breakouts from Sparkfun and Adafruit drop about a volt, however, meaning the usable charge of the LiPo is severely limited. I have ordered a low-dropout regulator from Digikey, but I'm not sure I want to spend the time wiring up an LDO as well as LiPo charge manager!)
(Yet another alternative is to use a 3.3V boost power converter, that ramps up and regulates the output of a pair of AAA cells...all the way down to the output of one nearly-discharged cell (something like 0.8 volts) before it finally gives up. I have one of these on order as well!)
Oh, and I already had the other end:
And it all worked great on the bench, and I soldered up everything and closed up the button.
And then I did the plugs-out test and it failed.
Battery usage was fine...it went past twelve hours on a fresh-charged pair. But the transmission was very much line-of-sight; at ten feet, it couldn't even transmit through my own body if I held it behind my back.
This is as against the original proof-of-concept, when I got 120 feet of range through several set-pieces. The primary flaw appears to be the nature of the I/O Line Passing Mode itself. It appears to transmit only when the status of the digital input line changes (which makes for great battery life, at least). This means that not only is there no re-try, but the I/O pins can lose synchronization and have to be "reminded." Which is NOT good behavior for a theatrical effect.
However. I've gone back into the transmitter and set IR to FF -- that is, forcing the node to take a sample of its inputs (and transmit the results) every 255 milliseconds. And I'm reading up on sleep modes, which should accomplish the same thing with a better power economy. This has increased the robustness of the transmission enough to where I can transmit reliably at 20 feet and through one wall. I probably need to juggle settings on the receiver as well to make sure it resets the outputs within a quarter-second of any break in radio contact.
I don't know yet if the batteries can handle this greater transmit volume, but as of this moment I've been operating for one hour and 7 minutes on the same pair of batteries.
I believe the more robust option is going to have to be full serial transmission, for which I need to add an AVR (and which means I finally have to learn how to use the UART on an ATtiny). Other options are going to regulated power (and supplying the transmitter with the full designed 3.3 volts), using wire antenna instead of chip antenna XBee models, and upgrading to XBee Pro (which have much greater output power and spec at over twice the effective range).
In the meanwhile, I could try to use this current unit, by locating the receiver close to the stage. But the show has been rehearsed already with a visual sound cue instead of an actor-operated one, and there's no real point to changing now (and even less reason to introduce the risk of new technology).
The batteries made it past ten hours in the new mode. On further reading, and tentatively confirmed in testing, when IR is set at other than the default of "0" the node does wait for an ACK and re-try up to three times if it doesn't get one. And I lowered my sample interval to about 100 millseconds. And also set a 100 millisecond automatic reset interval on the receiver's pins using the Tn command so if it loses contact with the transmitter it won't "hang."
In the theater, it made it from the stage to the back of the house but only when there was a clear line of sight. Next step, then, is to swap out the existing node with a Pro node instead.
ADDENDUM TWO: with an XBee Pro node installed, I was able to achieve reliable trigger from stage to sound booth. In fact, it triggered semi-reliably from all the way back in the dressing room. My first test was actually from orchestra pit to lobby -- I had the parts spread out on the Concessions counter while I was putting in the Pro node, and I draped a wireless mic over my laptop computer then went down and listened to the computer through the band vocal monitor!
As I said in an earlier post (Theater Should Not be a Hackerspace) although it works and the actor admired it very much, it will not be used in this show. We are already rehearsed with taking the sound cue manually. But now the button is ready for any application down the road where I need to hand a button to an actor or band member or Stage Manager to trigger an event wireless-ly.
Subscribe to:
Posts (Atom)