Repair the WiFi on Your Foscam FI8904, FI8905 or Maygion IP Camera

I have three different WFfi-connected network cameras; a Foscam FI8904, an FI8905, and a “Magion” Chinese knockoff I got on DealExtreme. These cameras are all pretty similar. There are anecdotal stories that the Maygion is really just an unbranded Foscam with custom software, but I haven’t really confirmed this. They’re fairly low-end (among the least expensive in terms of WiFi outdoor security cameras), which means the image quality is mediocre, especially in the brightness extremes of outdoors.

Also, the build quality is not great. Between the three of them, there’s always something going wrong; and AC adapter failing, IR emitters burning out, etc. Replacing the AC adapter is no big deal, and you can actually find replacement IR LED arrays on DealExtreme, so I’ve had some luck replacing those, as well. Twice, now, I’ve had a camera just stop working over WiFi.  You’d think this would be a situation where the only option is to toss it out and but a new one, but it turns out it’s not! In both cases I was able to repair the WiFi..for as little as $10!  To get that cheap, I had to do some more serious hacking (as I describe near the end of this post) but my first fix was quick, safe, and cost about $35.

I both cases where the wifi quite working, there was no obvious symptom..no errors in the log or anything…it just stopped reporting found wifi networks through the web admin page and no longer connected to my home hotspot.  It worked fine via 10baseT. When the first one died, on a whim I decided to crack open the case and see if it was anything obvious, but I had little optimism. The circuit boards inside consumer electronics like this tend to be a nearly incomprehensible array of surface-mounted components – impossible for an amateur like me to repair.  In this case, though, I discovered room for optimism.

Mother and Daughterboard inside Maygion camera

The rear of the camera can be removed by unscrewing four hex nuts, then carefully pulling the whole assembly out. Inside are a motherboard and a daughterboard mounted to it with a couple of stand-offs. The daughterboard is..you guessed it..the wifi board! Shown here already removed from the stand-offs. it is connected to the antenna and to the motherboard via a 4-wire jumper. These pictures are actually from my second repair (of my Maygion camera), but the two Foscams are almost identical.

Figuring it was still a long-shot, I started googling for identifying markings on the assembly. Turns out it’s relatively easy to find direct replacements for this board! The “model number” on the white sticker, “vnt6656g6a40″, turns up multiple hits.

Maygion identifying sticker

Interestingly, the identifying product information on the Maygion camera is almost the exact same sticker! They most likely stick one to the outside of the camera because it also shows the mac address.

Although I ordered my first replacement for about $35, I recently found one here for only $15 (may be a lot of shipping, though). As of this writing, they also seem to be available here and here.

The first time I made this repair, it was to one of the Foscams. As a stopgap measure to get the “better” (bigger IR emitter array), defective one working, I actually just cracked open the other one and swapped the boards. Bingo! It worked like a charm! I was now confident that a replacement board would do the trick and would be worth the $35. Sure enough, when the new one arrived, it was essentially identical to the original – even the jumper plug was the same. I plugged in the 4-wire jumper and antenna, powered it up, and presto!

This was an easy and convenient fix, but when the wifi died on my Maygion, I started to think this could add up if wifi goes out on a camera every six months or so. Ultimately, I should probably look at a camera with slightly better build quality. There are some in the $200 price range which might be a little better, while still being affordable. Still, there’s no guarantee that these won’t use a similar cheap (and trouble-prone) wifi module. It could be that the power supplied to the daughter board by the motherboard and, indirectly, the AC adapter, is poorly regulated and may be contributing to early failure, but who knows!?

So as I mulled over spending another 35 bucks, I thought about something that had intrigued me the first time around…time for some AustinLightGuy hacking!

The description of the daughterboard on one or more sites is typically something similar to “VIA VNT6656  USB Wireless LAN Module”. Hmmm…USB… Clearly, the 4-wire jumper connecting these things to the motherboards is just a USB connection! Digging a little deeper into the specs, I also found this: “The VT6656 WLAN Controller chip on the VNT6656 USB WiFi Module supports all major Microsoft Windows and Linux operating systems.” If you examine the chip on the daughterboard, it is, in fact, a VIA VT6656, and apparently very common wifi chipset! So i got to thinking, ‘well, what if I just bought the cheapest USB wifi adapter I can find that sports the VT6656 chipset, and the tear it open?’

That’s what I did. I bought this USB stick on ebay (advertised as a “54Mbps Wireless USB Adapter For DELL Latitude, INSPIRON & XPS Laptops”, as an FYI, since I assume the link won’t last forever). It was $9.99 with free shipping. When it arrive a few days later, I immediately removed the one screw holding the case closed, and opened it up. The result is actually comical! Here are two photos showing the camera daughter board next to the wifi USB stick board.

Camera daughterboard (left) next to USB WiFi stick (right)

Camera daughterboard next to USB WiFi stick – reverse

As you can see, these boards are practically identical! Even then component layout is very, very similar. My guess would be that anyone who want to knock out a wifi module just implements one based on a “Typical Application” diagram supplied by then vendor, VIA, or something like that. Anyway, this is clearly hackable.

First, I figured out which wires were which on the camera jumper by testing voltages with my multimeter. I came up with this pinout:

Next, I figured out which were the corresponding pins on the USB stick by comparing the connector to a standard USB connector pinout.

Piece of cake. Now I just removed the USB connector from the wifi stick, cut the connector of the jumper and soldered the wire right to the stick. (Actually, I first fooled with trying to transplant the micro connector from the original daughterboard, but this surface-mount stuff is really tiny and fragile and I eventually gave up in favor of the brute force approach : )

Antenna wire soldered to antenna trace on USB stick and ground.

Cool, now just to connect the antenna…DOH! The connector on the original module is male and the one on the stick is female! Oh well..after abandoning another effort to to reuse the old one, I just cut off the connector and soldered the antenna wire right to the board.  Next, I did an experimental power-up and, sure enough, it immediately connected to my wifi – Sweet Success! By the way, when these things boot up correctly, there is a little LED on board which lights up…goes off for just a moment about 10 or 20 seconds in to boot, then turns back on. It also flashes when in ‘discovery’ mode. On dead boards, it’s just remained on all the time.

So, I am now confident that I can repair dead wifi on both Foscam and Maygion cameras for just $10. Not a bad deal.

Kudos to Ernie Cline’s “Ready Player One”

A while back I saw the hardback (softback?) of ”Ready Player One“ on display at some big-box bookstore. I think the flashy cover drew my eye. At the time, it looked interesting, but I don’t really buy paper books anymore, plus I’m always suspicious of those books on those display tables – seems like they’re the ones the publishers want you to buy, which probably aren’t the ones I want to read. Turns out that was totally not the case with Ready Player One.

A few days ago, it came up as “recommended” while I was cruising for new Kindle books. A quick read of the reviews and I was all over it. I’m not a book reviewer, and this blog isn’t about reviewing that kind of thing, but in this case, I just need to gush! Turns out Ernie Cline is a huge fan of 80′s era geek stuff – plus he lives in Austin AND drives a Delorian! Just driving a Delorian makes him cool in my eyes. He’s also got a bunch of Ghost Buster stuff that makes the arguably pretty decent costumes I made (back in the 80′s, I should add :−) look like amateur hour.

Who ya Gonna Call?!

In “Ready Player One“, Ernie concocts a future (2044) where deep knowledge of all things 80′s, especially geeky things, becomes suddenly very relevant. Things I geeked out over in the 80′s, like role playing games, early console games,  early PC’s, dial-up BBS’s, 80′s geek movies like Wargames and Monty Python and the Holy Grail, dorky 80′s music like Oingo Boing and Duran Duran…all these things and myriads of other details feature front and center in the plot.

I played D&D! I played those dorky Atari 2600 games! I spent man-weeks  and hundreds of dollars of allowance at Aladan’s Castle playing video games! I had a Tandy Color Computer (still do :−), a Sinclair 1000, a TI-99/4, and an Apple II! (Sadly, I detected no reference to the Commodore Amiga computer line…COME ON, Ernie! ;−) And of course, I’ve seen every movie referenced in the book. While I wasn’t quite as into the esoterica of console games, anime & manga and music as the book’s characters, 90% of the references totally struck home.

I don’t want to spend a long time reviewing the book here – you can read much more comprehensive and well-written reviews on Amazon, but I’ll try to some up the plot briefly, in case reading this can prompt you to buy the book, which you should. Basically, a fictional computer game genius/mogel, James Halliday (now super-rich), has created the worlds most pervasive MMO, the OASIS. Sort of a combination of Second Life, plus every MMO game your can name (World of Warcraft, Everquest, Eve Online, etc., etc.) the OASIS is so pervasive that it has essentially replaced the internet. Play, business, entertainment – it’s all conducted online in OASIS.  Well, when Halliday dies of old age, his will stipulates that the first player to complete a quest wins his fortune ($250B or something like that) and control of the OASIS and it’s parent company. These stakes are huge, so millions of people are hunting for the keys to the quest and brushing up on 80′s esoterica – not to mention some giant clans and at least one powerful, greedy, and downright evil multinational. Since, like the author, Halliday was weened on 80′s geekdom, completing the quest requires substantial knowledge of all things 80′s or geeky, not to mention deep skilz in 80′s console and PC games. The quest is also not without “real-world” jeopardy.

As I’m reading this book, I’m thinking, “man, if done right, this would be a freaking awesome movie.”  Hurrah! – in the afterword, Ernie mentions there was already a big bidding war between some studios over the rights and it looks like Warner Brothers is actually going to make it! The producer seems to be Donald De Line, who also produced Green Lantern, which is a big warning flag, as far as I’m concerned, but at least he has some experience with heavy CG, which would be critical. Also, Ernie wrote the first couple of drafts of the screen play (he also wrote Fan Boys, by the way – you gotta love this guy!) so maybe there is hope. There’s a pretty cool interview with Ernie here. He cops to being a huge Snow Crash fan, by the way – probably my all-time favorite book, and one I would really like to see done well as a movie. Here’s to hoping they don’t make a mess of this one!

GE G35 ColorEffects Christmas Tree (part 2)

I pretty much have the “Mini Mega Tree” and sequencer enhancements all wrapped up. I only got my hands on five 50 bulb strings of G35′s, so my tree isn’t as big as the “original” Mega Tree, but I was able to get 20 lengths of 12 bulbs out of the setup, which made for a decent tree almost 12 feet tall.

I figured it would be a challenge erecting it, so to simplify things a bit, I bought a collapsible painting pole from Lowes for about $15 bucks and screwed a bent-up paint roller onto the end of it to hook the strings over.  

Just for the hell of it, I also got a PVC end cap to keep the pole from sinking into the yard. Since I plan on actually using it to paint with too, I don’t want the handle to fill with dirt and mud.

To get a sense of the circumference the base would have to be, I first laid a string out in a circle. I marked the location of each bulb with a stake. I bought the stakes in the garden center at Lowes and bent the tops in such a way that I could slip the flat wire of the strands into the slot.

I drilled a hole in the handle end, drove a 36″ piece of rebar into the dirt, then slid the handle end of the pole down over it. The rebar kept it upright (in collapsed position) while I looped the strings over the roller bard on the top end.

 I roughly positioned the ground-side ends of the strand lengths and secured them with the stakes I described previously.  Then I got in the middle of the collapsed tree and simply expanded the pole, raising the whole thing to its full height.

Since Part 1, I’ve done quite a bit more coding and worked a number of bugs out of the new plugin for my sequencer which supports driving grids of G35′s. Though not perfect, it’s working pretty well.  There is still a limit to how much data I can pump across the serial port to the Digilent Uno32 Arduino clone (which was necessary to get any speed at all).  If I use bitmaps that require updates to many LEDs, for example, when multiple rows or columns (depending on which way the bitmap is scrolling), it gets bogged down and falls behind.  Nevertheless, I can achieve some really nice patterns and don’t have to custom program each one in “C-like” code or whatever. I think perhaps next year’s project will be to change the way the plugin works. I think I could just download the bitmap to a buffer on the Arduino clone along with some instructions on what to do with it (i.e., scroll in and loop 5 times). This would require a burst of serial data, but less overall. Too much refactoring to do this year, though..it’s going to have to wait!

Anyway, here’s this year’s final product: “Mini Mega Tree”  If you want to try out this latest version of the sequencer, which includes the G35 Grid plugin, you can download it here:  http://practical-apps.com/misc/Sequencer3.4.zip

GE G35 ColorEffects Christmas Tree (part 1)

In a reply to a preview post, Jim pointed out this video of a cool project another guy did using G35 strings and a microcontroller: http://www.youtube.com/watch?v=bPgqNXjf-MY

I’ve been kind of dreading the effort of setting pulling out the scores of strings of lights I normally set up and sequence with my custom relay box. I did a Halloween setup and just finished taking it down. What with having to go out to the piney woods of East Texas for the Thanksgiving holiday and subsequent AustinLightGuy appearances around town in Austin, I just don’t have the energy this year! I was already thinking about doing something that was “big bang, low-effort”, so that post got me thinking.

Now, that MegaTree looks like it would involve a whole lot of micro-controller code, which is pretty time consuming to write, debug, etc.  In fact, writing custom code for all those patterns seems likely to be time-consuming in any language, so I started thinking about whether I could leverage my existing home-grown sequencer. In one respect, it’s not a great fit: it’s basically designed to turn individual “channels” (aka, light strings) on and off, not render what is essentially raster graphics on a grid of bubs. I though about a way to do that easier and maybe still leverage my sequencer in some way.

I came up with something pretty easy..I’m kind of going to “cheat”.  When you think about it, most of those patterns can be achieved by essentially rendering very-lo-res bitmaps to a display grid composed of bulbs. So, if I write some software that just takes bitmaps, “renders” them as commands to individual bulbs, and provides for scrolling the bitmaps in and out, rotating them up, down, left, right, etc., that – when combined with some simple bitmaps I can whip up in a paint program – would come come pretty close.  So that’s what I did.

My sequencer already accommodates dropping a variety of controls onto a sequence channel; on/off spans (which can also be G35 ramp up/down commands for channels mapped to G35 strings), pauses, loops, wave players and X10/Insteon controls.  I made a new one with a property sheet that looks like this:

G35 Sequence Property Sheet

I can specify the bitmap to display, cause it to scroll in or just appear, rotate up/down/left/right any number of times, then scroll out or just disappear. I can drop multiple grid controls back-to-back on a channel and, since I can carefully control the start times, I should be able to keep them pretty well synced with music from a WavePlayer control. Like my single-string G35 driver, this is a tethered solution – EverSequence is written in C# and it talks to an Arduin-compatible microcontroller over a USB serial port. The microcontroller runs a simple program that basically just acts as a protocol converter.

Now having spent a couple of man-days on it, I think it’s working pretty great. I have the same problem I have driving one G35 string with an Arduino…the sketch seems to wind up having timing glitches when it’s reading lots of data from serial and toggling the digital-out pin. This results in “glitchiness”, with bulbs left on..state changes cropped..etc.  But, as with the single-string driver, the screamin-fast chipKit Uno32 from Digilent seems to be totally up to the task. I can drive it at 230,400 baud and it seems to miss nary a command. I think at that rate, it’ll be capable of really decent “frame rates”, even with a 12X24 grid (yeah, my tree will be smaller than that other guy’s – only 24 lengths of 12 lights..or 6 strings). Stay tuned for a follow-up describing the build and final product and a link to the Sequencer.

Driving GE G-35 Light String with Digilent Uno32

Well, Christmas is approaching, so I guess it’s the time of year when I start revisiting projects that abruptly paused around Dec 26th last year.

I guess the thing that has been nagging me the most has been that I never really got my light sequencing software working very well with the GE G-35 light strings, as described a couple posts ago.  It continued to be kind of glitchy, especially when sending a lot of commands in rapid succession, like when doing ramps, fades, etc. Sometimes certain bulbs would be left on when they should have been off, some commands seemed to get ‘dropped’, etc.  I’ve had a suspicion that the cause is one or both of: (a) the signal timing generated by the Arduino “protocol converter” sketch not being perfect, or (b) The Arduino processor speed not being able to keep up with the rate that commands are sent.

Recently, an Arduino-compatible board by Digilent, the Uno32, came to my attention. It claimed to be fully Arduino-compatible, but runs a PIC32 processor at closer to 80MHz. It aslo has more IO pins and memory, but the speed is what interested me. I’m all about spending a few paltry bucks to save time on this accursed hobby, so I ordered one, hoping that just have a faster processor would produce positive results…

…BINGO! The board did have one compatibility problem with my sketch – I guess it doesn’t support the same serial registers, including the one for tweaking the handshaking, but I included that line is desperation, not because I had any evidence it would help.  I commented out the offending line, loaded the sketch (using Digilent’s custom IDE) fired up EverSequence and – sure enough – it works WAY better! Ramps and fades are pretty consistented and there is generally much less ‘glitchiness’.

That said, I still could an occasional bulb left in an inappropriate state. At this point, I still think (a) may be an issue.  I’ve seen a thread or two about the Arduino serial library not being very accurate and people linking more accurate timing libraries (delay_x) to get better results, so I might investigate that.  I kind of suspect I might have trouble getting the delay_x library to work on the Uno32 given the incompatibility I already ran into, so there’s some investigation there that may cause me to put it off indefinitely :-)

You can download the Digilent Uno32 version of EverSequence here.

Synchronized Lights using LabVIEW and Arduino

In late February, I started a new job in a development position at National Instruments. It’s been a pleasure to work at a tech company that actually has a proven business model, is large and stable, yet still has an entrepreneurial feel to it.  Anyway, I’m not there even two weeks, I think, when I start seeing flyers all over the place regarding an Arduino contest.  Basically, NI is developing an Arduino driver for its LabVIEW graphical programming environment, and they’re challenging people to come up with concepts for how to use Arduino/LabVIEW to do something fun or cool.  The top ten submitters win a free Uno and a $50 gift certificate to sparkfun.com.  Fun concepts for Arduino!!?? Seriously, how awesome is that!?

I’d had absolutely zero experience with LabVIEW at that point, but I figured I should be able to pick it up pretty quick (turns out it is very similar, conceptually, to Vignette’s VBiz tool) and whipping together a project where I use LabVIEW to drive the meshed-network light suits should be a shoe-in.  I can always use some $$ to spend at Sparkfun!  So, I ginned up a Powerpoint presentation and submitted it.  Sure enough, I was chosen as one of the ten and was thereby committed to learning LabVIEW.

I’ll update this blog entry shortly with the results of my endeavor.

Since the point of the contest is to generate some excitement about the interface, we’re required to submit a brief video of our project. Mine is here.

GE G-35 Light String Sequencing Hack, part 2

As I mentioned in my last post, this year I heard about the GE ColorEffects G-35 programmable light strings that a lot of people are hacking.  I piggy-backed on work that Robert Quattlebaum (“Darco”) and  Scott Harris have done to create an interface to the GE G-35 Christmas light strings via an Arduino using my light sequencer software, EverSequence.

In order to drive the string from EverSequence, I first had to tap into the data line.  I decided to use a 1/8″ miniplug jack on the string and a miniplug attached to the Arduino. Here is a basic diagram of how I connected them.  

Miniplug jacks typically have three pins. One is for the ground and the other two are normally connected when no plug is inserted. When you insert a plug, the tip is connected to one, and the other becomes disconnected – this permits me to use the built-in controller on the string when the Arduino is not plugged in.

Here are some pics of the actual build.

First, I cut the ground (-) wire coming out of the string’s controller. As described by Robert, this is the wire on the right, when looking at a bulb top-down where the three-conductor cable runs into it. The picture also shows the middle (data) line cut. I slipped short pieces of heat-shrink tubing around the wire ends before soldering them to the jack terminals so that they can be slid over the connection once I solder them. This provides a bit of assurance that things won’t go making contact with things they shouldn’t if terminals get bent or whatever later on.

Next, I connected the side of the data line that goes to the bulbs to the terminal that connects to the plug tip when it is inserted. The side coming from the controller connects to the remaining terminal – the one that connects through when no plug is inserted. I used a wide-diameter piece of heat-shrink around the whole plug assembly. You could also just wrap some electric tape around it or whatever.

Finally, I connected the plug to a fairly long, two-conductor wire that runs to my Arduino.  Originally, I used an Arduino Uno, but I wound up going with a “USB Boarduino” Ardiuno clone from Adafruit. This board is a nicer form factor for a dedicated purpose like this one, it’s pin-compatible with the Arduino, it still has a USB connection for connecting to the PC, and it’s cheaper! I connected the plug’s sleeve to ground and connected the tip to Digital Out pin 4, which is the pin the driver software expects the G-35 data line to be attached to. In the picture, I have already mounted the board in an enclosure, with a hole exposing the USB connector.

Since some people expressed interest in what I was doing,  I finally got around to packaging up a version of EverSequence which includes just the driver plugins for an Arduino-attached G35 string and, as a bonus, the a plain Arduino driving anything you want via digital out pins 2-12. You can download the installer here. It permits unlimited use, and is licensed for free personal user. If you want to redistribute it, use it for commercial purposes, or would like a version that includes the plugins for X10, Insteon, EEIC Ar-16, or Pencom relay controllers contact me. Update: I’m now providing the full version with all device plugins for free download for personal use.  Contact me for commercial licensing or source code.

There’s a fair amount of help available in the app in terms of how to use it, but I’ll go into a bit more detail about the Aduino and G-35 support here.

The plain old Ardiono plugin simply drives pins 2-12 on an Arduino board, turning the corresponding pins on or off as spans activate/deactivate in a running sequence. I actually wrote this plugin to drive my Light Suit and accoutrements (as described in this thread). Pins are mapped to sequence channels in the sequencer.ini file. You can map a sequencer channel to one or more pins on the arduino; typically you would use a one-to-one mapping with eleven channels but I have complex, preexisting sequences that have as many as 24 channels.  I wanted the flexibility to be able to map many-to-one and choose which channel maps to which pin.

In order for the sequencer to communicate with the Arduino, you have to load some driver software (provided in the ArduinoDriver.pde sketch) onto your Arduino. See arduino docs for how to do that. The driver sketch basically listens on the serial port for signals from sequencer sent using a simple protocol I invented.  A similar sketch is provided for the G35 plugin (G35_Driver_ALG.pde) an work similarly. It’s described in more detail in my last post.

In the case of the G35 plugin, at initialization time, it will actually poll the connect Arduino to see if the driver sketch has been loaded on it. If it finds an Arduino, but doesn’t detect the driver it will prompt for whether you want to load the driver sketch to the Arduino and will try to load the sketch if you select “Yes”.  This has not been tested thoroughly, however, so you may have to load it manually.  One thing I’ve noticed is that sometimes it seems to mistakenly think the driver hasn’t been loaded. Usually, shutting down EverSequence, disconnecting and reconnecting the Arduino, then restarting EverSequence makes this go away.

The G35 plugin supports the ability to set start, mid, and end colors in a span, and to adjust the ramp-up and down rates. This is new functionality I added this year for the G-35 and is currently only supported by that plugin.

Note that the G35 functionality is known to be a bit buggy. The Arduino driver is based on work done by Robert and code ported to the Arduino by Scott. When sending commands rapidly and changing intensity levels by more than one, as in the case of ramping colors up and down, the lights become”glitchy”. I’ll probably look at it again for Christmas next year (2011), but for now I just live with it.

If you read Robert’s post, you’ll see that, at startup, the string’s LEDs must be enumerated and given addresses. To do this, you should first power up the string, then power up the Arduino, which should already have the driver sketch loaded. The first thing the sketch will do is enumerate the bulbs, then it will go into “listen mode” and listen for signals from EverSequence.My driver sketch differs from Scott’s in that it assigns the bulbs only addresses 1-5, rather than1-50. This has the advantage of reducing the number of packets that have to be sent (every fifthbulb get’s the same packet) and thus the “glitchiness”. The disadvantage is that, while you can do chaser patters, alternating light patterns, or “all on” patterns, you can’t individually address each bulb. If I can solve the glitchiness, I might change this, although then you’d need a lot more channels in your sequence anyway.

I haven’t done a lot of testing with this packaged version of EverSequence. I can’t guarantee it will work on every system or OS.  I’m running WinXP on a fairly fast, dual-processor box with 2 GB of memory and on a similar laptop. Also, it’s not commercial software (at least, not yet and it definitely has a bug or two that you just have to live with.

Synchronized Control of GE Color Effects G-35 LED Light Strings

Jay discovered this blog entry by a fellow Christmas hacker going by “Darco” the other day and pointed me to it. We both felt the potential for hacking this thing together with an Arduino and my Light Sequencer Program, EverSequence, was pretty cool, so we ran over to Costco and bought two strings each. (Unfortunately, one of Jay’s conked out shortly after he plugged it in and then they were sold out – oh well, he can probably get a new one for half the price next season

Anyway, Darco has reversed engineered the protocol that drives these things and blogged about it.  Another guy, Scott Harris, also ported his Atmel driver code to the Arduino and posted it here.  Well, since I already have my now-much-improved Sequencer driving an Arduino to control the LED’s on my Christmas Light Suit, adding a little support for colors, dimming, and a plugin to control the G35 through an Arduino was not a huge leap.

First, I modified Scott’s code to accept a simple protocol that I will send via USB serial port from the plugin for my Sequencer.  The protocol involves sending 5 bytes in a single command packet to set bulbs at address X to a given intensity:

“.XIRGB“, where:
“.” is ascii period character,
X is a byte representing the light number to address (between 1 and XMAS_LIGHT_COUNT),
I is a byte representing intensity (usually 0xCC), and
RGB are bytes representing red, green and blue intensity levels (between 0×00 and 0x0F)

So, “2E 00 CC 0F 0F 0F” would turn all bulbs assigned an address of 0×00 bright white.  The Arduino code is here.  As specified by the G35 protocol, at startup the bulbs must each be enumerated consecutively and assigned a bulb address. Normally, Darco and Scott’s code assigns addresseses 1-50, but in my case, I want many bulbs to be addressed by one Sequencer channel, so I modified the code a bit.  I set XMAS_LIGHT_COUNT lower – to 5 in my case – which causes the init routine to use addresses 0×00 through 0×04 and assign the same address to every 5th bulb. This way I reduce the number of commands I have to generate, but can still easily produce chaser patterns or turn all bulbs to a given color level with only 5 packets.  I also set the serial port to a high baud rate, 115200kbps, for lots of throughput.

This protocol is easily tested once you load the code into the Arduino by editing a file using a hex editor to put in a 5 byte packet, then using a terminal program like Hyperterminal to send the file to the Arduino. I cut the middle (data) line coming out of the controller on the G35 string and put a earphone jack inline. Then I connected an earphone plug to ground and Digital-Out-4 on the Ardiuno (which the protocol coverter software uses as the out pin).  That way, I can plug the Arduino in and use it – or revert back to the out-of-the-box controller.

Next, I wanted to take advantage of the dimming abilities. To date, EverSequence only supported on/off, since it was only driving relay boards and simple on/off triacs on my light suit, cape and scepters.

Dimming enhancement to EverSequence spans

Fortunately, I’ve kept the code design on this thing relatively clean (after a couple of refactorings), so enhancements like this are not too overwhelmingly difficult. After an evening or two, I had basic dimming support added, with the ability to set a color, and ramp-up and ramp-down rates settable via sliders.  I wrote a new Sequencer driver plugin to talk to the Arduino running the protocol conversion code. This was quite easy, since I’d already written one to talk to the Arduino for the light suit setup.

The biggest enhancement to the code was ramping up or down (dimming). I did this using two .Net System.Timers that fire at (roughly) 25 millisecond intervals during the ramping periods, sending packets with the corresponding intensities. So, for example, a ramp-up that lasts .4 seconds results in 16 packets being sent, each 1 increment brighter. I had some initial trouble getting it to work, until I realized my stupid mistake – a cut and past error had me using no parity, instead of even.  Also, I found that when I had controls on more than one channel firing, the bytes they each sent were getting jumbled up, resulting in completely wacky behavior. That was easily fixed by synchronizing the serial buffer send code, sendBuf(byte[]).  Once that was done, it pretty much worked like a charm! It’s still a bit glitchy, as others have commented generally regarding the G35, but it works more than well enough to have a lot of fun with.

One more enhancement I want to make to the Sequencer is to support “fading down” to a

Running a chaser pattern

color other than black, permitting a cross-fade from one color to another. After that, I’ll post the latest program, as well as my plugin code. Here is video of EverSequence running a simple pattern and driving the string through an Arduino Uno.

Andy Coulson (aka AustinLightGuy)

Meshed Network Light Suit Technical Details (part 4)

OK, it’s finally time to talk about the hardware on this project.  I had originally planned two write one post about software and one about hardware, but I found I had a lot more to describe on the software side. Hopefully my description of the hardware will be more succinct.

In the past, for the light suit I’ve been using a simple light sequencer that I made by getting one of these fancy strings of snowflakes which has a little controller attached to it that flashes in six or eight different patterns. I basically chopped it off and grafted plugs onto the leads into which I could plug strings of LED lights. I power the whole thing with a small power inverter connected to 12v batteries.  Originally I borrowed the lead-acid battery out of the UPS that Grande Cable mounted to my wall, but have recently switched to packs of AA NiMH rechargeables.   AustinLightSidekick has a similar setup, although he uses an off-the-shelf sequencer he got at Home Depot or something which you normally stake in the ground outside to flash your house lights. He still uses a lead-acid battery, which is simpler and less of a hassle, but lots heavier.

As I mentioned at the start of this series, I’m kicking the whole light suit concept up a couple of notches this year – creating a wireless meshed network of device that will flash in synchronization with a sound track. I’ll have a small laptop in a backpack that will play the music via either my EverSequence sequencer program or via Windows Media Player with my custom-written plugin. In either case, as I described last post, signals will be sent over the serial (actually, USB) port to an Ardiuno micro-controller.

The Arduino has 14 digital I/O pins that can be used to control external devices (like Christmas lights :- ). Of the 14, 12 will be usable in my case, since two are shared by the serial send and receive lines. I’ll use four lines to drive my suit, four to drive Sidekick’s, two to drive the Autonomous cape, and two to drive the two new Autonomous Staffs.

Pinout of Master controller, and slaves driving more Triacs boards

In the main controller for my suit, the four Arduino digital out lines 9-12 are wired to opto-isolated triacs, which is what you need to switch 120V current on and off.  Rather than build my own, I just wound up using some nice little controller boards I found here.  The author, Mark Borden, has a whole bunch of them and will sell you some if you email him. Here’s a photo of the assembled results.

Fully assembled Master controller

The eight remaining digital out pins are wired to the digital I/O pins 0 – 7 on an XBee 802.14.5  mesh-networking module. The XBee modules are very cool little self-contained daughter boards the allow you to easily create point-to-point or mesh networks incorporating wirelessly connected nodes.

Calling my light suit setup a mesh network is really a little bit of false advertising. I’m actually using one XBee in broadcast mode on a specific “personal area network” ID (PAN), with others (one in each remote light costume component) listening for broadcasts on the same PAN. Strictly speaking, this is a point-to-multipoint network, since nodes are not forwarding data from other nodes in a peer-to-peer fashion, but mesh network sounds cooler. A good introductory tutorial to XBee modules is here.

Anyway, Arduino pins 2-8 and 13 are wired to pins Digital IO 0-7 on the transmitting XBee module, which I call the “Master”. I added 13 to the scenario near the end, when I realized I didn’t need the CTS pin on the XBee. Pin 12 on the XBee can be configured for CTS_FLOW_CTRL if you’re doing serial data transmission, or can be used as a Digital Out pin. I’m actually configuring the XBees to operate in “virtual wiring” mode, not serial transmissions mode. With “virtual wiring”, you basically configure the XBees such that, when an Input pin’s state changes on the “Master”, the state is transparently transmitted to all the “Slaves”, which then change their corresponding Output pin’s state to match. Since I’m not using the XBees in serial mode, I don’t need CTS_FLOW_CTRL, so I have another pin to play with. I also connected a button to Analog In Pin 0 which controls the ‘mode’ the Arduino runs in (see last post).

For the controller for AustinLightSidekick’s suit, I use another of the Triac boards,

Secondary Suit Controller

but connect it to DIO 0-3 on one of the XBee’s. I actually mounted the Xbee on a Lilypad Xbee breakout board, which has convenient solder pads and an on-board 3v regulator to supply the XBee.

Component view of Autonomous Cape controller

The Autonomous Cape also gets it’s own controller, but I’m only driving it with a couple channels, so I don’t need a full triac board. I also want to keep the controller a little smaller for the cape, so for it, I simply cut out the circuitry for two of the four triacs on one of Mark’s daughter boards and wired them to an XBee daughter board.  Actually, I tried building a two-circuit triac board from scratch (the circuitry is very simple), but for some reason, it didn’t work – it’s posible I blew out the opto-isolators early on by driving too much voltage through them or something. Whatever the issue, I didn’t want to blow a lot of time on it, so I just bought a couple more boards from Mark. I wired the opto-isolator input side to a different break board, an “USB XBee Adapter” kit from Adafruit.com, soldered to some prototype board. That board includes a USB serial adapter, which lets this box double as my XBee programmer.

Xbee driving Staff lights

For the staffs, I once again mounted XBees on a breakout boards, the somewhat simpler (and cheaper) “XBee Adapter Kit” from AdaFruit, soldered to prototype board.  The Xbees are powered by a couple of AA’s in each staff. They’re wired through resistors to a couple of transistors that drive 12V LED strings which are really partial-length strings I cannibalized from a full 120V LED string. The 12V comes

"Plain" Staff

from some little, flat, 3.7V lithium batteries I had around. I wired 3 in series for each staff. Since the 3V and 12V supplies are separate, I have two jacks in each staff for charging.

One staff is “Plain” – it contains just lights and an XBee, the other contains the same light circuitry, plus the Bluetooth Speaker-based sound rig I mentioned in Part 1.  I basically bought one of the cheapest set of Bluetooth speakers I could find, cannibalized it, and mounted the parts in the staff.

Cannibalized Bluetooth speakers

I mounted the circuit board in a plexiglass jar mounted on the top of the staff, and mounted the speakers in the shaft (which reverberates some, making the sound a bit more impressive).

Circuit board housing

The speakers took 3 AA’s originally, but would work on two. Originally, I made the mistake of trying to power the speaker circuitry off the regulated 3V supply provided by the XBee breakout board.

Bluetooth circuitry

I think there was a problem with that configuration, where the power available from the regulator was insufficient. The volume was low, and if I turned it up to high, I think it was starving the Bluetooth circuitry, which would reset. Instead, I connected it in parallel straight to the AA’s and EUREKA! Rocking loud Bluetooth sound coming out of the staff!

Rocking Bluetooth Speaker Staff

I gotta say, the total effect, now that all this stuff is working, is pretty awesome. With two light suits (four light channels each), a Light Cape (two channels), and two Light Staffs (sharing two channels each) all flashing in synchronization with music blasting out of the sound staff, the cumulative effect is pretty impressive.

If you’re in Austin and want to get a glimpse this holiday season, follow me on Twitter @acoulson2000 where I’ll announce appearances of myself and/or AustinLightSidekick in advance.

As Seen on TV!

I use LED Christmas light strings on the AustinLightGuy Light Suit.  The much-lower power requirements of LED strings make them ideal for mobile applications (I want to get around to figuring out a good way to put a few strings on my car this year too They’re still 120V strings, so I have a small Inverter that’s powered by 12V battery packs.

Now, I’m not exactly sure why, but some of the strings on the Light Suit start fading sooner than others as the batteries run down.  I’m pretty sure it has to do with the voltage rating of the individual LEDs and the number of LEDs on a string. Unlike incandescent bulbs, when you hook LEDs up in parallel (which is essentially what you are doing when you connect multiple strings to one socket), current tends to flow through the LED offering the least resistance. In a situation with limited current, as is the case when driving these things using a small 12v-to-120v inverter like I do, this means the current will tend to all go through the string with least resistance. Some of my strings have 50 lights, while others have 70, so I think that is contributing to the problem…that’s my theory anyway, and I don’t want to go into too much detail, since this post is about something completely different. For anyone interested, here’s an article from a fellow Austinite who has clearly spent more time both investigating and writing about the subject than I

So anyway, I have some strings that are under-performing and plan on swapping them out this year.  Now, to date, I have been hot-melt gluing them onto the jumpsuit. I just use a dollop of hot-melt every two or three lights rather than running a continuous bead to embed the string in, since you have to hold it a while while the glue cools. I also don’t want the attachment to be too permanent, precisely because I may have cause to remove one or more strings at some point. The hot-melt approach works pretty good, but constant activity still results in strings working loose from various attach points over time. AustinLightSidekick actually riveted Velcro to his jumpsuit, and has bands of the other side (what do you call that? Velcro male and female? No..I think it’s hook and loop…) wrapped around his light strings, which then stick to the riveted patches. This seemed to hold up pretty well last year, but seems like a lot of work.

Buttoneer

So, in the process of researching EL Wire for my Halloween costume, I came across another option for attaching wire to fabric – the Buttoneer! This thing attaches stuff (a button, or possibly a wire for example) by straddling the object with a little length of plastic and forcing each end through the backing fabric.  Each end of the little plastic doodad has a crossbar – sort of like the plastic thingies that hold the price tag on new clothes. When you load the doodad in, those little tabs sit inside two hollow, needle-like rails which you push through the fabric. Then, when you squeeze the Buttoneer, two little plungers inside the rails push the tabs down, through the fabric.

The little plastic things aren’t super strong, so the jury is out on how well it holds up, but they allow the wires to slide a bit which should reduce the tensions when I move. It also provides for the ability to perform repairs in the field, which could be handy.

This biggest problem is that I only  have about a 50% success rate with the Buttoneer.  I think it’s a combination of the device just not working very well, and the fact that the little plastic doodads are just barely long enough to straddle the wire and penetrate the fabric. You have to load the doodads just right or one end or the other may not get pushed through the fabric – or might get sheared off by the little plungers that push them through the fabric.  Holding it just right and getting a hand on the other side of the fabric to kind of work the fabric up closer to the wire seems to help, but I still get a lot of failures.  I have to give the Buttoneer only a moderate score for this task, and I wouldn’t expect it to work well with buttons at all, except in the case where the button is under only light strain.