robert/PedalPebble

Watch

Fork 0

Speed-source arbitration and GPS quality reporting #19

New issue

Closed

opened 2026-08-31 17:14:41 +02:00 by robert · 1 comment

robert commented

2026-08-31 17:14:41 +02:00

(Migrated from git.butzei.de)

Goal

Pick the best available speed source and tell the watch which one is live.

Acceptance criteria

Wheel sensor preferred when it has reported within the last 3 s, GPS otherwise
SPEED_SOURCE sent to the watch: 0 none, 1 GPS, 2 wheel sensor
GPS_QUALITY derived from fix accuracy and age, 0-3
Switching sources does not produce a visible jump or a distance discontinuity
With no source at all the watch shows a clear no-signal state rather than a stale number

Files

companion/.../location/SpeedSourceArbiter.kt

## Goal Pick the best available speed source and tell the watch which one is live. ## Acceptance criteria - [ ] Wheel sensor preferred when it has reported within the last 3 s, GPS otherwise - [ ] `SPEED_SOURCE` sent to the watch: 0 none, 1 GPS, 2 wheel sensor - [ ] `GPS_QUALITY` derived from fix accuracy and age, 0-3 - [ ] Switching sources does not produce a visible jump or a distance discontinuity - [ ] With no source at all the watch shows a clear no-signal state rather than a stale number ## Files - `companion/.../location/SpeedSourceArbiter.kt`

robert added a new dependency

2026-09-03 19:01:17 +02:00

#17 Speed pipeline: smoothing, stop clamping, distance, moving average

robert added a new dependency

2026-09-03 19:01:17 +02:00

#18 BLE CSC wheel sensor client and wheel-circumference calibration

robert added a new dependency

2026-09-03 19:01:27 +02:00

#65 Derived metric producers: max speed, average HR, average cadence, normalised power

robert referenced this issue from a commit

2026-09-04 19:38:13 +02:00

Implement BLE CSC wheel sensor client and wheel-circumference calibration (#18)

robert referenced this issue

2026-09-04 19:38:38 +02:00

BLE CSC wheel sensor client and wheel-circumference calibration (#18) #99

robert referenced this issue

2026-09-04 19:39:58 +02:00

BLE CSC wheel sensor client and wheel-circumference calibration #18

robert referenced this issue from a commit

2026-09-04 20:07:44 +02:00

Speed pipeline: accuracy gate, smoothing, distance, GPS fix wiring (#17)

robert referenced this issue

2026-09-04 20:08:08 +02:00

Speed pipeline: smoothing, stop clamping, distance, moving average (#17) #101

robert referenced this issue from a commit

2026-09-04 20:22:31 +02:00

Speed-source arbitration and GPS quality reporting (#19)

robert referenced this issue from a pull request that will close it,

2026-09-04 20:23:16 +02:00

Speed-source arbitration and GPS quality reporting (#19) #102

robert closed this issue

2026-09-04 20:24:12 +02:00

robert referenced this issue from a commit

2026-09-04 20:24:12 +02:00

Merge pull request 'Speed-source arbitration and GPS quality reporting (#19)' (#102) from area/speed-source-arbitration into main

robert commented

2026-09-04 20:24:24 +02:00

Owner

Closed by PR #102 (merged): resolved the 3s-vs-5s wheel-live-window discrepancy properly \u2014 traced back to D4's original 3s wording, which #69 quietly diverged from with an unreasoned 5s default; corrected to 3s, amended D35 transparently rather than silently. SPEED_SOURCE/GPS_QUALITY wire keys already existed from #7 with matching numbering, no reconciliation needed there. New deriveGpsQuality() (accuracy tier vs. age tier, worse-of) and a SpeedReport.Live/NoSignal type so a dead source reports honestly instead of freezing the last value (D44 principle).\n\nReal bug caught and fixed: onGpsFix's accuracy gate ran before the wheel-live check, so a poor-accuracy fix arriving while the wheel was live got rejected outright instead of refreshing the position baseline \u2014 a sustained bad patch (bridge, urban canyon) with a wheel sensor also live left the baseline stale, and the next good fix after the wheel quieted computed distance against it, producing an unbounded spike. Fixed by checking wheel-liveness first; proven with a regression test (~50m expected vs. the ~95m the bug produced).\n\nVerified for real: :companion:core:test (19+6 new tests), :companion:pebble:test (6 new), :companion:assembleDebug \u2014 all green.

Closed by PR #102 (merged): resolved the 3s-vs-5s wheel-live-window discrepancy properly \u2014 traced back to D4's original 3s wording, which #69 quietly diverged from with an unreasoned 5s default; corrected to 3s, amended D35 transparently rather than silently. SPEED_SOURCE/GPS_QUALITY wire keys already existed from #7 with matching numbering, no reconciliation needed there. New deriveGpsQuality() (accuracy tier vs. age tier, worse-of) and a SpeedReport.Live/NoSignal type so a dead source reports honestly instead of freezing the last value (D44 principle).\n\n**Real bug caught and fixed**: onGpsFix's accuracy gate ran before the wheel-live check, so a poor-accuracy fix arriving while the wheel was live got rejected outright instead of refreshing the position baseline \u2014 a sustained bad patch (bridge, urban canyon) with a wheel sensor also live left the baseline stale, and the next good fix after the wheel quieted computed distance against it, producing an unbounded spike. Fixed by checking wheel-liveness first; proven with a regression test (~50m expected vs. the ~95m the bug produced).\n\nVerified for real: :companion:core:test (19+6 new tests), :companion:pebble:test (6 new), :companion:assembleDebug \u2014 all green.

robert referenced this issue from a commit

2026-09-04 20:41:54 +02:00

Add derived-metric producers: MAX_SPEED, AVG_HR, HR_ZONE, AVG_CADENCE, NORM_POWER (#65)

robert referenced this issue

2026-09-04 20:42:21 +02:00

Derived metric producers: MAX_SPEED, AVG_HR, HR_ZONE, AVG_CADENCE, NORM_POWER (#65) #104

robert referenced this issue from a commit

2026-09-05 17:23:21 +02:00

BLE Cycling Power meter support (issue #50)

robert referenced this issue

2026-09-05 17:23:58 +02:00

BLE Cycling Power meter support (issue #50) #113