XBee reliable enough for a stage production?
Phil Pilgrim (PhiPi)
Posts: 23,514
I've been tasked with providing LED special effects for a high school play. It has to be possible to select from several effects sequences during the course of the play. To that end, I have three choices:
- If the number of sequences is three or fewer, I can grab light signals from the lighting control person via two of the AMX-controlled outlets.
- If more than three, I can put a keypad on the controller so that a person behind the proscenium can operate it.
- Or, I can make a different keypad box that connects to the controller box via XBee.
The reason for considering #3 is that the controller box has to reside on stage left. The stage manager sits on stage right. I can't run a cable across the stage, and the director would prefer not assigning an assistant stage manager on stage left to operate the control box.
I looked at the lighting system 110VAC outputs with my scope. At less than 100% on, they're extremely noisy. With gosh-knows-how-may lights on at once, there would have to be a lot of RF hash in the theater.
So how good is XBee, really? Can I depend on it? Or am I just asking for trouble?
Thanks,
-Phil
Comments
XBee modules are pretty resilient. You might want to select a channel that is "non-overlapping" with WiFi, and change the default PAN to something unique. I helped my friend Matt with a Propeller powered prop for a live stage show. The prop needed one digital and one analog input. The "remote" was nothing but an XBee with inputs configured and the prop used its XBee to grab data from the remote. We used 64-bit addressing to prevent possible problems and had none.
In my "day job" I work for a company that deploys about 4K XBee units every year in P1-powered laser tag products.
We use Xbee on tally lights for steadycam on big live tv studio shows. (ex. Eurovision song contest...)
, we use a P1 to translate the tv truck tally data to the Xbee. ( TSL4.0 tally protocol)
8 outputs, on or off, no complex data on Xbee
The shows use huge light settings and well engenered wireless transmission of all kind.
Never get a bad return from the operators.
Of course
Daniel
@"Phil Pilgrim (PhiPi)"
Just found this on my system, don't know why because I have the actual book.
Craig
Oh, and this.
Too big to upload so this is DropBox
https://dropbox.com/s/7y90lsngwg0ta5y/Propeller%20Book.zip?dl=0
Craig
https://www.parallax.com/product/programming-customizing-the-multicore-propeller-microcontroller/
https://www.parallax.com/package/programming-customizing-the-propeller-multicore-microcontroller-ftp-archive/
https://www.parallax.com/package/programming-customizing-the-propeller-micrcontroller-downloads/
I tested the XBee connection in the theater today to select from one of two LED special effects. It worked flawlessly. Nonetheless, I'm going to switch to XBee Pro to guarantee a secure connection from the lighting booth to the stage. In total, I'm probably looking at four different effects.
I've been warned by the director, however, to avoid anything too busy (i.e., to me, too interesting), since it draws attention away from the performers.
So the director's standing joke is this:
Q: How many techies does it take to screw in a lightbulb?
A: It can't be done.
The director needs some direction. I'm working on it.
-Phil
I'm my early days of acting (student and independent films) I often assisted with technical problems, and sometimes built effects for the project I appeared in. Some years back I did some tech work for a very popular web series called The Guild. After solving a bunch of tech problems, the star and producer, Felicia Day, approached me and said, "I thought you said you were an actor."
My latest challenges are these:
Stagecraft offers a lot of interesting design challenges. If you ever get a chance to volunteer assistance to a school or civic theater production, go for it! It will definitely broaden your horizons and skillsets.
-Phil
@"Phil Pilgrim"
Magnetic Pogo Pin connector?
I considered these for Android-tablet (machine HMI) charging but would probably not be a good idea with metal chips all over the place
Craig
Phil,
Is there a place to stash some 18650s since they are energy dense?
Could you place a switch or other sensor at the fully raised position to kill the power when it's there?
Can't you just hang a long cable down from some rigging or something to the scrim, so that the cable never needs to be disconnected and just hangs in a U-shape when the scrim is raised?
Thanks for the suggestion! Yup. That would've been nice. But the bottom of the loop would end up at chin height in an area where actors are entering and exiting.
I think I've got a dead-man connector figured out. I turns out that those little super magnets can be soldered to, which will make this job a bit easier.
BTW, all 400 LEDs are installed on the scrim now. It turns out that I didn't need to install an auxiliary power cable to tap in along the way. By just end-feeding 12V, I can light up all the LEDs with almost no diminution in brightness toward the end -- unless I color them all white, then it's noticeable. The really weird thing is that this is with a 24W regulated wall wart I had lying around the shop. And here I spent good money on a 150W Mean Well power supply!
Also, I tested my XBee Pro setup from the lighting booth to backstage today with no problems. Fingers crossed. I suppose I'll have to attend all six performances, though, just in case.
-Phil
Be careful, on rehearsal you don't have crowd.
When the real show start, everybody take his smartphone and trow a lot of RF inside the room.
The peoples also absorb a brunch of RF power of you Xbee.
If you have a spectrum analyzer, you can already look at the empty room.
The antenna location and shape are more critical for game winning, against the RF power output.
Good luck!
I would suggest sending the data with a CRC and some sort of acknowledgement handshaking and repeat attempts if the acknowledgement fails. I would step up from a simple XOR CRC and implement something more like a MODBUS CRC. I have MODBUS CRC broken down into it's 'atomic' elements that I have ported to PIC, Arduino, Python, and Perl if you want I can help you with that. Just send me a PM.
Modbus CRC using a lookup table for speed:
DIM INTEGER crc_table(255) ' lookup table for CRC generation genCRCtable ' generate the lookup table '------------------------------------------------------------ 'generates a lookup table for fast crc calculation SUB genCRCtable LOCAL i%, j%, k%, crc_const% = &HA001 FOR i% = 0 TO 255 k% = i% FOR j% = 1 TO 8 IF k% AND 1 THEN k% = k% >> 1 k% = k% XOR crc_const% ELSE k% = k% >> 1 END IF NEXT j% crc_table(i%)=k% NEXT i% END SUB ' ' returns the CRC as a string FUNCTION CRC16$(a$) LOCAL CRC% = &HFFFF, n% FOR n% = 1 TO LEN(a$) CRC% = (CRC% >> 8) XOR crc_table(CRC% XOR ASC(MID$(a$, n%, 1)) AND &HFF) NEXT n% CRC16$ = CHR$(CRC% AND &HFF) + CHR$((CRC%>>8) AND &HFF) END FUNCTIONIn the laser tag code I write we can send packets over IR and over XBee. At the end of the IR packet we add CRC8 (borrowed from 1-Wire) . When using XBee, we build the IR packet and then pop it into an XBee API-1 transmission. I wrote a MODBUS object a long time ago that used CRC16 -- note that the methods are identical other than the starting point of the CRC, the polynomial, and the size of the return value
pub crc8x(p_src, len) : crc '' Calculate 8-bit CRC repeat len crc ^= byte[p_src++] repeat 8 crc ->= 1 if crc & $8000_0000 crc ^= $8C crc &= $FF pub crc16x(p_buf, len) : crc '' Calculate 16-bit CRC for MODBUS RTU crc := $FFFF repeat len crc ^= byte[p_buf++] repeat 8 crc ->= 1 if (crc & $8000_0000) crc ^= $A001 crc &= $FFFFThe underlying 802.15.4 protocol used by XBee seems to handle problems -- I don't every remember getting a packet from an XBee that failed my CRC check. With XCTU you can bump the number of repeats if needed. We did that with laser tag because it's possible for multiple player to be "killed" at the same time and we want to ensure all messages (the device reports its "death") get through.
Yup, I saw that: set RR to a non-zero value. So I tried that with XCTU: set it to 8 and write. But when I did a read to check it, it was still 0. Gotta move on, regardless.
So what I think I'll do is use some kind of redundancy-based forward error correction so the onstage unit doesn't have to transmit anything back. When you stop to think about it, the LED display itself is the ultimate feedback mechanism. If the operator sees that the command was not executed, try again. Also, I'm planning to have an identical push-button console on the onstage unit. In the absolute worst case, someone can operate the effects from there.
Also, I dusted off my XBee loader program so I can load programs to the onstage unit from the lighting control booth upstairs. Having to do programming at the HS instead of in my shop is not ideal. But this will enable me to make program tweaks in real time when I can witness how the actual effect works.
BTW, the play is Shakespeare's A Midsummer Night's Dream. I've got sprites, fireflies, twinkling stars, and a few other effects in mind. Should be fun. Here's the playbill I designed for them:
-Phil
Here's a photo of my "dead man" disconnect:
The square thing on the left gets screwed to the stage floor. It contains four disc super magnets which can move up and down by 1/16" to accommodate any slight misalignments. Each one is soldered to a lead in the four-conductor cable that feeds it. The plug on the right contains four rod super magnets. Each one of them is soldered to a lead that exits out of the side. Both plug and socket are made from laser-cut layers of acetal copolymer.
In practice, the large hole in the plug is connected to a rope or cable leading up to the bar to which the scrim is attached. That cable is less slack than the electrical cable feeding the LEDs attached to the scrim. So when the scrim is raised, the circuit will disconnect before the electrical cable tightens. Once the scrim is lowered again, it's a simple matter to reconnect the plug.
The rod magnets are not supposed to move in their housing. To that end, I'm gluing them into place using West System Gflex epoxy.
-Phil
For several years now, I have been using neodymiums for mounting my control components in electrical cabinets. So much nicer than DIN-rail and it means no drilling/tapping (machine retrofits).
I detest having to extend conductors and in many cases, it's just not feasible to completely replace. With magnets, I'm able to make adjustments to the location of each element to suit the existing wiring and avoid ending-up with "banjo strings"
Craig
I finally got around to assembling and testing the LED receiver board today. Here's a photo:
It receives the differential RS485 signal from the transmitter and converts it to a solid 5V single-ended signal that the LEDs can deal with. It consists of an LTC485 RS485 chip, an LM78L05 regulator, a termination resistor, and several filter caps. This was just stuff I had in my junk drawer from past projects The unused connection on the lower left was meant to provide auxiliary power tapping into the LED strands along the way. But this turned out not to be necessary.
I'm glad I went the RS485 route. Individual RS485 lines are not very clean when examined on a scope. But the differential receiver cleans everything up perfectly.
If you do anything like this, make sure you use an RS485 transceiver that's not slew-rate limited, as many are. The LTC485 is rated to 2.5 MHz.
Tomorrow, the big PCBs arrive that interface to the Activity Board. I can't wait!
-Phil
Yesterday I assembled one of the LED driver boards. Here's what it looks like:
It has two RS485 drivers, directed to two different LED strings. There's a socket for a lighted 12-key keypad, as backup for the XBee unit in the lighting booth. And in case of a real emergency, I've added two micro-USB style power inputs, which go through dividers to two port pins. This unit will be proximal to two DMX-controlled outlets, so the control booth will still have access to three different effects, plus "off". The dividers are stiff enough to ensure quick discharge of the wall supplies' output caps when the AC is turned off.
-Phil
Went up to the HS today to run the wiring and secure it to the stage floor with gaffer's tape so folks won't trip over it. After several programming snafus, I got all individual parts of the system to work. Starting Monday (after getting my taxes done), I'll be working in the control booth for a major programming marathon. That'll be the fun part!
Right now, Forms 1040, 1120, and all their freaking attachments beckon. Yuck!
My only real regret, so far, is that I didn't add sliders to the board for fades and such. It would've been so easy to interface them to the ABWX's ADC. Next time ...
-Phil
Following this
Looking forward to opening night report!
Today I worked on fades and ascertaining that XBee over the distance from the lighting control booth to the stage would work. It did -- both for controlling the lighting from a keypad and for reprogramming the controller. The former is done via XBee Pro units; the latter, via a low-power XBee attached to my laptop's USB port.
Tomorrow I get to experiment with different effects. But writing programs in the control booth is PAINFUL. There's no table space for a laptop or a mouse, so I have to put my computer on a chair and crouch over to use it. I still haven't found a switch for the overhead light, so the door has to be propped open just so I can see what I'm doing. As a consequence, I'm trying to get most of the programming done at home, using one 50-LED strand that I reserved for that purpose.
I've moved everything out of my shop into the living room. That way, when I take my kit to the school, I can just grab everything in sight and know that I have it all without having to guess if anything was left behind among the shop clutter. I had set up a card table for doing my taxes -- empty horizontal space around here is precious -- and now it's control central for programming.
More to come,
-Phil
You should see "inspector gadget" here
I always have a Windows tablet, Android tablet and everything I need, in one place:
https://ayegear.com/products/ayegear-j25-jacket
Tablet + Bluetooth keyboard means I can program in some pretty awkward places. At a pinch, I can use the on-screen keyboard.
Today I finished the fireflies and twinkling stars effects. I decided to set up on the stage, rather than in the lighting booth. I could stand in front of the stage and could spread out with plenty of room for a mouse.
But ... there were two faculty absences today, and the auditorium was filled with two double study halls back-to-back, one with rowdy freshmen. Moreover, it was a "block" day, which means class times were an hour and a half each. So a three-hour constant din among a cesspool of viral transmission. I wore a mask.
But I managed to get my programming done during that time nonetheless. Then, after classes, the quiet, disciplined drama kids showed up for rehearsal, and I could demo what I'd done. They seemed to like it.
I'm back home now, with the laptop set up on the card table again to program one more effect. (BTW, that card table was purchased many years ago in Medford, OR, when I was installing a fruit sizer project there. Whenever I haul it out, the memories of that trip come flooding back. I had developed a Z8 priority multitasking operating system for the sizer firmware and, when I got there, I realized that I had made a terrible blunder. I got the table to set up in my motel room where my CP/M development computer and the control units could sit while I tried to fix things. I put a "Do not disturb" sign on my door. Major stress! Finally got it to work, though, and the installation was successful. Looking back, that was way worse than today's distractions.)
-Phil
In another thread, I outlined a way to do forward error correction (FEC) using Walsh functions. I've incorporated that method into the unit that transmits keystrokes from a 12-key keypad in the lighting control booth, via XBee, to the LED controller backstage. Although transmission has been flawless over XBee so far, once the show starts, there will be wireless headsets used by the crew, an audience full of cellphones, and really severe hash generated by the DMX lighting controllers -- IOW, a pretty nasty RF environment.
Using FEC over XBee, though, begs the question about the error modes that XBee might encounter. If single- or double-bit changes are one of them, then the FEC method will be helpful. But I suspect that might not be the case, as I'm sure that XBee already has robust error correction built in. So, as a backup, the keypad transmitter sends the keycode four times at 100ms intervals. The gap between is to prevent all four keycodes from being transmitted in the same XBee data packet. This way, four separate packets would have to be lost for the data to be missed, rather than just one.
At the receiving end, back-to-back duplicate keycodes are ignored, in case multiple packets make it through.
-Phil
Opening night was Friday. The kids were freaking amazing! Especially Puck. This was played against a weather forecast that called for 50 m.p.h. winds. To be prepared, I printed out rain checks, in case the lights went out half-way through the performance, that we could pass out to patrons so they could return for free to a subsequent performance. Fortunately, the power failure waited to occur until just after the cast took their final bows and folks gathered front-stage to bestow flowers and take photos. Perfect timing -- assuming it had to happen at all!
But there was a glitch in the LED effects. Each effect was prepended by a pattern on the scrim that I used to map the LEDs, so I could restrict certain effects to certain areas, e.g. twinkling stars near the top. I figured it must be a program bug, so I went to the HS yesterday afternoon to try to fix it. The stage manager told me that it only occurred when the effect was transmitted from the lighting booth, not when it was keyed in backstage. Oh cripes! RF interference? I tried it myself from the lighting control booth, but I could not get the glitch to recur.
Anyway I wracked my brain to figure out where in the program the glitch might be coming from. After an hour and a half, the director said, "Okay, Phil, you've got ten more minutes!" Then the light went on: the mapping effect was assigned to the number (#) key on the keyboard, which I assumed no one would use during a performance. The effects were assigned to keys 1-6, with 0 to fade off, and * to kill instantly. The only way the glitch could occur would be for someone to hit the # key. So I deleted the effect from that key at the last moment.
Last night's performance went without a hitch. It finally occurred to me today to ask the director how the effects were denoted in the lighting script. Were the key numbers prepended by #, e.g. #1, #2, etc.? "Well, maybe." And the lighting tech must've interpreted these instructions literally!
-Phil
Congratulations on the performance of both you and the HS kids.
Good job in finding the source of the glitch, whenever humans are involved there is always something that seem to crop up...