ReviewOS

stacks/wildloop

Compute per-split metrics from GPS (recorder hardcodes HR/cadence/splits to null)

#952
Closed glennmichael123 opened this 9 days ago ·
9 days ago

Problem

useRecorder.stop() always sends heartRateAvg/Max: null, cadence: null, splits: [] regardless of the recorded track. The activity detail page expects splits/HR. A Strava-like app computes per-mile splits (pace + elevation) from the GPS automatically.

Acceptance

  • Compute per-mile/km splits (time, pace, elevation) from the recorded points and persist them.
  • Render splits on the activity detail page.
  • HR/cadence: wire real sensor input or hide until supported.
9 days ago

Fixed in 5961939. The recorder keeps timestamped samples (lat/lng, wall-clock, altitude, moving-seconds) for every GPS point, and computeSplitsFromSamples (pure, in resources/functions/splits.ts) derives per-mile splits from them: pace from moving-time deltas interpolated at the exact mile boundary (a pause mid-mile can't inflate the split, #960), per-mile elevation gain (#953), and a trailing partial ≥0.1 mi normalized to per-mile pace.

Persistence: new activities.splits JSON column; the store action persists (capped at 200 entries), index/show return them parsed, feed hydration passes them through, and the activity detail page's existing splits table now renders real data end-to-end.

HR/cadence: stay null and render as '--' — no sensor source exists yet (Bluetooth HR straps would be a separate feature).

Verified by scripts/verify-activity-quality.ts: a synthetic perfectly-even 2.5 mi climb yields exactly [mile 1 @ 10:00 +100ft, mile 2 @ 10:00 +100ft, mile 3 (partial) @ 10:00 +50ft], pause-immunity holds, and the store→show→index roundtrip returns the same splits.

Sign in to comment on this issue.