Sprint athletes have no reliable way to check pace mid-rep without breaking form. GPS watches lag too much at sprint distances and require glancing down; foot pods like Stryd only report after the run is over. GhostPace is a prototype system I designed and built to close that gap: a foot-mounted IMU detects steps, an Android app computes pacing in real time, and smart glasses display a simple eyes-up indicator of whether the athlete is ahead of or behind target pace.
Foot pod: Adafruit Feather Sense (6-axis IMU), BLE, threshold-crossing step detection at ~100 Hz sampling
Middleware: Android app managing dual simultaneous BLE connections (foot pod + glasses), all pacing computation on-device
Display: ActiveLook smart glasses rendering a 3-segment-per-side "ghost bar" HUD
Validation: 49 ms mean step-detection error vs. video ground truth; correct pacing direction across validated 200m reps
Step detection
Wrote the foot pod firmware to detect strikes via threshold-crossing on the lateral accelerometer axis, with a minimum step interval to prevent double-counting. Tuned the 50 m/s² threshold and 500 ms interval empirically against slow-motion video, landing on 49 ms mean timing error.
Calibration system
Distance is estimated as step count × stride length, so I built a calibration workflow that lets an athlete run a known distance to compute stride length, then save it as a named profile. Validating this across three effort levels confirmed stride length is meaningfully pace-dependent (3.08 m easy vs. 3.45 m race pace). A fixed stride length would have introduced real error, which shaped the decision to build multi-profile calibration instead of a single hardcoded value.
Ghost bar Algorithm
Every step packet triggers a four-step computation: distance covered → distance remaining → current speed (rolling 8-stride window) → projected time delta vs. target. The result maps to 0–3 illuminated segments on either side of a center reference, activating only after 7 seconds into the rep to let the speed estimate stabilize.
Android application
Built the full app on the ActiveLook SDK and Android BLE stack, managing two simultaneous BLE connections (foot pod inbound, glasses outbound) on one device.
Directional accuracy held across validated reps, and the one discrepancy I found (a 0.9s-slow rep read as "ahead of pace") was diagnosable directly from the data. It traced cleanly back to the fixed-stride-length assumption, not a bug, which is exactly the kind of signal that's shaping the next iteration: replacing the fixed calibration with a dynamic Kalman-filter-based stride estimate using the 6-axis data I'm already logging.