Lacetronics

Inspiration

All of us run, and between us we've had shin splints, knee pain and other injuries that kept us off our feet for weeks. Most running injuries build up slowly from small form problems, like favoring one leg, overstriding or letting your cadence collapse as you tire, that you can't feel until it's too late. Running coaches and gait labs can spot these problems, but they're expensive and only give you a snapshot. We wanted something that watches every step you take on every run and tells you what to fix before it turns into an injury.

What it does

Lacetronics are smart running shoes that track your gait in real time. A sensor board on each shoe streams motion data 50 times a second over Bluetooth to a live web dashboard. From those two streams we measure:

Cadence: steps per minute over the last 30 s of running, and whether it drifts between the first and last third of a run.
Ground contact time: how long each foot stays on the ground, per step and per foot.
Favoring one leg: whether one foot spends noticeably longer on the ground than the other.
Step balance: left-to-right vs right-to-left step times, measured on a shared clock across both shoes.
Heel Striking: landing on the heel vs the forefoot, measured by a difference between the front and back sensor on each foot.

The coach turns these into a few short feedback cards. It only reports what the shoes measure reliably, and it never diagnoses. In one of our real test runs it caught a left/right imbalance: the left foot stayed on the ground for 219 ms and the right for 200 ms, so the runner spent about 9% longer on their left leg. The dashboard flagged that live.

There are three coaching levels: beginner, medium and expert. Each level sets its own cadence target (150 / 160 / 165 spm) and how strict the cards are. Because research shows a 5% cadence increase cuts knee load substantially, the coach sets a target 5% above your current cadence and gives you music to hit it:

Spotify playlists at your target BPM, opened with one tap, plus alternatives a few BPM either side.
Built-in, beat-matched music generated live in the browser with Web Audio. Because the beats are synthesized, the tempo can be any exact BPM. Two decks crossfade so the tempo can glide smoothly toward your target without a jarring song change. The music itself becomes the cue: a slightly faster beat pulls your stride up without a word being said.

How we built it

Hardware. Each shoe has its own Arduino UNO Q with a Grove MMA7660 3-axis accelerometer mounted at the front of the shoe and a digital hit sensor at the heel, both running off 3.3 V. The UNO Q is unusual: it pairs an STM32 microcontroller with a Linux computer on the same board, and the Bluetooth radio belongs to the Linux side.

Firmware. Our sketch samples the accelerometer at 50 Hz and catches heel hits in a pin interrupt, so they're timestamped to a few microseconds with a 50 ms debounce. It packs each sample into a 16-byte little-endian packet: a sequence number (so we can count dropped packets), a millisecond timestamp, X/Y/Z acceleration, hit counts, and the microsecond hit time. It only samples while someone is listening.

Bluetooth bridge. The sketch hands packets over the Arduino Router Bridge (a local TCP socket) to a Python service on the board's Linux side. That service registers a Bluetooth LE GATT service directly with BlueZ over D-Bus, with no extra Python packages, and sends notifications. It batches packets every 40 ms (up to 8 per notification) so two shoes can stream to one device without either falling behind. A one-command deploy.sh copies the bridge, installs it as a boot service, works around BlueZ plugin crashes, and flashes the sketch.

Web app. A React + TypeScript + Vite app connects to both shoes directly from Chrome using Web Bluetooth, with no native app needed. It shows live readings and charts per shoe, a shared timeline, and a recorder that exports labeled takes (samples, hits and markers as CSV + JSON) for analysis.

Clock sync. The two boards have independent, drifting clocks. We map each board's clock onto the browser's clock NTP-style, using the smallest arrival-minus-board-time offset over a sliding 20 s window. This also tracks crystal drift, and it lines up the two feet to within a few milliseconds.

Step detection. Every stride has one stance phase where the foot is quietest. Our detector finds that trough of activity (|a − 1 g| plus half the jerk), walks back to the impact that started it, and walks forward to toe-off. Ground contact time is toe-off minus impact. On our imbalance recording it found 40 of 40 steps on each foot.

AI coach. Coaching works in three layers, so the AI never makes up numbers:

Plain code turns packets into metrics. The model never sees raw sensor data.
Per-level rules, written as YAML configs with thresholds grounded in running research, decide which findings fired and rank them.
An agent server uses Claude (Haiku for quick live cues, Sonnet for the end-of-run summary) with structured JSON output to reword the cues for that runner. It uses Moss to retrieve the coaching rules and the runner's past sessions. Every Claude response passes through guardrails: it may only use numbers that appear in the input, stay under the level's word limit, avoid medical diagnosis, and never tell a healthy runner to change their foot strike. If it fails any check or answers too slowly, the rule-based cue is used instead, so a bad generation can never reach the runner.

Testing. We built a simulator that reproduces our exact packet format: 6-bit quantization, ±1.5 g clipping, dropped packets, drifting clocks and Bluetooth delay. We then fitted it to our real recordings. The test suite has 150 tests covering the coach logic, the real recordings, the simulator, the recorder and the server guardrails, and all of them pass. On simulated runs, landing detection hits about 99% precision and recall.

Challenges we ran into

Power. This was our biggest hardware problem. We planned to run each board on a 9 V battery, but the UNO Q runs Linux plus Wi-Fi and Bluetooth and needs 5 V at up to 3 A. On weak power it browns out and reboots in a loop: the startup animation repeats and Bluetooth vanishes. Even most laptop USB ports caused a reboot every 20–30 seconds. We switched to USB-C PD power banks strapped to the shoes. They were bulkier, but they gave us stable power.

Bluetooth on a brand-new board. Sending BLE straight from the sketch never worked: the radio didn't answer, and trying it left the Linux Bluetooth stack without its adapter. So we wrote our own bridge on the Linux side. We also had to work around several other problems:

BlueZ's LE Audio and MIDI plugins crashed the Bluetooth daemon.
A laptop audio service (WirePlumber's BLE MIDI) dropped our connection during setup.
The radio silently stopped advertising after a few minutes.

Syncing two separate boards. Comparing left and right foot timing means two independent clocks have to agree to within milliseconds over Bluetooth, which adds its own variable delay. Our NTP-style offset fitting fixed this without any wire between the shoes.

Real data didn't match our assumptions. Our first step detector looked for impact spikes, and it missed or mistimed many right-foot steps on real runs. About 35% of real samples were clipped at the accelerometer's ±1.5 g limit. The heel sensor turned out to be a knock sensor, not a contact sensor: it fired at push-off or mid-swing, and on only about half of one foot's steps. We rebuilt step detection around the quiet stance phase instead, which held up on the real recordings.

Accomplishments that we're proud of

We built a working wearable that a person can actually run in, and it caught a real 9% left/right imbalance live.
We went from raw sensor data to useful advice: from accelerometer readings to a concrete feedback card and music at your target tempo, all in one weekend.
Two independent shoes stay synced to within a few milliseconds over Bluetooth, from a plain browser, with no app install.
We kept the AI honest. It explains real measurements, it can't invent numbers, and it falls back to tested rules whenever it fails a guardrail.
When the data showed a feature didn't work, we took it out instead of faking it.

What we learned

We learned a lot about gait mechanics: what cadence, ground contact time and foot strike pattern say about injury risk. We also learned that the research is more careful than the internet. Raising cadence about 5% measurably lowers knee load, but there's no evidence that healthy heel-strikers should switch to forefoot running. So our coach reports strike pattern and doesn't coach it.

On the hardware side, we learned how much power a Linux-capable microcontroller really needs, how to run a BLE peripheral from the Linux side of a board, how to mount sensors so they survive impact, and how to clean up noisy, clipped real-world data. Most of all, we learned to check every algorithm against real recordings instead of trusting a simulator built on our own assumptions. We also learned how to turn an AI agent's output into specific, guardrailed coaching instead of generic advice.

What's next for Lacetronics

Custom hardware. Replace the Arduinos and power banks with a custom PCB that has a low-power BLE chip, a full IMU (accelerometer + gyroscope) and a pressure-sensing insole array, small enough to embed directly in the insole of any running shoe. This would make Lacetronics invisible to the runner. It would also give us what we need for reliable heel-strike detection: a pressure sensor under the heel, or an IMU at the heel.
Hardware time sync between the two shoes for sub-millisecond left/right comparisons.
Phone-first and voice cues so runners can leave the laptop at home and hear coaching mid-run.
Long-term trends. Track metrics across weeks of training, so a slowly growing imbalance or late-run cadence collapse gets caught well before it turns into an injury.