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.)
Friday, March 30, 2012
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.
Friday, March 9, 2012
You Don't Detect Any Traps on the Door
This was a typical moment in the old paper-and-pencil D&D games.
"Have the thief look for traps on that door."
"Okay, I'm looking for traps. I rolled an 8."
"You don't detect any traps."
"Great, there's no traps on the door! Oh, wait. Or are there traps, but my roll was too low to detect them? Which is it?"
"You don't detect any traps."
"Damn. Hey, guys, can we let the Halfling open the door this time? I'm kinda low on hit points."
I am, right now, repairing wireless elements. All I know is that something failed in performance. It might have been a bad connection, RF interference, the element might have sweated out. All I know is the element was suspect and was removed for testing.
Right now, on the bench, it works just fine. I connect it up to a mic pack, connect my scanner or a spare receiver to speaker or headphones, and shake it, twist it, tap it, etc.
It appears to be working.
Does that mean it isn't broken? No. All it means is that any problems it may have were not detected at this time.
All in all, I prefer it when it fails. Because then, even though the job takes up to forty-five minutes of squinting through a magnifying lens and working with very small tools, I can try to fix it.
As it is, all I can do is wrap it up and put it in the list of "Tested, presumed working." Until it fails in the place you don't want it to fail...on an actor, in the middle of a scene.
But that is the nature of all equipment. And that is why you really don't want an honest answer from an engineer if you ask "Will this work for tonight's performance." Reality is that problems develop over time, and not all of them are predictable (if we could predict them, we'd have already fixed them). So we can't validate the notion of perfection. All we can state is that, in our experience and professional opinion, the chances are against anything failing on tonight's performance.
This is not what Stage Managers want to hear, of course. Which is why we too often have to fall back on the white lie of "We fixed it." And when something does fail down the road -- because something always will, and that is why we have a skilled sound crew, not a random volunteer, running the board -- management types are all too likely to point fingers and say "You PROMISED it wouldn't break!"
Remember, those weasel words are there for your protection.
"I didn't detect any traps on the door."
"Have the thief look for traps on that door."
"Okay, I'm looking for traps. I rolled an 8."
"You don't detect any traps."
"Great, there's no traps on the door! Oh, wait. Or are there traps, but my roll was too low to detect them? Which is it?"
"You don't detect any traps."
"Damn. Hey, guys, can we let the Halfling open the door this time? I'm kinda low on hit points."
I am, right now, repairing wireless elements. All I know is that something failed in performance. It might have been a bad connection, RF interference, the element might have sweated out. All I know is the element was suspect and was removed for testing.
Right now, on the bench, it works just fine. I connect it up to a mic pack, connect my scanner or a spare receiver to speaker or headphones, and shake it, twist it, tap it, etc.
It appears to be working.
Does that mean it isn't broken? No. All it means is that any problems it may have were not detected at this time.
All in all, I prefer it when it fails. Because then, even though the job takes up to forty-five minutes of squinting through a magnifying lens and working with very small tools, I can try to fix it.
As it is, all I can do is wrap it up and put it in the list of "Tested, presumed working." Until it fails in the place you don't want it to fail...on an actor, in the middle of a scene.
But that is the nature of all equipment. And that is why you really don't want an honest answer from an engineer if you ask "Will this work for tonight's performance." Reality is that problems develop over time, and not all of them are predictable (if we could predict them, we'd have already fixed them). So we can't validate the notion of perfection. All we can state is that, in our experience and professional opinion, the chances are against anything failing on tonight's performance.
This is not what Stage Managers want to hear, of course. Which is why we too often have to fall back on the white lie of "We fixed it." And when something does fail down the road -- because something always will, and that is why we have a skilled sound crew, not a random volunteer, running the board -- management types are all too likely to point fingers and say "You PROMISED it wouldn't break!"
Remember, those weasel words are there for your protection.
"I didn't detect any traps on the door."
Subscribe to:
Posts (Atom)