In a previous post, I provided an overview of the “next generation” of my Christmas Light Suit (and various ‘peripherals’ 🙂 Really…it’s more like “generation 5 or 6” since the Light Suit has been through very many iterations, starting with just a couple strings of lights powered by a big-ole 12V UPS battery…
By this point, I had an Arduino-powered “Master” controller, which had 3 or 4 simple, pre-programmed sequences I could run, or all-on-or all-off. My suit lights were driven directly by the Arduino through a 4-port triac board, and other pins of the Arduino were connected to an XBee in transmitter, set up in “virtual wiring” mode, so receivers in the Cape, LakewayLightGuy’s suit, and the two Staffs, which had XBee recievers, echoed the pin outputs from the Arduino, effectively syncrhonizing all devices. I experimented a bit with sound-synchronization, but the ambient noise tended to be so high most places we went, it wasn’t really noticeable. There’s a lot more detail starting in this old post.
A big change was moving to ESP8266-based wireless ‘peripherals’ instead of XBee (although I also kept the XBee for now, for backwards compatibility). Although this means there’s a bit of a lag between sampling the octave levels of my sound source and actually getting a signal to the controllers, there are several advantages.
Independently-Addressable RGB LEDS
As I mentioned last post, this year I cranked it all up quite a bit, and it got even more complicated, but ultimately I hope it get’s a bit simpler. For example, Switching from commercial Christmas light strings to strings of WS2811 LED’s meant I had to incorporate a board that supported the WS2812 protocol, but I got rid of the inverter necessary to boost 12V to 120VAC and the Triac board necessary to do the switching. I also get 256 levels each of RGB intensity, addressable per bulb! By the way, WS2811 and WS2812 use the same protocol..just google for many discussions of the difference.
The ESP8266 supports the WS2812 protocol (I originally used this library, but it’s now also available via this online NodeMCU firmware build tool), so I can send RGB bytes of data over WiFi and have multi-color, varying-brightness, synchronized devices. Now, instead of just using XBee “virtual wiring” to echo the on/off state of GPO pins, I send packets of 3 bytes each to set the RGB values of LEDs on synchronized devices. Actually, packets are 4 bytes – I use a one-byte header to ensure receivers are in sync as they read bytes, although I think the UDP packets are received ‘atomically’, so this may not be necessary. Right now, I just send one color, but I could easily make my over-the-air protocol more sophisticated and send longer strings of ‘colors’. Receivers (‘slaves’) can either use PWM to just adjust the intensity of attached LEDs, or use the WS2812 library to send data over a GPO pin to one or more addressable LED’s.
Inexpensive, Prolific Peripheral Devices
Another BIG reason I wanted to get away from XBees – they’re expensive! Like, $20/ea minimum. With ESP-01’s running as low as a couple USD from China, you can build synchronized slave ‘peripherals’, like LED hats and batons, for as little as < $10. I got a few LED novelties from Windy City Novelties and by just adding an ESP-01 a little CR123A lithium battery, a really simple socket, a cheap switch, and wiring an output to the existing LEDs, I can have a synchronized Elf hat, for example. In this case, I just used GPIO2, in PWM mode, wired directly to the existing LED’s in the ornaments of this Elf hat.
ESP-01 wired to existing lights in the ornaments on the Elf hat
One CR123A ran the ESP-01 Elf hat for an entire night!
But since the ESP8266 also supports the WS2812 protocol, by adding a few WS2811’s and wiring GPIO2 as the data pin, I was able to have a multi-color “wand” that pulsed in sequence with other devices.
In the future, I’ll incorporate WS2812’s into more accessories, like Santa hats. I bought a whole strip of them, so on a piece-by piece basis, they are pretty cheap.
It’s also worth noting that my suit itself is now a “slave” – the “master” control unit is completely independent of the suit-driving unit, also built around and ESP8266 (in this case, an ESPToy, which had built-in 3.3V regulation and plenty of GPO pins). This way, I don’t have to carry around as much hardware if I don’t care about sound and synchronized patterns across devices. Or I can even flash the suit unit as a “master” that just does simple (non-sound-responsive) patterns, since the difference between a UDP packet sender or receiver, Access Point or Station, is totally software driven. Here’s a schematic of the suit driver:
Note that this circuit includes a binary-coded rotary switch. I included this specifically so I could load more complex code which can behave differently depending on the switch setting – acting as a slave in one position, or as a master with one of a couple simple pre-programmed patterns in the others.
Using the WS2811’s dropped my power requirement down to 5V, but this introduced it’s own complication – I had to add regulators to drop the voltage down to 5V. Even then, I wound up using TWO regulators, both with heat sinks added to them, and they were still getting excessively hot, as were the packs of 10 AA LiPo’s I was using for power. After the fact, I experimentally tried dropping the battery supply down to 6V and voila! Not only did nothing get hot, the whole suit ran for about an hour an a half on a singe set of 10 batteries (rigged as 2 x 5 in parallel). This is much better, and I’m still not entirely sure why. The Buck regulators I use are supposed to be very efficient, but I suspect that may not be the case under high current draw and maybe as they start getting hot. In any case, for future holidays, I’ll be putting together 6V packs.
Pack of 10 AA LiPo
Laying out strings of WS2811’s
An ESPToy, with two Buck regulators, including two heat sinks each
More on Sound
There are a couple more aspects of the sound circuitry, beyond what I talked about in Part 1, that I should probably mention. Here, again, is a block diagram, and also a schematic, of the “master” controller.
Teensy Audio Adapter schematic
I mentioned that the Teensy was really convenient for the complex audio manipulation I wanted – specifically FFT octave analysis and some audio delay, so that the audio out would be in sync with packets received by the slaves, which lagged by about 1/4 second due to WiFi propagation delay. One snag I ran into was that the RAM on-board the Teensy is only sufficient for an audio delay of about 180ms – I actually needed about 250-300ms. The ADC and DAC pins also require a bit of supporting circuitry – to level-adjust the input voltage of the Analog-In and to smooth the Digital-Out to an analog waveform, respectively. While the inventor offers an Audio Adapter that I believe addresses both the RAM issue and the Input/Output conversions, it would have been yet another board, plus, you still have to solder a RAM chip on to get the expansion and it would have cost another $20 or so, all in. The ADC and DAC example circuitry is provided in the online, graphical, audio patching tool when you choose those nodes. It’s pretty straightforward, so I just built it in myself. I had also corresponded briefly with the owner on his forum and he had suggested adding a RAM chip directly. I wasn’t sure where to start with that, but, upon inspecting the RAM portion of the schematic published for the adapter, I also realized that it’s just an 8 pin chip (available in DIP a package) connected to four pins of the Teensy, plus VCC and Gnd. I just added a DIP socket to my perfboard layout and wired it in – it worked on the first try on my protoboard! All in all, I really like the Teensy/ESP8266 combination, especially for the kind of complex, audio-related code I needed.
Here again is the final “master” assembly, consisting of the Teensy for audio sampling and delay, passing 3-bytes, representing 3 octave ranges, to the ESP8266, which is responsible to communicating with the “slaves”. The Teensy also provides basic I/O pin-based signals to the XBee for backwards-compatibility with my original cape and staffs. and with LakewayLightGuy’s orginal “secondary”, triac-driven suit.
It’s worth pointing out that I did make a minor improvement to the XBee setup. I converted the cape over to an ESP8266 receiver, did some surgery on the 110V lights strings inside it to be many parallel sefments of fewer LEDs in series (about 15), and then used Buck/Boost regulators to boost 12V to 30V, and added a couple of darlington transistors to drive the 30V segments. These I drive via the PWM pins from the XBee, instead of just on/off IO pins. If you look closely at the above schematic, you’ll see I’ve wired both kinds of pins to the Teensy. I also changed the bases of the transistors in the staffs to be driven by the PWM pins from the XBees. So, depending on the software I flash to the Teensy and the configuration I flash to the XBee’s, I can still go with the old, on/off style of synchronized lights and pre-programmed patterns, or I can drive the PWM’s with 1024 levels of brightness, providing a much better “pulsing” responsiveness. That’s a great thing in general about this controller – now that it’s all assembled, it’s largely software configurable!
I’ll conclude this long and rambling blog entry with a link to a little video of the modified cape, along with a modified staff on the left: