Meshed Network Light Suit Technical Details (part 3)

OK, so my last post (part 2) was basically a whole bunch of history of the evolution of my EverSequence light sequencing software.

This year, I figured I would put together some hardware (getting to that in the next post) that I would drive using the sequencer. Instead of relay boards, for the meshed Light Suits I’ll have an Arduino micro-controller that is connected via USB (which actually looks like a serial port) to the PC.  The Arduino Duemilanove has an ATmega368 MCU on-board that includes an Atmel microprocessor and 32KB of flash memory.  Arduino comes with a simple development tool in which you write code using a java-like syntax, then you upload it onto the Arduino using the same tool.  The program basically has to include, at a minimum, a setup() and a loop() function. The setup() gets called at boot-up, then the Arduino goes into a loop that just calls loop() indefinitely.

The first step in controlling lights from the PC via the Arduino was to write a little program  for the Arduino that listens to the serial port. Then I wrote a plugin for the sequencer that that talks to the Ardiono using a simple protocol I concocted.  Basically, to change the state of a pin on the Ardiuno card, I send a period, followed by a hexadecimal number, 2 though B, representing the Arduino pin number I want to control, then a three digit value, 000 – 255.  So, for example, “.A255″ would turn pin 10 on.  Right now, only 000 (off) or 255 (on) matter, but eventually I might support dimming using values in-between (6 of the Aurduino I/O pins can be used for PWM, or pulse-width-modulated output…basically what your wall dimmer does to dim 120V lights.)

Actually, there’s a little more to the program than serial-driven on/off.  I added some support for some simple built-in sequences, and for selecting one of the sequences – all-on, all-off, or serial mode – by using a button connected to analog input in pin0.  In built-in sequence mode, I use bit patterns (one per output pin), that I just rotate through, shifting left every 100ms, and turning on or off based on the leftmost bit.  The actual program is here.

This worked like a charm, as I suspected it would, but something was niggling at me while I was planning it. The problem with EverSequence is: it is a royal pain to design sequences of significant complexity.  It’s just plain time consuming to lay out a lot of spans timed correctly to the accompanying music, especially if you want nice patterns.

At one point I had some thoughts about adding some sort of beat detection which would detect the beats in a music span added to a sequence and automatically place some markers or relay spans on the sequence.  That might help automate the process some, but I didn’t really find any C# libraries that worked, and even with beat detection, I’d still have to invest a lot of time in polishing sequences.  I had another idea though.

Most MP3 players for the PC, including Windows Media Player(WMP), WinAmp, and iTunes, support Visualizations – graphic modes where all kind of cool graphics are rendered on-the-fly and in coordination with the music.  Visualizations can be as simple as bar graphs like on your stereo, or as complicated as 3D whirling clouds and other crazy stuff. I knew that it is possible to write custom visualization plugins for WMP or WinAmp, so I figured it might be possible to write one that, instead a drawing a bar graph representing the power level at certain frequencies, would send serial control codes to my Arduino.

The big hurdle to this was that with both WMP and WinAmp, you have to code you plugin in C++.  My capability level in C++ is pretty minimal – I’m far more adept at C# development. Fortunately, I found a “wrapper” by this guy in C#.  Actually, to be more technical, it’s a C# implementation of the IWmpEffects and IWmpEffects2 interfaces that must be implemented, along with a sample implementation of those interfaces in C#. This was a great starting point and made my job a piece of cake – thanks, Nanook!

Basically, to write a custom plugin, you implement the IWmpEffects2 interface, which includes fleshing out the RenderWindowed method, then registering your plugin with Windows.  Then, when you choose your plugin in WMP, it will call the RenderWindowed method many times per second, passing a structure that contains two sets of arrays; one contains stereo frequency power values, divided across 1024 bands, the other contains stereo waveform values, divide into 1024 time slots.  Think of the Frequency values as a bar graph with 1024 bars.  The Waveform values represent more of an oscilloscope visualization.  See the IWmpEffects2 interface and TimedLevel structure docs on MSDN and elsewhere for more detail.

So – how to use 1024 channels of analog values to drive 12 on/off pins on the Arduino? Averaging them into bar graphs is relatively easy (and is a good visualization of the power values), but a bar graph is a visual representation of what is essentially an analog value.  With my light suits, I just want On/Off values, so I needed to come up with some sane approach of converting something like 20 samples per second of values ranging from 0 to 255.  First, I average the 1024 bands and both stereo channels together in clumps to get 12 channel values that I use to control the 12 pins I use on the Arduino.  So the first 85 x 2 array values get averaged together into the lowest (bass) value, representing from 20hz to 1700hz, and so on.  Next, I track two sets of thresholds, which I’ll call the ceiling and the floor, one of each per channel. The ceiling thresholds are initialized to 255 and the floors are initialized to 0.  As play starts, I have the ceiling and floor values converge towards each other – the ceiling value starts falling and the floor starts rising.  At the same time, I’m comparing the current value of a given channel to its ceiling. If its value exceeds the ceiling threshold, a command is sent over the serial port to turn the corresponding pin On and the ceiling value is set, or “pushed up”, to the current channel value.  Likewise, if the channel value falls under the floor threshold, an Off signal is sent.

The result is pretty good, but there were two things I didn’t like.  One was that the lower (bass) channels, not surprisingly, flash more to the beat. The higher channels are more frenetic.  Since my hardware will be set up with channels 1-4 going to one Light Suit, and channels 9-12 going to another, one suit would actually appear to be more in sync with the beat.  Since I don’t want to screw either myself, or AustinLightSidekick, I reverse/invert the mapping of sound channels to pins every ten seconds.

Another thing I noticed is that the correlation between the low channels and the beat of the music isn’t actually all that great to begin with. I think this might be because Microsoft is doing fourier transforms that aren’t all that great at determining the power level of each frequency, but it could also have  to do with the fact that I’m averaging many frequencies together. In any case, on a whim I switched the code to use the waveform array instead of the frequency array.  On the bench, it looks like this might actually look better in terms of flashing to the beat in some cases.  I wound up making the plugin configurable, so I can adjust the com port, number of channels, and whether to use frequency or waveform data through a properties page.  Once I have it all assembled, I’ll make a decision about which looks best for ALG appearances.

All in all, I think the visualization plugin is going to be great for the meshed light suits.  I’ll be able to have a more diverse playlist, and probably spent less time developing the plugin than I would creating multiple sequences in EverSequences.  That said, I also wrote a driver for EverSequence that talks to the Ardiuno, so in the future, I’ll probably be incorporating Arduinos into my home light setup, and I may incorporate sequences into light suit appearances, as well.

In my next post, I’ll <finally> get to describing the hardware in more detail.

Meshed Network Light Suit Technical Details (part 2)

This is part two of a series of blog entries for the massive percentage of the myriad ALG fans who are fascinated by the technical intricacies of all the AustinLightGuy Light Suits. If you’re in the small majority of people who have no interest in how to pull off a mobile, illuminated, Christmas light suit with various light accoutrements, you might not find this all that interesting.  Surely, though, there aren’t many people out there who don’t want to assemble mobile light-emitting apparel, so this year I’m documenting my endeavors here.

In my last entry, I described some problems I had getting sound from a laptop to work over Bluetooth speakers (which I plan to mount in an illuminated Light Staff). The speakers will broadcast sound - primarily Christmas music – with which the lights are coordinated.  Although it took some fiddling, getting the Bluetooth speakers working was really just an annoying detour.  The much more significant effort has been the development of software that drives lights in a sequence. More recently, my effort has been in developing software that plays mp3 music coordinated with light sequences.

Initially, my light sequencing efforts were focused solely on my house. I guess it was back in the early aughts (’00 or ’01) when that awesome video of that dude’s house, synchronized to music from Transsiberian Orchestra, made the circuit on the internet. At the time, that seemed unachievable – he was using equipment and software that was mainly only accessible to professional lighting people.  Back then I was already festooning my house with a disproportionate number of lights.  While trying to pull off a light show like his wasn’t a challenge I wanted to take on, the more I thought about it, the more I thought I might be able to do something a little less ambitious. I wound up using AR-16^TM relay controller cards from EECI and building my own software-driven relay control box for driving my home lights with pre-designed patterns.  Back then coordination with music was really on the radar.  I’ll go into more detail in my next posting on that hardware, but also the newer generation of stuff I’m using in the light suits.

Back then, I needed software that would let me lay out light sequences, that is to say,

EverSequence 3.3

sequences of of on/off patterns that would be interesting. I decided the best bet was probably to develop a Windows-based graphical program that would display relays as a set of horizontal spans on which I could drag-and-drop widgets represent “on” timespans that could be moved, stretched or shrunk, etc. (see screenshot), and which would then play back those sequences, generating on/off signals sent via serial port, as the sequence progressed.  I wound up writing a custom program in C# to do this, which I called EverSequence.  I’ve continued to enhance that program over the years, adding support for X10 and Insteon controllers and a simpler relay card from Pencom Design, improving usability, etc.

Eventually, I did get to the point where I didn’t have much more to do with it, so back in…I think it was 2008…I got around to adding synchronized sound. It actually took a couple of years – I only work on this stuff around the holidays and adding sound complicated things a bit.  Until then, the sequences weren’t really time-accurate. The main program was basically driven by one timer that fired every 10 milliseconds. When it fired, the code looped over all the relay bars, and if an on or off was due, would flip the designated relay, then the timer would start again. But if there were a lot of relay timer spans (and there are a LOT), it could get behind.  A span that was at, say, 10 seconds into the sequence, might fire at 10.1 seconds.  That’s a big problem if you want them timed to an mp3, which always plays at an accurate speed.

So for Christmas 2007 I wound up re-writing all that to use a timer for each relay channel, or bar, instead. When a sequence starts, the code through all the channels, looking forward to see when the next event (relay on/off, pause, loop, etc) is due for that channel, and sets a timer to fire at exactly that time. When it fires, the associated event is triggered, then it looks forward in time to when the next is due, sets the timer for exactly that amount of time, and restarts it.

Since I don’t work on this stuff full time (AustinLightWife might argue otherwise , it took one season of refactoring and debugging to make this change, but once I worked the bugs out, it worked great! After that, it was relatively simple to add a new span type that played an MP3 or WAV file – the Windows Media SDK makes that quite easy in C#. Now, you’ll see lights synchronized to Transsiberian most nights around Christmas. I broadcast the music by hooking a low-power FM transmitter, meant for MP3 players, up to the audio-out on my PC (so as not to annoy the neighbors), so bring your car or FM walkman  By the way, you can download the latest sequencer program, which I call EverSequence, from here.

Oh yeah, I almost forgot…at one point, I decided I wanted to let people get on my website and control my lights.  I also wanted to be able to queue multiple sequences in a row and have them play automatically a certain intervals with a SequenceTimer. To accommodate both, I used .Net’s sweet remoting capability. I isolated all the classes related to defining a sequence in there own assembly and made the Sequences serializable. Then I made a SequenceCoordinator that is essentially a remotable queue. Clients (the website or the SequenceTimer) invoke enqueue() remotely to add Sequences. I then enhanced EverSequence to include a “slave mode”. In slave mode, the sequencer also checks the SequenceCoordinator via remoting, but looks to see if there is any Sequences in the queue and, if there is, dequeue()’s it and plays it.

Well, this recap of past efforts has wound up longer than I thought, so check back for Part 3, where I’ll actually talk about this season’s software efforts.

Meshed Network Light Suit Technical Details (part 1)

Lots of (non)moving parts

I’ve been putting off posting more details on the meshed-network-controlled light suits, as promised in my last blog entry, until I made enough progress on the whole project to be confident that it’s all going to work.  Although it has turned out to be pretty complicated (see illustration :- ) it hasn’t been that difficult – just time-consuming. In any case, it’s pretty much coming together and it looks like the whole setup will probably meet what I thought was an unlikely ‘stretch goal’: multiple, autonomous, light-festooned nodes (2 light suits, 2 autonomous light staffs and the autonomous light cape)  mesh-network to flash in sync with wireless sound.  I’ll now take a short break from assembling it all to post a couple of entries on how it’s all coming together. This first post will focus mainly on the sound.

So, frankly, I originally didn’t plan on doing that much this year.  I always like to kick it up a notch, no matter how slightly, so I had planned on adding a couple of illuminated Plexiglas staff’s for me and SideKick to carry around, and maybe work on an under-illuminated dim string or two on the suit – but that was about it.  I’ve actually gone WAY beyond that.  I gotta give some credit here… I’ve recently been working on a contract at Balfour to implement an architecture based on an Enterprise Service Bus and workflow engine to consolidate the orders process across their multiple business units.  Balfour, which until recently, was Commemorative Brands Inc. (CBI), will be familiar to many of you especially if you bought a class ring in high school or college.  They also own ArtCarved, as well as a letter jacket company, a year book company, and one or two other commemorative-related endeavors. Anyway, one of my new workmates, and a fellow techno-enthusiast, Jay Graves, noticed AustinLightGuy.com on my resume, I think. After I came on board, he ended up getting me interested in Arduino micro-controllers and the vast community of add-ons and arguably geeky projects (examples here) surrounding them.  Before long, I had talked myself into quite a bit more.  Thanks, Jay – you’ve cost me about a hundred hours of my spare time this holiday season! You better hope AustinLightWife has had a glass of wine or two in her when and if she meets you!

Instead, I decided on the stretch goal of not only synchronizing my suit lights to sound, but also using XBee mesh networking to synchronize the lights on AustinLightSidekick’s suit, the Autonomous Cape, and two new Light Staffs. XBee modules use the Zigbee 8.15.4 wireless protocol to establish mesh networks. This sounds really complicated, but I plan on trying to communicate how easy it actually is in a forthcoming post.

Light Staff Conceptual Schematic

Now, since I had made this decision to synchronize everything to music, I was thinking about what I would need to actually play the music. I thought about getting some fairly flat PC speakers that I could mount on the suit – maybe straddling my shoulders or something – but I sort of didn’t want a whole lot of stuff hanging off of me.  Just doing synchronized sound was already going to mean having a laptop (actually, I’ll probably use our Dell Mini) in a backpack under the jumpsuit. So, I thought “why not put the speakers in one of the staffs, and transmit the audio via wireless too?” (see conceptual schematic, left)  Rather than re-inventing the wheel, I figured I’d just get some cheap Bluetooth speakers, cannibalize them and mount them in the staff, then connect them to the Laptop via Bluetooth Audio, which is supposed to be part of the Bluetooth spec.

I ordered the cheapest pair of Bluetooth speakers I could find on DealExtreme.com (you must check out DealExtreme) that still seemed like they weren’t complete crap (warning: a lot of stuff on DealExtreme.com is complete crap – shop with care!) and would fit into a light staff when dismantled. I’m basically planning on using 1.75″ outer diameter Plexiglas tubes for the staffs.  I wound up ordering it from USPlastic.com, along with a slightly larger Plexiglas box that I’ll mount on top of the music-enable staff to hold the electronics I cannibalize out of the speakers. With a 1/8″ thick wall, that gives me an inner diameter of 1.5″, which should be adequate to contain the speakers from the Bluetooth enclosure, some batteries, some short LED strings, and the XBee receiver and a breakout board with some transistors to drive the LED strings.

Cheap Bluetooth Speakers

I ran into a problem right away with the Bluetooth speakers.  Although audio is a standard part of the Bluetooth spec, it seems the Microsoft Windoze drivers don’t support remote speakers over Bluetooth. What a surprise (not!). So, after a lot of googling, I found some drivers that do. Although they seem to be from some weird Chinese company (BlueSoleil), they are seem to be fairly standard in the world of Bluetooth, and even ship with more expensive dongles.  Even then, after installing the trial drivers I still had problems. Since none of my PC’s or laptops have integrated Bluetooth, I was using the tiny Bluetooth USB dongle, illustrated in the lower-right of the photo, that I had previously purchased for about $2.61 from, yes, DealExtreme.com.  The sound that was coming out of the speakers was horrible.  Very static-y and distorted. Also, the free trial version of the drivers only stream a few meg of audio before requiring you to upgrade to the full version.

So, at first I’m thinking “these must be crappy speakers”.  After all, the dongle is digital – it’s either going to work or not, right? It has been working fine with a Bluetooth mouse and keyboard. I experienced the same problem with two different brands of trial drivers, so I figured it’s probably not the drivers, leaving the speakers as the culprit, right?  WELL, the thing is, when I paired the speakers with my iPhone (which worked no problem, the first try, by the way), I could play music on them no problem and it sounded MUCH better. Not great but, hey, what do you want for $20? So, as unlikely as it seemed, I figured it must be the USB dongle.

I could by one for around $20 plus shipping from a reputable online source, but what fun

Bluetooth Dongles

would that be.  I went back to DealExtreme and bought two (this one and this one ..for as long as the links last) that were more than $2.50 – actually $6.36 and $8.36, respectively – that both came with driver CD’s. One was even pictured with a BlueSoleil CD.  My goal was to get at least one that worked well with audio and came with a full version of BlueSoleil.  Four weeks later (DealExtreme stuff ships from China…for free, by the way!) they arrived. One came with Toshiba drivers which didn’t seem to include audio support..or at least, not audio support that worked. The one on the left came with (yeah!) licensed BlueSoleil drivers.  After installing those, both new dongles play perfectly good audio on the speakers! Problem solved.

In my next post, I’ll go into some detail about the software I’m going to use to generate the light sequences and play the music they are synchronized to.

Kicking It Up a Notch for XMas 2010

ALG groupies will know that every year, I try to kick the light costume up a notch. The first light suit was a meager two or three strings of normal, incandescent mini-lights pinned to some black sweats. I pulled the lead-acid battery out of the UPS (uninteruptable power supply) that Grande Cable installed in my closet to protect all the fiber optic cable crap they mounted on the side of my house (don’t worry Grande, I put it back when I was done with it)  and I hooked it up to a bulky inverter. The whole setup weighed about eight or ten pounds and would run just long enough to get to the Trail of Lights race from the parking lot, linger a bit, do a fast walk/slow run race and get back to the car.

In following years, I upgraded to LED lights, brought on AustinLightSidekick (aka Richard Davis), got a smaller inverter, and added many more strings (SideKick’s bigger C7-style strings actually outshine ME now!) and a rudimentary sequencer. Last year, we went to one-piece jumpsuits and I added the spectacular Autonomous Cape.

So anyway, what to do this year?! Although I’m already busy getting this year’s luminescent Halloween costume together – not to mention blogging about it – I know from experience that if I’m going to add anything to the Christmas outfit, I need to get an early start on it, especially if it’s significant.  After all, half of my November is usually taken up getting the house lights up

Well, I think significant might be an understatement…

Initially, I had some thoughts about connecting the light-sequencing program to the suit and cape. I tried my home-written light-sequencing program out (the one I use on my house) on Cherie’s Dell Mini and it seemed to have more than enough horsepower to run it. That just leaves the somewhat complicated task of building a mobile light relay box or something. So, this guy at work, Jay, got me looking at some hobbyist automation stuff. I’ll go into more detail in a subsequent post but, to make a long story short, I got all motivated and decided to do a mesh-networked, software-sequenced setup that coordinates both light suits, the capes, and hopefully a couple of new light staffs.  Here’s a schematic:

 

Light Suit Mesh Network Schematic

 

If all goes well, I’ll have a Dell Mini inside my suit running the sequencing software which will drive an Arduino microcontroller that will be mesh-networked with all the endpoints (suits, staffs and cape). My plan is to have the sound broadcast via bluetooth to one of the two light staffs, which will have a cannibalized set of bluetooth speakers inside it. It’s going to require a couple hundred bucks in off-the-shelf electronics, some custom-built electronics, and a bunch of software enhancements to drive it all.  This is all pretty ambitious, so I may only pull off part of it but, if successful, I think it will be a hell of an upgrade for 2010!

I’ll post more geeky details for anyone interested soon.

Great Pumpkin Progress

Pumkin Body

My Great Pumpkin is coming along nicely…

I got 5mm EL Wire for the body ridges and they really look nice and thick now that they’re on the frame.  I started out taping them with transparent tape, but that really wasn’t working out and I quickly moved to hot-melt-gluing them. After that, it went on quite fast and looks good. Soon, I’ll black out the lengths that had to detour around the eyes and mouth.

Eye close-up.

Regarding the eyes and mouth, my original concept was to use something (I used thin sheet metal) that would provide the depth you get when you cut through a pumpkin wall. I plan on illuminating the inner surface using thinner, yellow EL wire, and plan on blacking out the exterior surface and covering over the back opening.  My vision (which may not come out as good as I was hoping for) was that you’d only see the eye and mouth “openings” as they were turned towards you, and that there would be the illusion of depth, just as would be the case with a real pumpkin. I think it could look really eerie if it comes out right.  I’m not sure I’m going to get the sort of general glow in the illuminated voids I was hoping for, though. Will have a better idea soon, as I complete the eyes and mouth and get a look at it in the dark.

Coming soon.. progress on this year’s Christmas Light Suit enhancements!

Halloween 2010

Well, we’re out of the aughts and it’s almost holiday season, 2010!

To celebrate, I’ve decided to go ahead and do a light-oriented costume (actually, two – Cherie wants one too now) for Halloween this year.  My friend Sean got me thinking about doing more with Electro-luminescent (EL) wire.  ALG groupies might recall I’ve had AustinLightGuy.com spelled out in it on my Christmas light suit in years past.

Tomato cages being broken down and re-assembled

So, I bought a hundred feet of 5mm, orange ELwire, a few feet of yellow, a couple of inverters to drive it all, and a bunch of tomato cages.  Here is the work-in-progress.

I guess it’s basically a kind of a “Great Pumkin” theme.  A huge, glowing pumkin.

Almost finished with the structure

The tomato cages are turning out to be just the right rigidity to support themselves and the EL wire, I think. Maybe a tad to heavy-gauge.. I plan on getting the smaller ones for Cherie’s.

One problem: it’s currently to wide to go through a standard, interior door.  I’m going to try to elongate the cage slightly and reduce the width, but I may be stuck with mostly outdoor activities. Hopefully, I’ll get invited to some (hint, hint).

ELwire and AustinLightCat II

Happy Halloween 2010!

Trail of Lights Officially Dead

In case you missed it, the Austin City Council officially killed the Trail of Lights this past week, in favor of channeling the three hundred and seventy some odd thousand dollars it would have cost to park maintenance. While I can hardly argue that our parks could use more maintenance, $370K seems like a paltry amount to spend on one of the things that Austin is famous for.  I’d argue that it’s things like the Trail of Lights that make people thing “wow, Austin is such a cool city..I want to live there!”  The Council might want to consider it an investment in Austin, much like all the other multi-million dollar investment projects the City endorses (and gives massive tax breaks to).

I encourage all ALG followers to go to the City website and express their displeasure.

On a related note, while thinking about what to write in this post, the $10 million dollars that Austin Energy pays into the Economic Growth and Redevelopment Services Office was on my mind. Trail of lights seems like, say, THE PERFECT THING FOR AUSTIN ENERGY TO FUND, but I guess not much of the money for the Trail goes into the pockets of any big players around Austin, so it’s probably not an option. Anyway, I was wondering what Austin Energy’s budget looks like. Weirdly, I couldn’t really find much. Even the department’s own annual report is strangely lacking in any actual profit/loss statements. The lack of detail in this report would be criminally punishable if it were a publicly traded corporation. Weird….

Welcome!

Welcome, AustinLightGuy fans!

In addition to a number of enhancements to wearable light costumes (which I’ll blog about shortly), I’ve decided to enhance the web experience this year by adding this blog. I hope to describe what I’m up to in more detail here, both in terms of kicking the lights up a notch, as well as planned appearances and maybe pics and comments following some.

Keepin’ it bright,

Andy Coulson (aka AustinLightGuy)