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.
Friday, March 30, 2012
Buzz, Buzz
Still tinkering with the XBees. Progress is slow and I'm feeling more stupid than usual. I do have the excuse of an ongoing show in one town and a load-in in another town.
Yesterday was typical, though. Wasn't able to get the XBee to respond to my desktop, thought I had another Java issue, in the process of re-installing Java realized I really needed to do a round of file back-ups and general cleaning on three different machines...and after several hours of that, more driver installs, and change back to the previous version of Processing...realized it was a bad USB cable all along.
I've been trying to interpret the signals from the XBee, which are sent as strings of different lengths. I'm trying to parse them using Processing's string functions and it is NOT going well. Whether it is due to Processing considering string handling beneath it (the manual gives short shrift to the subject), the difficult-to-decipher documentation on the XBee, or that my own brain is not quite running right this week...
The easiest way to use XBees is as a transparent serial link. With two XBees in the factory defaults, and serial-to-USB connections to them (via say the XBee Explorer USB, which uses the perennial FTDI chip to produce a virtual COM port on the USB hub -- don't forget to install the FTDI drivers!) you can type into a terminal application on one computer and the text will appear on the other.
After struggling with the broken Java implementation of MIDI on OSX 10.4 through 10.5, I was able to get a proof-of-concept working via a nice little piece of freeware called the Hairless MIDI to Serial Bridge. For whatever weird reason, Processing uses -128 to 128 as the range of values for the Byte data format, so to get something like 144 (the decimal value of the "NoteOn" command) I had to do some odd tinkering.
But it all worked well enough. I ran a Processing sketch on my laptop that would spit out a serial string on command, and Hairless was on the slave computer, hooked up as a virtual MIDI input to QLab. And the actual serial connection between the two machines was via XBee modules plugged into the USB ports. Using just Series 1 modules with chip antennas I was able to fire off a sound cue even with the sound computer at the back of the house (in the lighting booth) and my laptop all the way upstage behind the scenery.
And this will...work. It means intelligence on the sending end. My preference was that the transmitter would be "dumb," merely reporting on the status of the sensors or other inputs connected to it, and that the massaging of the data and creation of a MIDI or DMX signal would happen on software running on the receiving computer. But to get this working either requires I learn how to program on CoreAudio itself (bypassing Java entirely) or wait until I am working on machines running 10.6 and above.
I can hack it now, though, by having an AVR do the listening to the sensors and conditioning of them, and constructing a viable serial string. The advantage to having intelligence at the sensor end is you can add battery status and other diagnostic and self-reporting functions. The downside is that trimming the sensor or otherwise changing the response means re-programming a micro. Or adding more hardware to the transmitter so you can interact with it directly (aka display, buttons, etc.)
The next show has a potential "Jeopardy" type button. Basically, that means sticking an XBee into the "Easy" button we are using right now to run QLab. I think a wireless "Easy" button is far too useful not to have around. I do want to build it with some sort of self-diagnostics, though, and of course I need the ability to change out the battery easily.
Probably the nicest solution is a custom fabbed board with an AVR, LED drivers, and perhaps a MAX power monitor chip on it. At the moment, I'd just waste an Arduino in order to get it up and functioning -- if there was room for an Arduino and shield inside the button. I'm not quite comfortable with serial I/O on a "naked" AVR yet.
Or move the intelligence. The XBee modules have several I/O ports that can be configured as digital inputs, ADCs, digital outs, or even PWMs. That was the big progress for this week; I finally got an XBee set up to where it would stand in idle mode without doing anything, but transmit a short burst whenever the status of a "sensor" (aka a button) on one pin changed.
The XBees are very much designed for remote monitoring applications and thus also have a variety of sleep modes, including sleep-until-pin and wake-every-n-seconds. In my current arrangement, I'm not sleeping the module at all; it is remaining in active state. It just isn't transmitting unless it has something to say.
I've already been working up a control surface for use with QLab -- several large buttons (maybe even arcade buttons) on a box that is powered from the USB connector and shows up (via the ATmel family of USB-compliant chips) as a MIDI device.
It is much easier to hook up the AT-USB chips as HID -- to make them emulate mice and keyboards. But there are a growing number of MIDI libraries for them now and I'm pretty sure I can get that working in a couple more weeks.
So in this format, the XBee is a dumb terminal; it sits around, reporting what it sees on its inputs. The micro sitting inside the control surface up in the sound booth interprets the sensor readings, adds them to the button inputs, and spits out MIDI-over-USB which is interpreted by QLab.
And, yes, using Max/MSP as a go-between, and upgrading to OSC (or just sending serial to Max and letting it deal with it) is a smarter solution. I'm just used to MIDI, I don't need to pay for it, and it will work with any host -- like the typical "someone supplied a laptop to run sound effects but they need it back after the show." Same for the XBee, really -- you can get cheaper radio links, but the cost on the XBees is as low as 17 bucks each and they handle all the error correction and multiple transmit tries and so forth for you.
Of course it doesn't stop there. The XBee has those outputs, after all. You can quite easily have them controlling relays or servos. But there is another trick that, again, leverages the insane intelligence available these days in very small packages.
For instance, by hooking it to a BlinkM. According to my reading, A BlinkM can be run off an unregulated 6v supply. The typical breakout for the XBee includes a 3.3V regulator. The UARTs on both devices are tolerant enough to operate across a range of voltages.
The end result would be a high-power RGB LED running a pre-programmed sequence that can change behavior (change sequences) by remote command.
I don't know how many shows I've had a candle or lantern on stage. The difficulties are both getting them bright enough to read against stage lighting, and being able to turn them on and off. On a production of "Lulu" some time back the solution was to glue a servo and radio (from an RC model car) to the shaft of a potentiometer inside the lamp. Thus, by using the RC controller you could dial the light up or down.
In this case, once you are in digital domain like this, the control impetus can come from anywhere...from the lighting board, for instance. So a lantern hanging in the barn will go up automatically with the lights, go out at the blackout, and flicker in a pleasing manner during the scene.
Or turn red and blue or flash like a police car, if you wanted it to. It's all right there in the remote controls.
In the upcoming show, I also have some electric collars. Mention was made during the production meeting of the light-up collars in the old Star Trek episode "The Gamesters of Triskellion." It is totally do-able with this sort of hardware. With lithium coin cells you could even make it self-contained (but an external battery pack would be nicer). Under direct control from the booth the collars could be radio controlled to light up and change color.
Waaaay too useful a tool not to try to put together.
Argh. The BlinkM is designed to take I2C. You can bitbang with an XBee to talk to a I2C device, but it is a complicated, slow, and power-hungry process. You could use the two PWM outputs of the XBee for a light controller (via some Darlington drivers) but this has several disadvantages; it wouldn't be a full RGB, you have to transmit constantly, and the only way to access these pins anyhow is via "echo mode" -- where one XBee is fed an analog value on several pins and the other mimics it out the corresponding pins.
You could include any of the family of AVR or Arduino clones to act as a translator from XBee to BlinkM, but that is adding to the cost, complexity, and size of the device, and is a bit silly besides; the BlinkM already HAS an AVR.
As it turns out, you can hack the BlinkM. You can even burn an Arduino-style bootloader and run it via the Arduino IDE, if you happen to have an ISP handy (which I do). At which point, you could write your own open version of the BlinkM software. Opening up the BlinkM also opens up the available I/O pins -- unfortunately it does not include the UART but you can use one of the soft serial libraries.
So, in short, it is still a plausible idea; to connect XBee to BlinkM, add a battery, and make an over-the-air programmable RGB light. It just requires a lot more work on the software side.
###
As I describe in a later post, once you've added the BlinkM to the list of compatible boards in the Arduino IDE, you can write modified Arduino code to it. And since one analog in port is uncovered (aka broken out to a pin), a trim pot or resistor ladder can be used as a multi-position switch. Presumably you could also use the PWM output of an XBee for this. My proof of concept, though, involved a digital output from the XBee and two resistors to toggle the BlinkM between two programmed states.
Of course, you could do soft serial. Or even write your own asynchronous unidirectional protocol; three "clicks" from the XBee means go to the blinking red program, four clicks means turn the LED off, etc. (Or, even more clever...an asynchronous PWM comparator; count the time from leading edge to falling edge and compare to the time from falling edge to leading edge. Then use the comparison as an analog value.)
Yesterday was typical, though. Wasn't able to get the XBee to respond to my desktop, thought I had another Java issue, in the process of re-installing Java realized I really needed to do a round of file back-ups and general cleaning on three different machines...and after several hours of that, more driver installs, and change back to the previous version of Processing...realized it was a bad USB cable all along.
I've been trying to interpret the signals from the XBee, which are sent as strings of different lengths. I'm trying to parse them using Processing's string functions and it is NOT going well. Whether it is due to Processing considering string handling beneath it (the manual gives short shrift to the subject), the difficult-to-decipher documentation on the XBee, or that my own brain is not quite running right this week...
The easiest way to use XBees is as a transparent serial link. With two XBees in the factory defaults, and serial-to-USB connections to them (via say the XBee Explorer USB, which uses the perennial FTDI chip to produce a virtual COM port on the USB hub -- don't forget to install the FTDI drivers!) you can type into a terminal application on one computer and the text will appear on the other.
After struggling with the broken Java implementation of MIDI on OSX 10.4 through 10.5, I was able to get a proof-of-concept working via a nice little piece of freeware called the Hairless MIDI to Serial Bridge. For whatever weird reason, Processing uses -128 to 128 as the range of values for the Byte data format, so to get something like 144 (the decimal value of the "NoteOn" command) I had to do some odd tinkering.
But it all worked well enough. I ran a Processing sketch on my laptop that would spit out a serial string on command, and Hairless was on the slave computer, hooked up as a virtual MIDI input to QLab. And the actual serial connection between the two machines was via XBee modules plugged into the USB ports. Using just Series 1 modules with chip antennas I was able to fire off a sound cue even with the sound computer at the back of the house (in the lighting booth) and my laptop all the way upstage behind the scenery.
And this will...work. It means intelligence on the sending end. My preference was that the transmitter would be "dumb," merely reporting on the status of the sensors or other inputs connected to it, and that the massaging of the data and creation of a MIDI or DMX signal would happen on software running on the receiving computer. But to get this working either requires I learn how to program on CoreAudio itself (bypassing Java entirely) or wait until I am working on machines running 10.6 and above.
I can hack it now, though, by having an AVR do the listening to the sensors and conditioning of them, and constructing a viable serial string. The advantage to having intelligence at the sensor end is you can add battery status and other diagnostic and self-reporting functions. The downside is that trimming the sensor or otherwise changing the response means re-programming a micro. Or adding more hardware to the transmitter so you can interact with it directly (aka display, buttons, etc.)
The next show has a potential "Jeopardy" type button. Basically, that means sticking an XBee into the "Easy" button we are using right now to run QLab. I think a wireless "Easy" button is far too useful not to have around. I do want to build it with some sort of self-diagnostics, though, and of course I need the ability to change out the battery easily.
Probably the nicest solution is a custom fabbed board with an AVR, LED drivers, and perhaps a MAX power monitor chip on it. At the moment, I'd just waste an Arduino in order to get it up and functioning -- if there was room for an Arduino and shield inside the button. I'm not quite comfortable with serial I/O on a "naked" AVR yet.
Or move the intelligence. The XBee modules have several I/O ports that can be configured as digital inputs, ADCs, digital outs, or even PWMs. That was the big progress for this week; I finally got an XBee set up to where it would stand in idle mode without doing anything, but transmit a short burst whenever the status of a "sensor" (aka a button) on one pin changed.
The XBees are very much designed for remote monitoring applications and thus also have a variety of sleep modes, including sleep-until-pin and wake-every-n-seconds. In my current arrangement, I'm not sleeping the module at all; it is remaining in active state. It just isn't transmitting unless it has something to say.
I've already been working up a control surface for use with QLab -- several large buttons (maybe even arcade buttons) on a box that is powered from the USB connector and shows up (via the ATmel family of USB-compliant chips) as a MIDI device.
It is much easier to hook up the AT-USB chips as HID -- to make them emulate mice and keyboards. But there are a growing number of MIDI libraries for them now and I'm pretty sure I can get that working in a couple more weeks.
So in this format, the XBee is a dumb terminal; it sits around, reporting what it sees on its inputs. The micro sitting inside the control surface up in the sound booth interprets the sensor readings, adds them to the button inputs, and spits out MIDI-over-USB which is interpreted by QLab.
And, yes, using Max/MSP as a go-between, and upgrading to OSC (or just sending serial to Max and letting it deal with it) is a smarter solution. I'm just used to MIDI, I don't need to pay for it, and it will work with any host -- like the typical "someone supplied a laptop to run sound effects but they need it back after the show." Same for the XBee, really -- you can get cheaper radio links, but the cost on the XBees is as low as 17 bucks each and they handle all the error correction and multiple transmit tries and so forth for you.
Of course it doesn't stop there. The XBee has those outputs, after all. You can quite easily have them controlling relays or servos. But there is another trick that, again, leverages the insane intelligence available these days in very small packages.
For instance, by hooking it to a BlinkM. According to my reading, A BlinkM can be run off an unregulated 6v supply. The typical breakout for the XBee includes a 3.3V regulator. The UARTs on both devices are tolerant enough to operate across a range of voltages.
The end result would be a high-power RGB LED running a pre-programmed sequence that can change behavior (change sequences) by remote command.
I don't know how many shows I've had a candle or lantern on stage. The difficulties are both getting them bright enough to read against stage lighting, and being able to turn them on and off. On a production of "Lulu" some time back the solution was to glue a servo and radio (from an RC model car) to the shaft of a potentiometer inside the lamp. Thus, by using the RC controller you could dial the light up or down.
In this case, once you are in digital domain like this, the control impetus can come from anywhere...from the lighting board, for instance. So a lantern hanging in the barn will go up automatically with the lights, go out at the blackout, and flicker in a pleasing manner during the scene.
Or turn red and blue or flash like a police car, if you wanted it to. It's all right there in the remote controls.
In the upcoming show, I also have some electric collars. Mention was made during the production meeting of the light-up collars in the old Star Trek episode "The Gamesters of Triskellion." It is totally do-able with this sort of hardware. With lithium coin cells you could even make it self-contained (but an external battery pack would be nicer). Under direct control from the booth the collars could be radio controlled to light up and change color.
Waaaay too useful a tool not to try to put together.
Argh. The BlinkM is designed to take I2C. You can bitbang with an XBee to talk to a I2C device, but it is a complicated, slow, and power-hungry process. You could use the two PWM outputs of the XBee for a light controller (via some Darlington drivers) but this has several disadvantages; it wouldn't be a full RGB, you have to transmit constantly, and the only way to access these pins anyhow is via "echo mode" -- where one XBee is fed an analog value on several pins and the other mimics it out the corresponding pins.
You could include any of the family of AVR or Arduino clones to act as a translator from XBee to BlinkM, but that is adding to the cost, complexity, and size of the device, and is a bit silly besides; the BlinkM already HAS an AVR.
As it turns out, you can hack the BlinkM. You can even burn an Arduino-style bootloader and run it via the Arduino IDE, if you happen to have an ISP handy (which I do). At which point, you could write your own open version of the BlinkM software. Opening up the BlinkM also opens up the available I/O pins -- unfortunately it does not include the UART but you can use one of the soft serial libraries.
So, in short, it is still a plausible idea; to connect XBee to BlinkM, add a battery, and make an over-the-air programmable RGB light. It just requires a lot more work on the software side.
###
As I describe in a later post, once you've added the BlinkM to the list of compatible boards in the Arduino IDE, you can write modified Arduino code to it. And since one analog in port is uncovered (aka broken out to a pin), a trim pot or resistor ladder can be used as a multi-position switch. Presumably you could also use the PWM output of an XBee for this. My proof of concept, though, involved a digital output from the XBee and two resistors to toggle the BlinkM between two programmed states.
Of course, you could do soft serial. Or even write your own asynchronous unidirectional protocol; three "clicks" from the XBee means go to the blinking red program, four clicks means turn the LED off, etc. (Or, even more clever...an asynchronous PWM comparator; count the time from leading edge to falling edge and compare to the time from falling edge to leading edge. Then use the comparison as an analog value.)
Tuesday, March 27, 2012
Static
It never fails -- if someone complains about noise in any part of the sound system, they will describe it for you as "static."
Sometimes you can get them to imitate the noise. Tom and Ray, the Car Talk brothers, demonstrate this every weekend on their radio show. But most times, what you have to do is put your own ears in the space and hear it for yourself.
The most frequent sustained noise you get when mic'ing a pit or in monitor speakers is hum -- 60 cycle for us in the States. Once you've heard it, you always recognize it. Sometimes it can be tracked to, and corrected with, proper grounding. Sometimes people try to correct it by defeating the safety grounds -- a practice I do not recommend.
(Also, because defeating the safety ground often stops the ground loop of the moment but leaves the device unprotected for the next surge of electrical noise in the system as the lighting design reaches a point where the dimmers are making maximum noise in the building wiring).
The other instantly recognizable sound involving microphones and speakers is feedback -- which the British refer to by the wonderfully descriptive phrase "Howl-around." When you have been running mics near feedback for a while, you will also recognize the distinctive "ring" of near-feedback conditions. Basically, feedback is a loop between speaker and mic that is higher than unity. The ringing is when the loop is under unity; the tone of the feedback of the moment starts, but can not sustain.
Then we get down to crackling and popping. Soft crackles are usually dirty connections (why I always travel with a can of Caig De-oxit) or dirty pots. Extremely loud and sharp pops come when there is a bad connection or a broken cable to a microphone with phantom power on it. And a single loud "pop," not repeated, is due to the bass player yanking the cord out of the DI three seconds after his last note so he can get packed and off to his next gig.
As a general note, electrical connection problems have a crackling sound with a lot of high-frequency content -- this is how you recognize them as being something other than rattling drum hardware or a failing microphone.
Hiss comes from a great many sources. There is always nearly-pure white noise in electronics; the basic thermal noise of the components. If any stage is gained too high, you may pull that noise floor up to where it gets objectionable. The only real recourse is to gain-stage carefully -- putting stronger signals down the lines from the earlier stages so the later stages don't have to amplify the noise floor along with the wanted signal.
Especially when you try recording in an ordinary stage space, you notice another hiss; the noise floor of the building itself (ventilation, air movement, traffic noise from outside, etc.) This is more of a low-mid ranged whooshing sound, plus of course any louder specific elements (like a noisy fan in the HVAC). One place where this may become objectionable and get mentioned to you as "I heard this hiss during Laura's lines" is when you are compressing or gating the microphone in question. Aggressive settings of either will mean the noise floor can be heard coming and going (referred to as "breathing" or "pumping.") A steady, constant noise is less noticeable than one that changes quickly.
With powered monitors, especially, there is another extremely familiar noise you will hear; GSM noise. Which always means that someone put their purse -- with their cell phone in it -- down on top of a monitor or on the floor right by some insufficiently shielded electronics. I suspect an entirely new range of ugly noises of this type as the even more powerful radios of the latest round of smart phones become more ubiquitous.
Wireless of course has a whole slew of new and wonderful noises.
There is a constant reedy whine of specific frequency, often sounding much like the back of an old television set. This is a fault in the transmitter itself and means it needs to be returned to the company that made it. It seems to happen as certain brands age.
There is an extremely loud broad-band white noise. This is usually due to interference, specifically, one of the new DTV stations. There is no space here to go into the Digital Dividend, the restructuring of the airwaves, and so forth, except to note that even when you are in the white space (as you should be!) under the right conditions your receivers may still reach for a strong but distant television signal instead of the nearer (but extremely weak) belt pack you wanted.
Related to this is when there is a momentary interruption of the wireless signal -- due to path cancellation usually. Since the wavelength is in centimeters, the physical location in the building where the multiple transmission paths meet out of phase and cancel is a mere centimeter or two in size. So with an ordinary actor, doing ordinary acting, all you will hear is this distinctive "Fwiip!" of white noise as the receiver loses lock for a moment then resumes. You can usually "fix" this by turning the squelch higher -- at the cost of having the signal cut out completely for these brief moments.
When the drop-out is complete; aka, the receiver properly squelched, but it is a significant time before the signal is regained, you can often hear this as a dull popping sound. This is something -- like many RF issues -- you need eyes as well as ears to diagnose.
Sometimes a constant source of interference can hetrodyne with the transmitter in such a way that what you get is a low-level modulation; it is a sort of siren whistle, usually low in level, that goes on almost constantly; "weewooweewooweewooweewoo...."
On the wireless elements themselves, the most frequent failure you will hear is a broken connector. This is the element that gets the most stress, and the place where it fails most often. The connection itself can come adrift; the Sennheiser connectors have a nasty habit of unscrewing, the Shure connectors over time will lose the spring in the detent button until it no longer locks the connector. For both, electrician's tape is often the stop-gap to keep the connector secure.
The wiring also rips, either just inside the connector or just above the strain relief. It can also be cut higher up, especially when someone has been careless with bobby pins or toupee clips. But the tear is usually within a few CM of the connector. These will show up as a loud crackle, and can usually be confirmed by manipulating the cable.
Sometimes you have a intermittent and usually softer crackle due to corrosion of the contacts in the connector. This is, again, why Caig De-Oxit is in my gig bag. I tend to spray the connectors every time I put a fresh element on.
When the sound is hollow or sounds like it is flanging, the first place to look is if the element has slipped, or if the actor has managed to put the tape on top of it. This is the same sound you will hear from the actress who thinks that holding her mic to her face with one hand is sufficient for mic check (she will attach it later after she has finished with her make-up.) It is also (although in a different frequency range) the lovely sound you will get used to on any period show where half the cast are wearing hats.
Sweat makes a whole variety of sounds. Sweat is sufficiently conductive so it can short out a mic if it gets far enough. You will hear this as loud but dull-sounding pops most of the time, followed by complete mic failure, and then followed by a mysterious resurrection.
It can also block the screen or sit on top of the diaphragm and make a clouded, distant sound. I had a crop of Senny ME2's that got sweated out, and they produced this very interesting illusion that the actor was ten feet away and was singing as if his heart wasn't really in it. Countrymen will get quiet, shut off for a while, restore themselves...but still sounding clouded and muffled.
My two major activities against sweat these days is to wrap moleskin around the cord just behind the element (it traps much of the sweat that would otherwise drip down the cord) and to rinse out the mics in isopropyl alcohol several times a run (and let them dry THOROUGHLY before powering them up again).
Over their lifetime, Countryman B3's get dull-sounding, subtly but increasingly muffled until you have to retire them. The cleaning in alcohol will often help. Shure WL93s, which I was graced with the opportunity of working with at far too many venues, fail more suddenly and more thoroughly; the diaphragm becomes detached. Suddenly the output drops dramatically and seems to come and go. Sometimes, the detached piece is exactly right, though, leading to this rather lovely sound of tiny chimes that sound along with the voice.
Sometimes you can get them to imitate the noise. Tom and Ray, the Car Talk brothers, demonstrate this every weekend on their radio show. But most times, what you have to do is put your own ears in the space and hear it for yourself.
The most frequent sustained noise you get when mic'ing a pit or in monitor speakers is hum -- 60 cycle for us in the States. Once you've heard it, you always recognize it. Sometimes it can be tracked to, and corrected with, proper grounding. Sometimes people try to correct it by defeating the safety grounds -- a practice I do not recommend.
(Also, because defeating the safety ground often stops the ground loop of the moment but leaves the device unprotected for the next surge of electrical noise in the system as the lighting design reaches a point where the dimmers are making maximum noise in the building wiring).
The other instantly recognizable sound involving microphones and speakers is feedback -- which the British refer to by the wonderfully descriptive phrase "Howl-around." When you have been running mics near feedback for a while, you will also recognize the distinctive "ring" of near-feedback conditions. Basically, feedback is a loop between speaker and mic that is higher than unity. The ringing is when the loop is under unity; the tone of the feedback of the moment starts, but can not sustain.
Then we get down to crackling and popping. Soft crackles are usually dirty connections (why I always travel with a can of Caig De-oxit) or dirty pots. Extremely loud and sharp pops come when there is a bad connection or a broken cable to a microphone with phantom power on it. And a single loud "pop," not repeated, is due to the bass player yanking the cord out of the DI three seconds after his last note so he can get packed and off to his next gig.
As a general note, electrical connection problems have a crackling sound with a lot of high-frequency content -- this is how you recognize them as being something other than rattling drum hardware or a failing microphone.
Hiss comes from a great many sources. There is always nearly-pure white noise in electronics; the basic thermal noise of the components. If any stage is gained too high, you may pull that noise floor up to where it gets objectionable. The only real recourse is to gain-stage carefully -- putting stronger signals down the lines from the earlier stages so the later stages don't have to amplify the noise floor along with the wanted signal.
Especially when you try recording in an ordinary stage space, you notice another hiss; the noise floor of the building itself (ventilation, air movement, traffic noise from outside, etc.) This is more of a low-mid ranged whooshing sound, plus of course any louder specific elements (like a noisy fan in the HVAC). One place where this may become objectionable and get mentioned to you as "I heard this hiss during Laura's lines" is when you are compressing or gating the microphone in question. Aggressive settings of either will mean the noise floor can be heard coming and going (referred to as "breathing" or "pumping.") A steady, constant noise is less noticeable than one that changes quickly.
With powered monitors, especially, there is another extremely familiar noise you will hear; GSM noise. Which always means that someone put their purse -- with their cell phone in it -- down on top of a monitor or on the floor right by some insufficiently shielded electronics. I suspect an entirely new range of ugly noises of this type as the even more powerful radios of the latest round of smart phones become more ubiquitous.
Wireless of course has a whole slew of new and wonderful noises.
There is a constant reedy whine of specific frequency, often sounding much like the back of an old television set. This is a fault in the transmitter itself and means it needs to be returned to the company that made it. It seems to happen as certain brands age.
There is an extremely loud broad-band white noise. This is usually due to interference, specifically, one of the new DTV stations. There is no space here to go into the Digital Dividend, the restructuring of the airwaves, and so forth, except to note that even when you are in the white space (as you should be!) under the right conditions your receivers may still reach for a strong but distant television signal instead of the nearer (but extremely weak) belt pack you wanted.
Related to this is when there is a momentary interruption of the wireless signal -- due to path cancellation usually. Since the wavelength is in centimeters, the physical location in the building where the multiple transmission paths meet out of phase and cancel is a mere centimeter or two in size. So with an ordinary actor, doing ordinary acting, all you will hear is this distinctive "Fwiip!" of white noise as the receiver loses lock for a moment then resumes. You can usually "fix" this by turning the squelch higher -- at the cost of having the signal cut out completely for these brief moments.
When the drop-out is complete; aka, the receiver properly squelched, but it is a significant time before the signal is regained, you can often hear this as a dull popping sound. This is something -- like many RF issues -- you need eyes as well as ears to diagnose.
Sometimes a constant source of interference can hetrodyne with the transmitter in such a way that what you get is a low-level modulation; it is a sort of siren whistle, usually low in level, that goes on almost constantly; "weewooweewooweewooweewoo...."
On the wireless elements themselves, the most frequent failure you will hear is a broken connector. This is the element that gets the most stress, and the place where it fails most often. The connection itself can come adrift; the Sennheiser connectors have a nasty habit of unscrewing, the Shure connectors over time will lose the spring in the detent button until it no longer locks the connector. For both, electrician's tape is often the stop-gap to keep the connector secure.
The wiring also rips, either just inside the connector or just above the strain relief. It can also be cut higher up, especially when someone has been careless with bobby pins or toupee clips. But the tear is usually within a few CM of the connector. These will show up as a loud crackle, and can usually be confirmed by manipulating the cable.
Sometimes you have a intermittent and usually softer crackle due to corrosion of the contacts in the connector. This is, again, why Caig De-Oxit is in my gig bag. I tend to spray the connectors every time I put a fresh element on.
When the sound is hollow or sounds like it is flanging, the first place to look is if the element has slipped, or if the actor has managed to put the tape on top of it. This is the same sound you will hear from the actress who thinks that holding her mic to her face with one hand is sufficient for mic check (she will attach it later after she has finished with her make-up.) It is also (although in a different frequency range) the lovely sound you will get used to on any period show where half the cast are wearing hats.
Sweat makes a whole variety of sounds. Sweat is sufficiently conductive so it can short out a mic if it gets far enough. You will hear this as loud but dull-sounding pops most of the time, followed by complete mic failure, and then followed by a mysterious resurrection.
It can also block the screen or sit on top of the diaphragm and make a clouded, distant sound. I had a crop of Senny ME2's that got sweated out, and they produced this very interesting illusion that the actor was ten feet away and was singing as if his heart wasn't really in it. Countrymen will get quiet, shut off for a while, restore themselves...but still sounding clouded and muffled.
My two major activities against sweat these days is to wrap moleskin around the cord just behind the element (it traps much of the sweat that would otherwise drip down the cord) and to rinse out the mics in isopropyl alcohol several times a run (and let them dry THOROUGHLY before powering them up again).
Over their lifetime, Countryman B3's get dull-sounding, subtly but increasingly muffled until you have to retire them. The cleaning in alcohol will often help. Shure WL93s, which I was graced with the opportunity of working with at far too many venues, fail more suddenly and more thoroughly; the diaphragm becomes detached. Suddenly the output drops dramatically and seems to come and go. Sometimes, the detached piece is exactly right, though, leading to this rather lovely sound of tiny chimes that sound along with the voice.
Thursday, March 22, 2012
Somewhere West of Java
So the Processing language and IDE is an artist-friendly wrapper for Java. You know Java? That C-like language that is hardware agnostic, meaning the same program will run on multiple environments?
Except not always. The handling of MIDI events was broken in the Mac implementation of Java. You know the Mac, right? The artist's machine? Only Apple in all their wisdom decided to cripple MIDI when they transitioned to OSX. With a lot of third party aps and hard work you could re-create the lost functionality of Opcode's OMS, and get back a system that actually listed the patch names of your outboard equipment again.
But then Apple goes and loses the MIDI functionality of Java around OS 10.4 or so. It doesn't come back until a later Java release -- that won't run on anything less than OS 10.6 -- but not all the way; there are still a few broken functions. There is a third party library, mmj, which in some implementations on OS 10.4 (and perhaps even OS 10.5) will work.
Of course even then you are left with the need to build a library for PROCESSING, to "Processing-ize" the MIDI functionality in the raw Java. Oh, to be an actual programmer instead of an artist-type, so I could just write it myself. Or, better yet, go straight to CoreAudio and handle it there, without involving Java.
The nice thing about a Java ap is that as long as the Java virtual machine is properly installed on the user's computer, you can stick a custom icon on the Java ap and it will look just like an ordinary double-clickable application.
And Processing makes the whole thing even one step easier, when you are working with a "sketch" in the friendly IDE, which turns your twenty lines of kindergarten code into something that will actually run...and then you can play with the finished Java ap and make it into a practically stand-alone application.
With libraries like proMidi and controlP5, all the heavy lifting is done for you, and even an idiot like me can make a functional serial-to-MIDI translator.
Or, I could, if I had an Intel Mac. Unfortunately I'm still stuck in the PPC world. I have five PPC laptops that see almost constant use, being used by me or loaned or sometimes even rented to work as sound effects playback, multi-track recorders, video playback and virtual instruments. One of them just came back from being a harp in a pit orchestra (played from a Yamaha Clavinova), one is currently playing back sound effects in a booth, and my main machine is being a drum sub-mixer (an improvised solution I really hope not to have to resort to again!)
Which means, in short, although I intend to do more with Processing and MIDI, I'm simply going to wait until my hardware is updated. Because even if I could get it to run on my hardware, what I want to be doing is making solutions that will run on the average -- aka modern -- machine. It doesn't help any in the long run to have a piece of software that requires OS 10.4 to run.
What I really could have done with, is to not have to spend two days of frustration over compiler errors to finally discover all this.
Oh, and I have an interim solution. Hairless MIDI (yes, that is what it is called) is a serial-to-MIDI converter that works on, well, my lone OS 10.5 machine at least.
With that, I was able to confirm transmission of a MIDI command from desktop to laptop over the airwaves, and trigger QLab remotely to play back a cue.
Except not always. The handling of MIDI events was broken in the Mac implementation of Java. You know the Mac, right? The artist's machine? Only Apple in all their wisdom decided to cripple MIDI when they transitioned to OSX. With a lot of third party aps and hard work you could re-create the lost functionality of Opcode's OMS, and get back a system that actually listed the patch names of your outboard equipment again.
But then Apple goes and loses the MIDI functionality of Java around OS 10.4 or so. It doesn't come back until a later Java release -- that won't run on anything less than OS 10.6 -- but not all the way; there are still a few broken functions. There is a third party library, mmj, which in some implementations on OS 10.4 (and perhaps even OS 10.5) will work.
Of course even then you are left with the need to build a library for PROCESSING, to "Processing-ize" the MIDI functionality in the raw Java. Oh, to be an actual programmer instead of an artist-type, so I could just write it myself. Or, better yet, go straight to CoreAudio and handle it there, without involving Java.
The nice thing about a Java ap is that as long as the Java virtual machine is properly installed on the user's computer, you can stick a custom icon on the Java ap and it will look just like an ordinary double-clickable application.
And Processing makes the whole thing even one step easier, when you are working with a "sketch" in the friendly IDE, which turns your twenty lines of kindergarten code into something that will actually run...and then you can play with the finished Java ap and make it into a practically stand-alone application.
With libraries like proMidi and controlP5, all the heavy lifting is done for you, and even an idiot like me can make a functional serial-to-MIDI translator.
Or, I could, if I had an Intel Mac. Unfortunately I'm still stuck in the PPC world. I have five PPC laptops that see almost constant use, being used by me or loaned or sometimes even rented to work as sound effects playback, multi-track recorders, video playback and virtual instruments. One of them just came back from being a harp in a pit orchestra (played from a Yamaha Clavinova), one is currently playing back sound effects in a booth, and my main machine is being a drum sub-mixer (an improvised solution I really hope not to have to resort to again!)
Which means, in short, although I intend to do more with Processing and MIDI, I'm simply going to wait until my hardware is updated. Because even if I could get it to run on my hardware, what I want to be doing is making solutions that will run on the average -- aka modern -- machine. It doesn't help any in the long run to have a piece of software that requires OS 10.4 to run.
What I really could have done with, is to not have to spend two days of frustration over compiler errors to finally discover all this.
Oh, and I have an interim solution. Hairless MIDI (yes, that is what it is called) is a serial-to-MIDI converter that works on, well, my lone OS 10.5 machine at least.
With that, I was able to confirm transmission of a MIDI command from desktop to laptop over the airwaves, and trigger QLab remotely to play back a cue.
Tuesday, March 20, 2012
Theater Should Not Be a Hackerspace
Harsh words. And surprising for this blog. But hear the full argument.
I've been thinking about this for a while, and from a couple of different directions. The first is that theater -- theatrical procedures, and much theatrical technology -- is conservative. First and foremost, you are performing live. There isn't much room to fail and re-try. You are also performing to the public, which means you have that public's safety to consider. Theater, especially at the school and community theater level, runs on volunteers, outsiders, non-experts, part-timers; all sorts of people who should not have to (and often won't) learn complex new technologies just for a single show. And theater is also steeped in the arts. Most theater people are more comfortable with a paint brush than with a line of code.
The latter is changing. There are more and more artists working with technologies and seeing them as simply another tool. But, again especially with the school and community theater circuit, many of your people are going to be across the generation gap and genuinely uncomfortable with technology.
Or, shall we say, technological CHANGE.
The core technologies in theater may seem arcane to the outsider, but they are often on the order of hundreds of years old. The basics of theater rigging was worked out by Elizabethan sailors. The workhorse lighting instruments have changed in form but functionally would be quickly understood by someone who had learned lighting in the 1930's.
This reaches pervasively and surprisingly. Sound and lighting, for instance, is thought of in terms of events, which are triggered by cues. Even if you have some non-linear actor-triggered multimedia effect going on, it will almost certainly be contained in a wrapper that allows the running crew to interact with it as a single event; as a cue.
Theater is conservative the same way aerospace is. When a bad opening night can cost you thousands of butts-in-seats -- at forty-five bucks each -- and bad sound can even lose you part of your subscriber base, you really don't want to be using untested technology.
The pressure of rehearsal and tech time is so tight, and so many different activities are trying to coordinate, you really do not have the luxury of problem-solving new ways to do things.
We've all been there, of course. We've all been there two days before opening, with the cast, chorus, full running crew, twenty-piece pit orchestra all standing around while someone tries to fix a video projector connection. New technologies are being introduced constantly. And each brings with it new teething pains. But there's only so much one show can stand. This is why whenever possible you don't re-invent the wheel -- even if the old square wheel runs slow and makes a loud rattling sound.
In short, the existing methods are well-understood and well-integrated, and there is considerable risk in changing them. So you don't change them without good cause.
And then there's the other direction to be thinking from; an expansion of the age-old kit-build caveat -- you will never be able to build a cheaper one than you could buy.
Theater is always strapped for money. And effects -- heck, key elements! -- are always scavenged and re-purposed. I don't think there is a theater person out there who has never gone dumpster-diving. So we are already in firm Maker mode here, where we access the functionality of something without regards to the original packaging. Old home stereo speakers propped up on a chair for band monitors. Sockets pulled from an old Christmas Tree light strand to use inside an illuminated bar sign.
I think the important distinction is that the more technical you get, and the more show-critical that tech is, the less applicable this method is. You can scavenge an old floor lamp and re-wire it. You can sort of cobble together a working lighting instrument out of a Par lamp and a coffee can (what we used to call the "tin can fresnel" -- but they don't work that well. On the far end of this scale, I've seen very, very few people make their own lighting console.
What we are talking about specifically, though, is one of the subjects of this blog; geeky bits of mostly electrical engineering to achieve integrations that haven't been seen before. Such as allowing a percussion player to trigger a lighting effect, or putting a doorbell sound under control of the actor, or sweetening the sound of a gunshot on stage and integrating that with a falling plate (or a squib!)
And I'm going to get very specific here.
One of the problems that comes up over and over is a phone ring on stage. Lately I've gotten away from caring so much about placement and complete sonic believability -- I just play a recorded effect out of the nearest speaker and call it good enough.
The cool way to do it -- and I've done it many times in the past -- is to cause the actual phone to ring.
Old period phones with bell ringers are expecting a 90V AC signal at 20 Hz (US). If you supply something similar down the lines, the original bells will ring. Many theaters have a "ring box" lying around for just that purpose.
You can create a nice, conditioned signal, or you can do a hack like half-rectifying raw wall current; this gets you about 60 volts RMS with a half-wave occurring at about 30 Hz. Not right...but it sounds pretty decent anyhow.
That hack also means you are, basically, running wall voltage down a zip cord into the set and on to a prop that will be handled by an actor. If you must do this, at least include a GFCI!
A better version uses a transformer to step down the voltage to about 50 volts, then rectifies it, then sends it through an H-bridge driven at 20 Hz by an oscillator. An even better version starts with a (much safer!) battery and steps the voltage UP.
In the actual Bell design, in what we call "POTS" (Plain Old Telephone System) there is an imposed 40v DC line battery on top of the ring signal. When the phone handset is removed from the switch hook, DC current begins to flow, and in some 200 ms the local exchange detects this and stops sending ringing voltage.
If you connect an old phone to any of the ringer boxes described above, it will probably ring. But if you lift the handset, however, you will observe the following; a nasty buzzing sound from the speaker. A popping sound and perhaps a brief flash of light. Then the distinctive smell of magic smoke.
So if you really want to build a good ring box you want to include switch hook detection circuitry as well.
At which point I need to point out you can purchase a ringer box from various theatrical supply outlets for about $200.
See, this is the point. You can hack a ringer box; many of us have done it. You are taking risks with wall current and with the actor's safety and you also risk the phone getting zapped if someone isn't fast enough on the switch. So you are, in the simplest terms possible, putting the show at risk.
Or you can spend the time to try to do it right. But by the time you've gone through breadboarding, tests, multiple iterations, various parts runs, etc., you've spent over $200 in supplies and a lot more than that in hours. And the commercial product still beats yours -- because it has been tested in hundreds of theaters, and was assembled by engineers who knew how to achieve UL certification.
And had access, too, to economies of scale. To assembly methods and tools that you don't get when you are doing a one-off project. Although that is changing more rapidly than anything else -- with 3d printers and fab houses and shop bots and Maker Spaces and the growing Chinese economy it is getting easier and easier for a small company or an individual to access professional-level technologies.
Almost anything you can imagine probably already exists as a pre-built solution. And in most cases, by the time you get you hand-rolled wireless DMX or floor sensor MIDI input working dependably enough to WANT to hang a show on it, you will have spent as much as you would to just get the commercial version.
So when and where does it make sense to hack?
At the more experimental end. If you are doing performance pieces, gallery spaces, experimental works, things on the fringe of established theater, then the technology may not be there, or may not be appropriate; in this case the robustness of the existing commercial solutions works against you as it will take as long to make it do the thing you just dreamed up as it would to build your own.
In the smallest spaces. When you simply can't afford the commercial box, but volunteer time is there. And when you are in a situation where some risk is absorb-able -- where the audience will forgive some technical failures.
Because you want to. Or because someone wants to. The pay is bad, most of us on this side of the stage don't get to take bows, and sometimes what keeps you excited is doing things in a way that is fun for you more than it is of benefit to the theater.
Every designer has had the experience of putting more into a set or a costume than the show required: because they wanted something exciting in their portfolio, because they wanted a chance to learn a new skill, or even because they wanted to take it home at the end of the show.
And the geekery is the same way. We do it because it is fun. In some spaces, the hairy nature of the improvised circuits -- the "Stone Knives and Bearskins" even becomes something we share with the audience. I have in my current show a bucket of water at the FOH position with a microphone sticking in it. As a sound effect, it ain't much. But as an audience attention-getter....worth it.
But, lastly, in the words of Tim O'Reilly, innovation comes from the hackers. Yes, there will eventually be a commercially-made box that does the thing smoother and safer and at a lower cost. But in many cases the idea was first tried out by crude hacked-together experiments in a dozen shows.
Oh, yeah. And these days, the division between hobbyist and small business is hardly there at all. That robust, well-designed, well-tested box with the surface-mount components and the custom-extruded case may come from a business that runs out of the garage of the tech who first got that prototype working on a show.
Especially if one goes the kit route. But that's a subject for a whole other post!
I've been thinking about this for a while, and from a couple of different directions. The first is that theater -- theatrical procedures, and much theatrical technology -- is conservative. First and foremost, you are performing live. There isn't much room to fail and re-try. You are also performing to the public, which means you have that public's safety to consider. Theater, especially at the school and community theater level, runs on volunteers, outsiders, non-experts, part-timers; all sorts of people who should not have to (and often won't) learn complex new technologies just for a single show. And theater is also steeped in the arts. Most theater people are more comfortable with a paint brush than with a line of code.
The latter is changing. There are more and more artists working with technologies and seeing them as simply another tool. But, again especially with the school and community theater circuit, many of your people are going to be across the generation gap and genuinely uncomfortable with technology.
Or, shall we say, technological CHANGE.
The core technologies in theater may seem arcane to the outsider, but they are often on the order of hundreds of years old. The basics of theater rigging was worked out by Elizabethan sailors. The workhorse lighting instruments have changed in form but functionally would be quickly understood by someone who had learned lighting in the 1930's.
This reaches pervasively and surprisingly. Sound and lighting, for instance, is thought of in terms of events, which are triggered by cues. Even if you have some non-linear actor-triggered multimedia effect going on, it will almost certainly be contained in a wrapper that allows the running crew to interact with it as a single event; as a cue.
Theater is conservative the same way aerospace is. When a bad opening night can cost you thousands of butts-in-seats -- at forty-five bucks each -- and bad sound can even lose you part of your subscriber base, you really don't want to be using untested technology.
The pressure of rehearsal and tech time is so tight, and so many different activities are trying to coordinate, you really do not have the luxury of problem-solving new ways to do things.
We've all been there, of course. We've all been there two days before opening, with the cast, chorus, full running crew, twenty-piece pit orchestra all standing around while someone tries to fix a video projector connection. New technologies are being introduced constantly. And each brings with it new teething pains. But there's only so much one show can stand. This is why whenever possible you don't re-invent the wheel -- even if the old square wheel runs slow and makes a loud rattling sound.
In short, the existing methods are well-understood and well-integrated, and there is considerable risk in changing them. So you don't change them without good cause.
And then there's the other direction to be thinking from; an expansion of the age-old kit-build caveat -- you will never be able to build a cheaper one than you could buy.
Theater is always strapped for money. And effects -- heck, key elements! -- are always scavenged and re-purposed. I don't think there is a theater person out there who has never gone dumpster-diving. So we are already in firm Maker mode here, where we access the functionality of something without regards to the original packaging. Old home stereo speakers propped up on a chair for band monitors. Sockets pulled from an old Christmas Tree light strand to use inside an illuminated bar sign.
I think the important distinction is that the more technical you get, and the more show-critical that tech is, the less applicable this method is. You can scavenge an old floor lamp and re-wire it. You can sort of cobble together a working lighting instrument out of a Par lamp and a coffee can (what we used to call the "tin can fresnel" -- but they don't work that well. On the far end of this scale, I've seen very, very few people make their own lighting console.
What we are talking about specifically, though, is one of the subjects of this blog; geeky bits of mostly electrical engineering to achieve integrations that haven't been seen before. Such as allowing a percussion player to trigger a lighting effect, or putting a doorbell sound under control of the actor, or sweetening the sound of a gunshot on stage and integrating that with a falling plate (or a squib!)
And I'm going to get very specific here.
One of the problems that comes up over and over is a phone ring on stage. Lately I've gotten away from caring so much about placement and complete sonic believability -- I just play a recorded effect out of the nearest speaker and call it good enough.
The cool way to do it -- and I've done it many times in the past -- is to cause the actual phone to ring.
Old period phones with bell ringers are expecting a 90V AC signal at 20 Hz (US). If you supply something similar down the lines, the original bells will ring. Many theaters have a "ring box" lying around for just that purpose.
You can create a nice, conditioned signal, or you can do a hack like half-rectifying raw wall current; this gets you about 60 volts RMS with a half-wave occurring at about 30 Hz. Not right...but it sounds pretty decent anyhow.
That hack also means you are, basically, running wall voltage down a zip cord into the set and on to a prop that will be handled by an actor. If you must do this, at least include a GFCI!
A better version uses a transformer to step down the voltage to about 50 volts, then rectifies it, then sends it through an H-bridge driven at 20 Hz by an oscillator. An even better version starts with a (much safer!) battery and steps the voltage UP.
In the actual Bell design, in what we call "POTS" (Plain Old Telephone System) there is an imposed 40v DC line battery on top of the ring signal. When the phone handset is removed from the switch hook, DC current begins to flow, and in some 200 ms the local exchange detects this and stops sending ringing voltage.
If you connect an old phone to any of the ringer boxes described above, it will probably ring. But if you lift the handset, however, you will observe the following; a nasty buzzing sound from the speaker. A popping sound and perhaps a brief flash of light. Then the distinctive smell of magic smoke.
So if you really want to build a good ring box you want to include switch hook detection circuitry as well.
At which point I need to point out you can purchase a ringer box from various theatrical supply outlets for about $200.
See, this is the point. You can hack a ringer box; many of us have done it. You are taking risks with wall current and with the actor's safety and you also risk the phone getting zapped if someone isn't fast enough on the switch. So you are, in the simplest terms possible, putting the show at risk.
Or you can spend the time to try to do it right. But by the time you've gone through breadboarding, tests, multiple iterations, various parts runs, etc., you've spent over $200 in supplies and a lot more than that in hours. And the commercial product still beats yours -- because it has been tested in hundreds of theaters, and was assembled by engineers who knew how to achieve UL certification.
And had access, too, to economies of scale. To assembly methods and tools that you don't get when you are doing a one-off project. Although that is changing more rapidly than anything else -- with 3d printers and fab houses and shop bots and Maker Spaces and the growing Chinese economy it is getting easier and easier for a small company or an individual to access professional-level technologies.
Almost anything you can imagine probably already exists as a pre-built solution. And in most cases, by the time you get you hand-rolled wireless DMX or floor sensor MIDI input working dependably enough to WANT to hang a show on it, you will have spent as much as you would to just get the commercial version.
So when and where does it make sense to hack?
At the more experimental end. If you are doing performance pieces, gallery spaces, experimental works, things on the fringe of established theater, then the technology may not be there, or may not be appropriate; in this case the robustness of the existing commercial solutions works against you as it will take as long to make it do the thing you just dreamed up as it would to build your own.
In the smallest spaces. When you simply can't afford the commercial box, but volunteer time is there. And when you are in a situation where some risk is absorb-able -- where the audience will forgive some technical failures.
Because you want to. Or because someone wants to. The pay is bad, most of us on this side of the stage don't get to take bows, and sometimes what keeps you excited is doing things in a way that is fun for you more than it is of benefit to the theater.
Every designer has had the experience of putting more into a set or a costume than the show required: because they wanted something exciting in their portfolio, because they wanted a chance to learn a new skill, or even because they wanted to take it home at the end of the show.
And the geekery is the same way. We do it because it is fun. In some spaces, the hairy nature of the improvised circuits -- the "Stone Knives and Bearskins" even becomes something we share with the audience. I have in my current show a bucket of water at the FOH position with a microphone sticking in it. As a sound effect, it ain't much. But as an audience attention-getter....worth it.
But, lastly, in the words of Tim O'Reilly, innovation comes from the hackers. Yes, there will eventually be a commercially-made box that does the thing smoother and safer and at a lower cost. But in many cases the idea was first tried out by crude hacked-together experiments in a dozen shows.
Oh, yeah. And these days, the division between hobbyist and small business is hardly there at all. That robust, well-designed, well-tested box with the surface-mount components and the custom-extruded case may come from a business that runs out of the garage of the tech who first got that prototype working on a show.
Especially if one goes the kit route. But that's a subject for a whole other post!
Friday, March 16, 2012
Processing
I'm on show schedule now, which theoretically means I have a little time to get back to ongoing projects. It works out more like a four-day weekend, though, with the 40-hour work week condensed into several twelve-hour days. Plus meetings, rehearsals, brush-ups, school matinees, and of course ongoing repairs and maintenance.
So every time, as much as I look forward to going on show schedule, I end up burning all that "free" time in errands and catching up on sleep. And then feeling guilty for not getting more accomplished on outside projects. Such as my -- very slight -- progress in theater electronics this "weekend."
I've been learning about the Xbee. These are small digital radio transceivers that can be built into a number of theatrically-useful projects.
The Xbee itself is one implementation of the greater Zigbee standard, which was dreamed up by the Zigbee Alliance as an implementation of the 802.15.4 standard for wireless networks. Specifically, Zigbee is designed for low data rate, low battery usage, and flexible network topologies; it was intended for applications like remote monitoring and home automation.
XBee is a brand name from Digi International, for a series of inexpensive transceiver modules sharing an identical form factor. The later modules incorporate more of the Zigbee protocols, especially the security measures.
You can get an Xbee module for under twenty bucks US at many vendors, including SparkFun, Adafruit, and of course Digikey. The Series 1 modules come out of the box set up for point-to-point bi-directional buffered serial communication at 250 Kb/s and an indoors range of about 30 meters. The "Pro" version of Series 1, with a radiated power of 100 mW, extends that to 100 meters.
Most of them are in the 2.4 GHz range, which is getting increasingly crowded, but the modules are fully addressable and designed to work with poor conditions; depending on how they are configured they will re-transmit, or even seek out a clear channel in which to communicate.
In the basic point-to-point configuration, they are basically invisible; treat it as a cable from one serial port to another (a slow cable, but anyhow...!) This by itself makes it simple to wirelessly connect the micro of your choice to a computer, or rig a wireless MIDI or DMX connection, but the power of these devices does not stop there.
Of course it is never quite that simple. The Xbee's are 3.3v devices (like the Lilypad wearable computer, and an increasing number of Arduino compatibles), but worse (from a hobbyist standpoint) is while they are through-hole devices, the pin spacing is 2mm.
So while you could solder to one, to make it easier to breadboard and otherwise connect to the rest of the world, you want some kind of breakout.
These range from the basic pin breakout (such as the one from NKC Electronics) to a variety of breakout boards with built-in 3.3V regulators and level shifters (so you can connect to micros and other devices with a 5V logic level -- Adafruit as usual has a nice inexpensive one in kit form -- all the way up to an Arduino XBee shield and to the Xbee Explorer USB (available from several manufacturers and vendors) which breaks your XBee out into a USB connection your computer can see.
I am using two Series 1 modules to experiment with at the moment, with one of them on a SparkFun Xbee Explorer USB, and the other on Lady Ada's XBee Adapter, which in turn is connected to an Adafruit FTDI Friend (a small breakout board for the ubiquitous FTDI USB-to-Serial chip, which also includes a mini-USB jack and on-board level-shifting and even a 3.3V regulated power supply!)
And, horribly, it took me ten hours just to confirm that the modules were actually sending clean serial from one to the other.
Why? Well, therein lies the story behind the title of this entry. The various USB devices are actually serial devices which smuggle themselves in through the USB port. You can talk to them using something like OSX's Terminal application. But there are...difficulties.
The first step in Terminal is the command "ls /dev" which will print out a list of all devices connected to the Mac. Look for something like "cu.usbserial-A6007uEn" -- you don't want any of the "tty" devices.
Then a command like "screen /dev/cu.usbserial-A6007uEn" (use the actual device name you found in the list) will connect your terminal window to the USB connection to the XBee -- anything you type will be sent to the XBee and vice-versa.
You will notice a problem right off -- the XBee sends a carriage return, not the new line character the Mac is expecting, meaning your cursor stays right in the corner and everything you or the XBee writes piles up on top of itself.
Oh, sure, you can still work like this. But it is annoying!
Sure, it would probably be simple to write a quick runtime command in the Terminal that would parse the text correctly. But I'm not exactly a programmer. Dealing in naked UNIX like this is a bit much for me.
So I turn to, first, work that has already been done for me. Tom Igoe, he of "Making Things Talk," (the great introductory book on sensors and communications for microcomputing) wrote a nice little terminal application for communicating with XBee modules.
Unfortunately the version I found -- a later, more updated version -- had the wrong kinds of bells and whistles.
You can communicate with the XBee merely by sending it serial data, and it will (if it is in the right mode) faithfully transmit that data to any devices configured to listen on that network and channel. However, to get full value out of your XBees you want to be able to enter Command Mode.
Digi International of course distributes, free, the program X-CTU -- which is the only way (unfortunately!) to update the firmware in the XBee modules.
However, other functions are as easy to get to as entering Command Mode and then typing the appropriate strings. The pdf guide is probably sufficient for someone with the time to wade through and understand what they are reading, but...!
To enter Command Mode, type "+++" and wait one second. Do not hit "Return!" After one second, the module will enter Command Mode, and will stay there unless thirty seconds goes by without an additional serial entry (at which point it will go back to normal operation).
All the commands are suffixed "AT." The most useful that I've found, so far, are;
ATMY -- the node's personal ID code.
ATDL -- the second (low) bit of the ID code of the node it wants to talk to.
ATID -- the PAN ID#; a 2-digit (hex) unique identifier of the network your node belongs to.
ATCH -- the channel your node is using.
ATRE -- restore node to factory defaults
ATWR -- write the current settings to non-volatile memory (otherwise they will be lost when you disconnect it from power).
ATCN -- exit Command Mode.
Not all of these commands take a data byte. In the case of ATWR, say, execution is immediate. If you send, however, "ATMY" the node will return the current value for the personal ID#. If you want to change it, follow "ATMY" with a value, aka "ATMY2" in order to set the ID to "2."
You can easily burn up an hour just messing around querying your devices, changing their settings, querying them again, and so forth. But, as I said, doing it in Terminal can be annoying.
The Rob Faludi-modified Tom Igoe program now known as "Xbee Terminal Max" is very cute. As you type a command, it automatically puts in the "+++," test to see if the node is in command mode, and at the end of each command automatically issues "ATCN." This makes changing the units settings a breeze.
It also means that it suppresses display of the serial communication I was looking for in the first place!
So I went back to the original Tom Igoe program as written up in "Making Things Talk" and entered it by hand. Writing programs out by hand is actually a great exercise. It makes you think about each line, about the syntax, about the purpose of it. Just like many comic book artists first learned by tracing, and composers learn by performing, typing out another person's program can help you learn to program.
The programming environment in this case is Processing.
Processing is part of the same ball of wax that contains Wiring, and the Arduino IDE. It is, in short, an artist-friendly wrapper for Java. The advantages for a project like this is, like the Arduino IDE, it is free and open source, and manifests as a friendly little "Sketch" window, where you can jot down a simple program and then either run it or generate a stand-alone Java ap right from the programming window.
This is not CodeWarrior. This is not about version control and extensive debugging modes...it is about quickly cobbling up something and running it. Processing has a number of built-in and third-party libraries, but the downside is that most of them are oriented towards graphics, video, 3D rendering, machine vision -- stuff the computer-based visual performance artist wants.
However, one of those third-party libraries is a nice simple serial library that makes building a basic terminal in Processing relatively simple.
(I say "relatively" because I had to borrow the code from Tom. I could monkey with it (pun intended) but I am not quite up to speed enough on Processing yet to write something like this from scratch.
Of course there were bugs. I'm going to assume neither Tom nor O'Reilly Media made any errors (I've met Mr. O'Reilly, actually -- at the East Bay Mini Maker's Faire). So the errors were in my transcribing, and in any changes to Processing core or the attached libraries since the code was written down.
Fortunately I already knew the nodes worked (I'd been sending them commands and getting back good replies). And there are status LEDs on the Xbee Explorer USB (yay for blinkenlights!) So I knew my serial messages were getting in, and I even could confirm it had entered Command Mode on the appropriate "+++" prompt.
So it was the usual method of commenting out suspect lines of code, and adding new print commands at various random places. My first hack of that kind was inserting at the very top of the function call "void serialEvent(Serial myPort)" a print statement to the order of "inString = "Serial Event Detected!"".
This is a great way of debugging simple programs. Put in print events that will put something -- the current value of a loop counter, the expected return from a function call, etc. -- on the terminal. Then you can see if the program made it that far, and if what it is doing at that point is what you expected it to be doing.
Anyhow, the inserted line popped up and I knew the XBee was trying to talk to me. At that point it only took another twenty minutes of debugging to track down the remaining errors and to get the terminal application I was writing to properly display the serial output of the XBee node.
At which point I could clean it up a little (inserting some carriage returns and stuff), export a stand-alone java ap, load that ap up on my laptop, and start sending random strings from one computer to the other via the airwaves.
Okay, and part of why it took the better part of a couple of days (that time not spent at the gym, getting groceries, or catching up on sleep) is that while the Xbee Explorer USB worked like a charm, I had to mess around with the connection on the other unit. First, there was a confusing legend on the XBee Adapter. The "Power" LED doesn't light when the unit is getting good power through the regulator; it is actually showing received RF strength! The "Activity" LED is, also, reversed with the Power LED. It took a while of tracing wires and messing around with a VOM before I was sure the breakout board was properly wired and functional.
Then the pinout did not match that of the FTDI Friend, meaning I couldn't just put one into the other but had to run jumpers. The node confirmed it was getting power and even that it could see the other node -- once I understood what the activity LEDs actually meant! -- but it wouldn't reply to serial prompts.
The mistake appeared to be using the provided 3.3V setting on the FTDI Friend. I changed the jumper settings on the FTDI Friend to use 5V logic level instead, and changed the pins I was using on the Xbee Adapter to go through the onboard level shifter instead. And at that point the XBee finally picked up and started answering commands.
And, well, now I'm now into the next show weekend and I'm not sure what I'll get done for the next few (twelve hour) days. Except for one thing -- I mean to borrow a PC laptop just long enough to run X-CTU and upgrade the firmware. Neither of my modules have the firmware version that implements a very, very useful function for remote monitoring; the functions that turn some of the pins into AD converters. Meaning you can hook an analog sensor into an XBee node, and with no additional circuitry but a 3.3V regulator, you have a remote sensor.
And this is exactly what I want for my digital trigger finger project.
So every time, as much as I look forward to going on show schedule, I end up burning all that "free" time in errands and catching up on sleep. And then feeling guilty for not getting more accomplished on outside projects. Such as my -- very slight -- progress in theater electronics this "weekend."
I've been learning about the Xbee. These are small digital radio transceivers that can be built into a number of theatrically-useful projects.
The Xbee itself is one implementation of the greater Zigbee standard, which was dreamed up by the Zigbee Alliance as an implementation of the 802.15.4 standard for wireless networks. Specifically, Zigbee is designed for low data rate, low battery usage, and flexible network topologies; it was intended for applications like remote monitoring and home automation.
XBee is a brand name from Digi International, for a series of inexpensive transceiver modules sharing an identical form factor. The later modules incorporate more of the Zigbee protocols, especially the security measures.
You can get an Xbee module for under twenty bucks US at many vendors, including SparkFun, Adafruit, and of course Digikey. The Series 1 modules come out of the box set up for point-to-point bi-directional buffered serial communication at 250 Kb/s and an indoors range of about 30 meters. The "Pro" version of Series 1, with a radiated power of 100 mW, extends that to 100 meters.
Most of them are in the 2.4 GHz range, which is getting increasingly crowded, but the modules are fully addressable and designed to work with poor conditions; depending on how they are configured they will re-transmit, or even seek out a clear channel in which to communicate.
In the basic point-to-point configuration, they are basically invisible; treat it as a cable from one serial port to another (a slow cable, but anyhow...!) This by itself makes it simple to wirelessly connect the micro of your choice to a computer, or rig a wireless MIDI or DMX connection, but the power of these devices does not stop there.
Of course it is never quite that simple. The Xbee's are 3.3v devices (like the Lilypad wearable computer, and an increasing number of Arduino compatibles), but worse (from a hobbyist standpoint) is while they are through-hole devices, the pin spacing is 2mm.
So while you could solder to one, to make it easier to breadboard and otherwise connect to the rest of the world, you want some kind of breakout.
These range from the basic pin breakout (such as the one from NKC Electronics) to a variety of breakout boards with built-in 3.3V regulators and level shifters (so you can connect to micros and other devices with a 5V logic level -- Adafruit as usual has a nice inexpensive one in kit form -- all the way up to an Arduino XBee shield and to the Xbee Explorer USB (available from several manufacturers and vendors) which breaks your XBee out into a USB connection your computer can see.
I am using two Series 1 modules to experiment with at the moment, with one of them on a SparkFun Xbee Explorer USB, and the other on Lady Ada's XBee Adapter, which in turn is connected to an Adafruit FTDI Friend (a small breakout board for the ubiquitous FTDI USB-to-Serial chip, which also includes a mini-USB jack and on-board level-shifting and even a 3.3V regulated power supply!)
And, horribly, it took me ten hours just to confirm that the modules were actually sending clean serial from one to the other.
Why? Well, therein lies the story behind the title of this entry. The various USB devices are actually serial devices which smuggle themselves in through the USB port. You can talk to them using something like OSX's Terminal application. But there are...difficulties.
The first step in Terminal is the command "ls /dev" which will print out a list of all devices connected to the Mac. Look for something like "cu.usbserial-A6007uEn" -- you don't want any of the "tty" devices.
Then a command like "screen /dev/cu.usbserial-A6007uEn" (use the actual device name you found in the list) will connect your terminal window to the USB connection to the XBee -- anything you type will be sent to the XBee and vice-versa.
You will notice a problem right off -- the XBee sends a carriage return, not the new line character the Mac is expecting, meaning your cursor stays right in the corner and everything you or the XBee writes piles up on top of itself.
Oh, sure, you can still work like this. But it is annoying!
Sure, it would probably be simple to write a quick runtime command in the Terminal that would parse the text correctly. But I'm not exactly a programmer. Dealing in naked UNIX like this is a bit much for me.
So I turn to, first, work that has already been done for me. Tom Igoe, he of "Making Things Talk," (the great introductory book on sensors and communications for microcomputing) wrote a nice little terminal application for communicating with XBee modules.
Unfortunately the version I found -- a later, more updated version -- had the wrong kinds of bells and whistles.
You can communicate with the XBee merely by sending it serial data, and it will (if it is in the right mode) faithfully transmit that data to any devices configured to listen on that network and channel. However, to get full value out of your XBees you want to be able to enter Command Mode.
Digi International of course distributes, free, the program X-CTU -- which is the only way (unfortunately!) to update the firmware in the XBee modules.
However, other functions are as easy to get to as entering Command Mode and then typing the appropriate strings. The pdf guide is probably sufficient for someone with the time to wade through and understand what they are reading, but...!
To enter Command Mode, type "+++" and wait one second. Do not hit "Return!" After one second, the module will enter Command Mode, and will stay there unless thirty seconds goes by without an additional serial entry (at which point it will go back to normal operation).
All the commands are suffixed "AT." The most useful that I've found, so far, are;
ATMY -- the node's personal ID code.
ATDL -- the second (low) bit of the ID code of the node it wants to talk to.
ATID -- the PAN ID#; a 2-digit (hex) unique identifier of the network your node belongs to.
ATCH -- the channel your node is using.
ATRE -- restore node to factory defaults
ATWR -- write the current settings to non-volatile memory (otherwise they will be lost when you disconnect it from power).
ATCN -- exit Command Mode.
Not all of these commands take a data byte. In the case of ATWR, say, execution is immediate. If you send, however, "ATMY" the node will return the current value for the personal ID#. If you want to change it, follow "ATMY" with a value, aka "ATMY2" in order to set the ID to "2."
You can easily burn up an hour just messing around querying your devices, changing their settings, querying them again, and so forth. But, as I said, doing it in Terminal can be annoying.
The Rob Faludi-modified Tom Igoe program now known as "Xbee Terminal Max" is very cute. As you type a command, it automatically puts in the "+++," test to see if the node is in command mode, and at the end of each command automatically issues "ATCN." This makes changing the units settings a breeze.
It also means that it suppresses display of the serial communication I was looking for in the first place!
So I went back to the original Tom Igoe program as written up in "Making Things Talk" and entered it by hand. Writing programs out by hand is actually a great exercise. It makes you think about each line, about the syntax, about the purpose of it. Just like many comic book artists first learned by tracing, and composers learn by performing, typing out another person's program can help you learn to program.
The programming environment in this case is Processing.
Processing is part of the same ball of wax that contains Wiring, and the Arduino IDE. It is, in short, an artist-friendly wrapper for Java. The advantages for a project like this is, like the Arduino IDE, it is free and open source, and manifests as a friendly little "Sketch" window, where you can jot down a simple program and then either run it or generate a stand-alone Java ap right from the programming window.
This is not CodeWarrior. This is not about version control and extensive debugging modes...it is about quickly cobbling up something and running it. Processing has a number of built-in and third-party libraries, but the downside is that most of them are oriented towards graphics, video, 3D rendering, machine vision -- stuff the computer-based visual performance artist wants.
However, one of those third-party libraries is a nice simple serial library that makes building a basic terminal in Processing relatively simple.
(I say "relatively" because I had to borrow the code from Tom. I could monkey with it (pun intended) but I am not quite up to speed enough on Processing yet to write something like this from scratch.
Of course there were bugs. I'm going to assume neither Tom nor O'Reilly Media made any errors (I've met Mr. O'Reilly, actually -- at the East Bay Mini Maker's Faire). So the errors were in my transcribing, and in any changes to Processing core or the attached libraries since the code was written down.
Fortunately I already knew the nodes worked (I'd been sending them commands and getting back good replies). And there are status LEDs on the Xbee Explorer USB (yay for blinkenlights!) So I knew my serial messages were getting in, and I even could confirm it had entered Command Mode on the appropriate "+++" prompt.
So it was the usual method of commenting out suspect lines of code, and adding new print commands at various random places. My first hack of that kind was inserting at the very top of the function call "void serialEvent(Serial myPort)" a print statement to the order of "inString = "Serial Event Detected!"".
This is a great way of debugging simple programs. Put in print events that will put something -- the current value of a loop counter, the expected return from a function call, etc. -- on the terminal. Then you can see if the program made it that far, and if what it is doing at that point is what you expected it to be doing.
Anyhow, the inserted line popped up and I knew the XBee was trying to talk to me. At that point it only took another twenty minutes of debugging to track down the remaining errors and to get the terminal application I was writing to properly display the serial output of the XBee node.
At which point I could clean it up a little (inserting some carriage returns and stuff), export a stand-alone java ap, load that ap up on my laptop, and start sending random strings from one computer to the other via the airwaves.
Okay, and part of why it took the better part of a couple of days (that time not spent at the gym, getting groceries, or catching up on sleep) is that while the Xbee Explorer USB worked like a charm, I had to mess around with the connection on the other unit. First, there was a confusing legend on the XBee Adapter. The "Power" LED doesn't light when the unit is getting good power through the regulator; it is actually showing received RF strength! The "Activity" LED is, also, reversed with the Power LED. It took a while of tracing wires and messing around with a VOM before I was sure the breakout board was properly wired and functional.
Then the pinout did not match that of the FTDI Friend, meaning I couldn't just put one into the other but had to run jumpers. The node confirmed it was getting power and even that it could see the other node -- once I understood what the activity LEDs actually meant! -- but it wouldn't reply to serial prompts.
The mistake appeared to be using the provided 3.3V setting on the FTDI Friend. I changed the jumper settings on the FTDI Friend to use 5V logic level instead, and changed the pins I was using on the Xbee Adapter to go through the onboard level shifter instead. And at that point the XBee finally picked up and started answering commands.
And, well, now I'm now into the next show weekend and I'm not sure what I'll get done for the next few (twelve hour) days. Except for one thing -- I mean to borrow a PC laptop just long enough to run X-CTU and upgrade the firmware. Neither of my modules have the firmware version that implements a very, very useful function for remote monitoring; the functions that turn some of the pins into AD converters. Meaning you can hook an analog sensor into an XBee node, and with no additional circuitry but a 3.3V regulator, you have a remote sensor.
And this is exactly what I want for my digital trigger finger project.
Subscribe to:
Comments (Atom)