An interesting renaissance in the last few years has been a resurgence in novelty light-up sneakers. This probably speaks towards both the infantilization of the Millenial and Zoomer generations as much as the proliferation of rave culture in the mainstream, but as an electrical engineer with a fascination in blinking lights I am less interested in the sociology than the technology of this trend. A friend of mine who uses a pair of these for raving was complaining that the lion's share of available options were unideal for dancing for the following reasons:
- They can only be one color at a time
- They can only be toggled via a button on the shoe
- They only have one brightness setting
While I'm sure higher quality options exist that provide solutions to these problems, I thought it might be a fun technical challenge to see what it would take to produce the hardware from the ground up to solve these issues in a cost-effective and technologically robust manner. Which is how I ended up with these wirelessly-controlled, animated prototypes:
This gif just can't handle the boogie
Using this blocky demonstration as a testbed for hardware and software development, I spun custom printed circuit boards (PCBs) with the disparate functionality of my off-the-shelf parts in a more streamlined form factor:
But enough pre-amble. Let's dive into the development process and see the finished product!
Prototyping the Hardware
This project began as some scribbles in my notebook to jot out the general hardware requirements; while much changed since sketching this out a year or so ago, the general principles remain the same:
We need a battery and charging circuit, some form of power regulation to drive the LEDs (and possibly digital logic), and a Bluetooth Low-Energy (BLE) enabled micro-controller to handle the wireless and computational aspects. When scoping out available development hardware, I landed on the following parts based on capability and price:
- Nordic Semiconductor nRF52
- Bluetooth enabled ARM Cortex M4F, this will run the software. For the prototype, we'll use the Adafruit nRF52 Bluefruit Feather
- WS2812 Individually Adressable LEDs
- RGB LEDs that will allow for animations
- TPS61090 5V Boost Converter
- This will provide the 5V power for the LEDs, though the final revision may need a higher-power alternative
- 1200mAh Li-Ion Battery
- This rechargeable battery is among the least expensive available and should provide sufficient capacity
- Some basic toggle switches and buttons for enabling the various functionality
Before purchasing the requisite development boards, I did some quick back-of-envelope math to sanity-check the battery. Each LED is actually three separate channels of Red, Green, and Blue that combine in the eye to form any color:
Well that sounds reasonable enough, two hours is plenty for dancing. With this architecture in mind, I set about ordering the electronics and firing up CAD to make some prototype enclosures per the approximate dimensions of the purchase-list. I ended up with a simple box with some escapements for cabling, screw holes for attachment, and a clip for fixing to a given pair of shoes. The final design looked like this:
I asked my friend to fire up a print for me, and got to work on inventory. Once the parts came together, a quick fit-check showed everything to be in roughly working order. Screws, components, battery, and a USB cable with no major collisions or squeezing:
Look at that fitment
After a few hours of soldering in the lab, the hardware began to come together. Using mostly 30AWG blue wire for the digital connections and 24/28AWG for the power, there was barely enough room for the PCBs and battery without too much jiggling:
Lookin'... pretty tight
After throwing it together and trying to test it out, I saw... some pretty patchy performance. I was able to drive the LEDs and set their colors, but there would be periodic glitches where the lights would be the wrong color, or off, or flashing when supposed to be disabled. Mildly distressed, I fired up my Saleae Logic Analyzer to see what the signal integrity looked like, and was upset to see my poor 3.3V micro-controller was struggling to talk to the 5V LEDs! To be honest, I knew this would probably be a problem, but a lot of hobbyists press onwards regardless and I was curious to see how frequently this would be an issue. Because the power integrity of my little fly-wired mess is substandard, it's not surprising that we're seeing enough voltage drop on these lines to cause the data lines to drop below the threshold. Because the data rates can be quite high (in the 100's of kHz), the data required a push-pull level shifter:
Throwing this bad boy into the circuit fixed all the signal integrity issues, and testing progressed as expected with functionality on display for the first time! Let's take a look:
Level shifter waving there like a little flag
Controlling these boxes from the bluetooth on a computer is one thing – but controlling them while dancing is something else entirely. For that, I opted for a wristband with some buttons to toggle the LEDs. To save money and development time, I decided to use a pared back version of the shoe hardware but with a significantly smaller battery, and some additional buttons to toggle the animation on the shoes. Throwing together some CAD, the following enclosure arose – with mounting holes for buttons, switches, and a watch wristband:
Putting it all together, the hardware came together as seen in the initial demonstration in this post, with two shoes worth of LED driving boxes and a wristband to control them:
What's the software story looking like?
Prototyping the Software
Using the Adafruit development board offered two benefits from the outset – reliable development hardware, and extensive software support. The wonderful folks at Adafruit put together an Arduino bootloader for the nRF52 chipset, which makes writing a great deal of this software a breeze. For a full description, you can check out the Github page, but briefly:
Device acting as BLE remote that scans for the beacon. Ordinarily this pairs with peripherals, but in this case simply scans for advertising packets, extracts the UUID, and if it is a match for its remote, will sync its state. Deployed to any number of synced devices beyond shoes, e.g. LED headphones synced with music.
Device acting as the BLE beacon — pairs with a control phone as a peripheral to set the button states, and then upon button presses will adjust its state and transmit this information via the BLE beacon
minor value. BLE beacon architecture is as follows:
uuid: 16-byte identifier for all devices in a given family (e.g. LED shoes). In this case, the first 8-bytes represent the device family and the second 8-bytes are a unique identifier for this pair.
major: 2-byte device category of paired state (i.e. two shoes, 16 headphones, whatever)
minor: 2-byte system color state
Using the BLE beacon protocol, any number of synchronized devices can listen to a central broadcast and receive small amounts of encoded data in the major and minor registers. Putting it all together, we can control both shoes in a very low-power state from a central beacon on the wristband.
Looking pretty good, but those battery/logic boxes on the shoes are ungainly, and difficult to dance with due to their size and weight. Time for the fun part – let's design a custom PCB to do this in a much smaller form factor.
PCB Schematic Capture, Layout, and Manufacturing
The first step in designing a PCB designing the schematic – there are myriad free/freemium tools for accomplishing this task, and I've tried most of them over the course of my tinkering. While more expensive suites like Altium or Cadence may provide toolchains for more sophisticated hardware, I'm always tickled by how far free software has come; in this case, I elected to use EasyEDA. They offer their design tools for free in exchange for streamlining the process to use a partner component supplier and PCB fabricator; that being said, they allow the export of gerber files so other sources can be used as well.
The schematic is as follows:
These files alongside the layout can be located on Github, in the design files folder. Be generous – I do this for a living but when given the opportunity to be more lax about style conventions, I take it. Notice that instead of the raw nRF52 integrated circuit from Nordic, we have the MDBT42 module from SEEED studios – this is because the module contains the micro controller, front-end module, and antenna required for the bluetooth functionality in an FCC certified package; the most difficult work already done, a rough sketch of the layout followed shortly thereafter with a general flow of data and power flowing from left to right.
Note the lack of particularly small packages – nowadays, passive components like resistors or capacitors can be 01005 or even smaller, meaning 1mmx0.5mm in dimension. This can be prohibitively difficult to assemble without mass production techniques, so I used larger, less space efficient components when possible to save time on assembly later. Using JLCPCB as the fabricator due to a fabulous first-time order deal and their integration with EasyEDA, I ordered 10 pieces of the board with a framed stencil for about $50 USD. They arrived a week or so later, and I set about reaching out to local SMT shops to see if anyone could find time to assemble a few of these for me at a reasonable price. Most prototype houses charge upwards of $500 or $1000 per board at low quantities even for simple boards like mine – this is way out of my budget, so I called around to talk person-to-person and was extremely lucky to find Acme PCB who were able to provide significantly more affordable prices about 20 minutes from where I live. After a teensy snafu
wherein I placed the power button backwards causing interference with the LED strip connector, some quick manual rework led to a beautiful prototype board:
Gotta have that bokeh
As a bonus, I put some big, fat test points on the bottom side:
Remember kids...Always put test points on your boards
This would prove invaluable later for debug and rework purposes, as every piece of prototype hardware comes replete with fun bugs to squash.
Before plugging any of my hardware to something that might destroy it permanently, I proceeded to perform what is affectionately described as "Smoke Testing". For this type of testing the board is plugged in, and if no magic smoke is released the smoke test is passed. While this may sound whimsical and non-scientific, one of the most common mistakes in designing printed circuit board assemblies (PCBAs) is accidentally connecting a power (or any low-impedance net) to ground, thereby shorting out the board and potentially causing damage to a component. Indeed, depending on the quality of PCB manufacturing, these shorts can be lurking simply due to poor fabrication tolerances, so oftentimes smoke testing can begin a the board level – in fact, I did so before sending these boards out but except for the power supply rails, it can be difficult to suss out design problems until the board is fully populated. So here we are:
After ensuring that the power rails came online successfully and the level shifter was doing its magic, one thing became immediately apparent: I screwed up the push-button circuit, which is particularly annoying because it is the only BGA component in my design and therefore notoriously difficult to rework. This push-button signal is necessary as it enables the load switch connecting the battery to the main bus, and activates the 3.3V LDO that powers main logic.
Look ok? Nah, and not just because I didn't break these obviously vital signals out to test points because I was lazy.
I should have brought these signals out to pull-up resistors so I could reconfigure them as I saw fit, but I got lazy and paid for it. Luckily, by shorting this enable pin to the battery rail, we can temporarily put the switch on the battery line (insulated by some hot glue) to connect and disconnect power to the system:
Oof, ugly. But I have some thoughts on a better solution in due course. With this short-term fix implemented and the electronics seemingly in order, it was time to get some software running on these boards. Using the Arduino bootloader provided by Adafruit and a J-Link EDU Mini:
I plugged the cable into my board's SWD connector and gave it a whirl to try and flash the board with a practical bootloader.
Oh no! Well, actually, I just had the cable backwards. When in doubt, flip it out. After flashing, it was pretty simple to set up a working demo of the board using my existing wristband controller and the hardware on-hand, because now the Arduino IDE recognizes my board as one of its own.
Hooray, the integrated system works! This is a much more elegant solution than the blocky prototype of yesteryear. I ordered up some new rocker switches and threw a pull-up resistor between the switch and enable line – voilà, a switch that doesn't need to handle an entire battery's worth of current:
And once again from the top!
The board has been brought up! Time to work on the shoe.
Assembling the Shoe
After buying some incredibly cheap Converse All-Star knockoffs off Amazon:
Hueibbva Superstar? Heck yes.
I enlisted my girlfriend to help me sew some pockets to house the electronics onto the side. Try as I might to finesse these gnarled hands to new seamstress heights, she's significantly better than me and ultimately I'd like these to be more fashion statement than technical oddity. Look at her go:
After a few hours of work and a liberal application of industrial adhesive for the LEDs, we ended up with some finished buckets. Hopefully now the restless populace can go out and dance without having to worry about lame shoes that require leaning down to push buttons. Instead, we have rad kicks with super cool programmable patterns that really "get lit!", as the kids say.
That about wraps it up for this build. The whole project has been an interesting exercise in trying to build hardware from scratch – despite several years of industry experience in designing, manufacturing, and programming low-level electronics, doing so alone highlighted the contributions of my esteemed colleagues and threw a great deal taken for granted into sharp relief. Negotiating with manufacturers and global suppliers, designing for manufacturing with the assembly house, debugging & software bringup, and final assembly – in the past I've been responsible for various aspects of these processes across a variety of products, but it was a fascinating learning experience bringing it all together for a single design.
Check back after Thanksgiving for some rad footage of these kicks in rare shuffling form. Take care and keep dancing, fam.