Smart Insoles for Realtime Gait Analysis

Work started where the risk was highest. The biggest unknown was the two-device architecture itself, so the project began on Nordic devkits, proving that a primary-secondary insole pair coordinating with a phone could work the way I had designed it on paper before committing any of it to product hardware.

From there, firmware development moved onto the existing product electronics. The hardware redesign came later: once the new boards arrived, the firmware was ported across and extended with the features the new hardware made possible, battery monitoring among them.

The supporting work followed the same design-first discipline. The BLE protocol and its interface documentation were fixed before the BLE implementation began, and the Android test app was then built against that contract rather than alongside a moving target. Over-the-air updates, rollback, diagnostics, and provisioning were all present in the first architecture pass.

The firmware was designed around a continuous sensor and communication pipeline: pressure sensors and IMU, driver layer, acquisition and filtering, sensor fusion, step event detection, then either the BLE data model or the flash session store, and finally the mobile app.

The architecture separated hardware-specific drivers from application logic so sensor handling, BLE communication, power management, session storage, DFU, and device-health features could evolve independently. It also made the primary-secondary roles explicit: the primary insole acted as its own data source and as a gateway for the secondary insole.

The firmware was built on Zephyr through Nordic's nRF Connect SDK. Both the chip family and the RTOS were familiar ground by this point: I had already rebuilt the MTronic motion and light sensor firmware on the nRF52832 and Zephyr, and first proved that low-power Nordic platform on a wearable epilepsy monitor. The nRF52840 here was a step up in memory and connectivity, but the platform underneath was one I already knew well.

On that foundation I built a hardware-watchdog-enforced, event-driven runtime. Interrupt handlers stayed intentionally lean: they captured time-sensitive events and handed deferred processing to Zephyr work queues. Sensor handling, BLE follow-up work, and state transitions ran outside the ISR path, which kept latency-sensitive paths short, reduced timing jitter, and made the firmware easier to reason about as subsystems were added.

The runtime was organized around explicit operating modes rather than a single always-on behavior. Sleep, walking, high-activity streaming, deferred sync, and firmware-update flows each had different power, communication, and storage expectations, and giving each mode its own contract made those expectations enforceable rather than implicit.

Each insole used an array of 8 force sensing resistors to measure plantar pressure. These analog signals were scaled and filtered through op-amp circuitry before being sampled by a high-resolution external ADC. Each insole also carried an ICM-42670 6-axis IMU for motion sensing.

Both pressure and motion data were sampled at 200 Hz and decimated to 100 Hz for analysis, with the rate reduced further in low-activity mode. These numbers mattered more than usual here, because power profiling showed that sensor sampling and onboard analysis, not the radio and not flash, were the dominant consumers in the runtime budget. Battery life depended more on the acquisition path than on anything else.

The firmware did not try to perform every possible calculation. Speed, cadence, deeper gait analysis, and pressure-distribution analysis ran in the mobile app, because nothing about them required embedded hardware. The firmware focused on the work that had to happen close to the sensors: acquisition, fusion, step-event detection, data integrity, and communication. Pressure-matrix data combined with the IMU detected and classified steps, heel strike and toe-off were computed on the device, the IMU's built-in pedometer cross-checked step counts, and the remaining IMU axes fed pose estimation.

Keeping signal conditioning and feature extraction tight to the acquisition path was a habit from earlier biosignal work on the wearable epilepsy monitor, where noisy surface EMG had to be filtered and reduced to features on the device itself before anything left the wearable.

I designed the BLE interface between the insoles and the mobile application: GATT services and characteristics for sensor streaming, device configuration, device health, firmware updates, connection management, left/right coordination, and stored session synchronization. The primary insole represented the pair to the app and acted as a gateway for the secondary, tunneling raw data through when the app needed both feet, and otherwise sending processed results from on-device analysis.

The topology borrowed directly from my work on the Simplifier Gateway, where multiple safety cores and a communication core exchange validated state over IPC in a safety-critical industrial product. The insoles map onto the same shape: peers with explicit roles, carefully synchronized state, and a third party that must always see a coherent picture. The gateway version of the problem was far more extreme in its determinism and durability demands, which made the insole version feel familiar and considerably more forgiving, and the habits of explicit roles and clean recovery behavior carried over directly.

BLE pairing alone could not determine whether a new peer was the smartphone or the secondary insole, so I implemented an application-level authentication and identity layer on top of BLE using a secure key-based approach. Once identity was established, the connection manager could assign phone, primary, and secondary roles correctly even if peers connected in an unexpected order, without tearing down the session and starting over. A stalled peer that failed to complete identification within its window was disconnected rather than left half-connected.

The keys behind that authentication were provisioned per device during production, alongside serial numbers and other factory data. Treating manufacturing as part of the system design, where every unit needs identity, keys, and a test path before it ships, was a lesson carried over from building the production test cabinet that screens every Simplifier Gateway unit before final assembly.

Sensor and derived-data packets carried timestamps and integrity checks so streamed and synchronized records could be interpreted consistently across firmware and app. The transport layer was MTU-aware: rather than assuming a fixed payload size, it adapted to the negotiated MTU of each BLE link so data could move across the primary-secondary-app topology without avoidable fragmentation.

The product could not depend on the mobile app always being connected, so recorded sessions had to survive disconnection. The challenge, established early by power measurement, was that the original flash part drew around 20 mA during writes against roughly 7 mA for BLE transmission.

I attacked that from both sides: the part and the schedule. On the hardware side, I researched low-power flash options, communicated with suppliers, and selected a part with roughly 4 mA active write current, a fifth of the original, after checking it was available long term, practical to source, and straightforward to develop against.

On the firmware side, writes were restructured around RAM buffering: data was batched in memory and committed in efficient, scheduled writes rather than persisted continuously. Live streaming and deferred recording used consistent data formats, and stored sessions carried enough metadata for the app to understand what was pending and resume an interrupted sync cleanly.

The redesign existed because product quality demanded it, and the gaps were concrete. The original design had no battery monitoring at all, and the debug access required so much disassembly that boards could not be live-debugged while being worn. The new revision fixed both, along with measurement quality, user interaction, fault visibility, and mechanical space.

Moving FSR measurement to an external high-resolution ADC improved pressure precision and, just as usefully, freed the MCU's internal analog resources for the battery measurement the product had been missing. A user button added power, reset, pairing, unpairing, and recovery controls. USB serial access and Tag-Connect ECV3 castellated board-edge connectors made development and service workflows practical, including debugging a board inside a worn insole.

Shrinking the PCB won back room for a larger battery, a trade-off between board area and assembly practicality I had worked through before when squeezing the wearable epilepsy monitor down to a roughly 0.5 x 2 inch main PCB.

A fault LED was added with a dead-man-switch behavior: the firmware had to regularly hold the LED off, so if the firmware hung or stopped servicing that mechanism, the LED turned on and the user saw a fault instead of a silently dead device.

Power profiling began with the project itself rather than as a response to problems. The method came from the MTronic motion and light sensor, where pushing battery life from months to years meant measuring the cost of every operation instead of estimating it: profile individual peripherals and features with the nRF Power Profiler Kit 2, then compare those against the complete system cycle.

Because each peripheral and feature had a measured profile, the battery-life impact of algorithm and scheduling choices could be estimated with confidence before committing to them. This is what surfaced that sensor sampling and onboard analysis dominated the budget, and what made the flash-part comparison earlier a calculation rather than a guess.

The mode-driven architecture existed from the first design pass, and profiling is what it was built for: sleep behavior, walking-mode flash recording, high-activity streaming, sync, and firmware-update flows could each be evaluated against the runtime budget they imposed, instead of leaving power as a tuning pass at the end.

Profiling also became part of regression testing, because new features often reduced battery life in ways nobody predicted. Repeated measurement caught those regressions while they were still cheap to fix, and it is how the 14-hour target was met with room to spare.