Smart Insoles for Realtime Gait Analysis

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, BLE data model or flash session store, and mobile app.

The architecture separated hardware-specific drivers from higher-level 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, giving the product a production-grade RTOS foundation for BLE, timers, storage, device drivers, and structured asynchronous work.

I used that foundation to build a hardware-watchdog-enforced, event-driven runtime model. Interrupt handlers stayed intentionally lean: they captured or registered time-sensitive events, then handed deferred processing to Zephyr work queues.

Heavier tasks such as sensor handling, BLE-side follow-up work, deferred state transitions, and other non-interrupt-safe processing were performed outside the ISR path. That kept latency-sensitive interrupt paths short, reduced timing jitter, and made the firmware easier to reason about as more subsystems were added.

The firmware was also 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.

• Hardware drivers isolated from application behavior.
• Sensor processing kept close to acquisition.
• BLE and flash paths treated as separate delivery modes.
• Well-engineered failure paths for graceful degradation.
• Hardware watchdog supervision for forward progress and recovery.
• Lean ISRs with deferred processing through Zephyr work queues.
• Mode-driven runtime control for sleep, walking, streaming, sync, and firmware update flows.

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 the high-resolution external ADC. Each insole also included an ICM-42670 6-axis IMU for motion sensing.

Both pressure and motion data were sampled at 200 Hz and then decimated to 100 Hz for easier analysis. In low-activity mode, the sampling rate was reduced to conserve power.

The edge device did not perform every possible calculation. Speed, cadence, deeper gait analysis, and pressure-distribution analysis were handled by the mobile app because those calculations did not need to run on the embedded hardware itself. 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 plus IMU Z-axis detected and classified steps.
• Heel strike and toe-off were calculated on the device.
• Built-in IMU pedometer confirmed step count and reduced error.
• IMU X-axis and Y-axis measurements helped calculate pose.

I designed the BLE interface between the insoles and the mobile application, including 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 insole. When the app needed raw data from both insoles, the primary insole tunneled the secondary insole data through to the phone. In other cases, the system did the required on-device analysis and sent processed results to the app.

BLE pairing alone was not enough to 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 or were initially treated as the wrong type of peer, without tearing down the session and starting over.

The connection flow also included an authentication timeout. If a smartphone or the secondary insole connected but did not complete the expected identification and confirmation steps within the allowed window, the firmware disconnected the stalled session instead of leaving the system in a half-connected state.

This process was made easier by considering critical characteristics early on.

Sensor and derived-data packets carried timestamps and integrity checks so streamed or synchronized records could be interpreted consistently across firmware and mobile app paths.

The transport layer was also MTU-aware. Rather than assuming a fixed payload size, it adapted to the negotiated MTU of each BLE link so timestamped sensor data, derived metrics, and health records could move across the primary-secondary-app topology without avoidable fragmentation problems.

• Payload formats and binary data structures.
• Expected app behavior and data interpretation.
• Interaction sequences, error handling, and recovery flows.
• Application-level peer authentication and dynamic role resolution.
• Authentication timeout for stalled or invalid sessions.
• MTU-aware packet handling across multiple BLE links.

The product could not depend on the mobile app always being connected. Recorded sessions needed to survive temporary app disconnection, phone unavailability, or BLE interruptions.

Because traditional flash writes were significantly more power-hungry than BLE transmission (~20 mA vs ~7 mA), flash storage had to be designed as a carefully managed recording path rather than a simple always-write fallback.

I evaluated low-power flash options, communicated with suppliers, and checked that selected parts were available long term, practical to source, and straightforward to develop against.

On the firmware side, RAM-to-flash writes were structured to reduce write frequency, batch data efficiently, and avoid unnecessary write cycles while still preserving session integrity.

• Low-power flash with ~4 mA active current selected with supplier and lifecycle considerations.
• RAM buffering used to reduce flash write cycles.
• Power-aware flash writes instead of continuous persistence.
• Live streaming and deferred synchronization coexisting.
• Metadata so the app could understand stored and pending data.

The electronics redesign addressed measurement quality, serviceability, user interaction, fault visibility, debug access, and mechanical space for a larger battery.

The external ADC improved FSR measurement precision while also freeing the MCU's internal analog resources for battery measurement and power-monitoring needs.

The fault LED used a dead-man-switch style firmware behavior. The firmware had to regularly prevent the LED from turning on. If the firmware became stuck or stopped servicing that mechanism, the LED would turn on and give the user a visible fault indication instead of failing silently.

• USB serial access for development and service workflows.
• PCB size reduction for a larger battery.
• External ADC for more precise FSR measurements.
• User button for power, reset, pairing, unpairing, and recovery.
• Tag-Connect ECV3 6-pin castellated board-edge connectors.

Power profiling was done using the nRF Power Profiler Kit 2. I profiled individual peripherals and features, then compared those measurements with the complete system cycle profile.

Because each peripheral and feature had a measured power profile, I could estimate the battery-life impact of different algorithm and scheduling choices with much more confidence. Hardware and software decisions were evaluated against their effect on battery endurance.

Distinct operating modes turned power optimization into an architectural concern rather than a last-minute tuning pass. Sleep behavior, walking-mode flash recording, high-activity live streaming, sync behavior, and firmware-update flows could each be evaluated against the runtime budget they actually imposed.

Regular power profiling became part of regression testing. New features often had the potential to unexpectedly reduce battery life, and repeated profiling helped catch those regressions before they became product problems.

• Sampling and streaming rates checked against power cost.
• Peripheral enable and disable sequences optimized.
• Event frequency tuned based on measured current.
• BLE behavior evaluated through its power profile.