BLE Cycling Power meter support

robert commented

2026-08-31 17:25:16 +02:00

(Migrated from git.butzei.de)

Goal

Support a power meter over the standard BLE Cycling Power profile. Unlike cadence this is a genuine addition: a separate profile, its own client and its own derived metrics.

Acceptance criteria

Cycling Power service 0x1818 discovered and connected
Cycling Power Measurement 0x2A63 parsed, including the variable-length flags field
Instantaneous power in watts sent to the watch and shown as a ride data field
3-second rolling average power computed, since raw power is far too jittery to read while riding
Normalised power and average power for the ride computed and shown in the summary
Crank-based cadence taken from the power meter when it supplies it, in preference to a separate CSC sensor
Power written into the recorded GPX
Pairing and calibration flow in the companion, including zero-offset where the meter supports it
Sits behind the same sensor interface as speed and cadence, so dropout handling is shared

Files

companion/.../sensors/CyclingPowerClient.kt
watchapp/src/c/view_ride.c

Notes

The flags field makes this parser materially more involved than CSC - fields are optional and their offsets shift. See docs/DECISIONS.md D16.

## Goal Support a power meter over the standard BLE Cycling Power profile. Unlike cadence this is a genuine addition: a separate profile, its own client and its own derived metrics. ## Acceptance criteria - [ ] Cycling Power service `0x1818` discovered and connected - [ ] `Cycling Power Measurement` `0x2A63` parsed, including the variable-length flags field - [ ] Instantaneous power in watts sent to the watch and shown as a ride data field - [ ] 3-second rolling average power computed, since raw power is far too jittery to read while riding - [ ] Normalised power and average power for the ride computed and shown in the summary - [ ] Crank-based cadence taken from the power meter when it supplies it, in preference to a separate CSC sensor - [ ] Power written into the recorded GPX - [ ] Pairing and calibration flow in the companion, including zero-offset where the meter supports it - [ ] Sits behind the same sensor interface as speed and cadence, so dropout handling is shared ## Files - `companion/.../sensors/CyclingPowerClient.kt` - `watchapp/src/c/view_ride.c` ## Notes The flags field makes this parser materially more involved than CSC - fields are optional and their offsets shift. See docs/DECISIONS.md D16.

robert added a new dependency

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

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

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

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

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

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 from a pull request that will close it,

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

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

robert closed this issue

2026-09-05 17:25:16 +02:00

robert referenced this issue from a commit

2026-09-05 17:25:16 +02:00

Merge pull request 'BLE Cycling Power meter support (issue #50)' (#113) from area/ble-power-meter into main

robert commented

2026-09-05 17:25:32 +02:00

Owner

Closed by PR #113 (merged). Cycling Power Measurement (0x2A63) format verified live against two independent sources -- confirmed three real differences from CSC's layout rather than assuming symmetry: a 2-byte Flags field (not CSC's 1 byte), signed sint16 instantaneous power (a negative reading decodes as negative, tested explicitly, not left to wrap), and Wheel Revolution Data's event-time at 1/2048s resolution vs CSC's 1/1024s (crank data keeps 1/1024s, correctly reused). Decoded: instantaneous power, pedal power balance/reference (no consumer yet, carried through honestly), crank data (feeds a real CrankCadenceTracker since resolution matches CSC). Correctly walked past but did NOT decode wheel revolution data from a power meter -- feeding it through the CSC-tuned WheelSpeedTracker would have silently halved the computed speed given the resolution mismatch; a real bug avoided by cross-checking rather than assuming code reuse was safe.

SensorPermissions reused unchanged, not duplicated. Dropout/reconnect mirrors CscClient's proven structure exactly. NormalizedPowerCalculator and a new Power3sAverage are now genuinely fed live power samples; AvgPowerAccumulator exists with the same honest "no ride orchestrator yet" gap as AvgCadenceAccumulator/AvgHrAccumulator.

Verified for real: :companion:core:test (CyclingPowerMeasurementTest 14, Power3sAverageTest 6, AvgPowerAccumulatorTest 4), :companion:pebble:testDebugUnitTest, :companion:sensors:assembleDebug and :companion:assembleDebug all green. No Bluetooth hardware in this sandbox -- AndroidCyclingPowerClient is compile-verified only, same honest disclosure as #18/#49.

Closed by PR #113 (merged). Cycling Power Measurement (0x2A63) format verified live against two independent sources -- confirmed three real differences from CSC's layout rather than assuming symmetry: a 2-byte Flags field (not CSC's 1 byte), signed sint16 instantaneous power (a negative reading decodes as negative, tested explicitly, not left to wrap), and Wheel Revolution Data's event-time at 1/2048s resolution vs CSC's 1/1024s (crank data keeps 1/1024s, correctly reused). Decoded: instantaneous power, pedal power balance/reference (no consumer yet, carried through honestly), crank data (feeds a real CrankCadenceTracker since resolution matches CSC). Correctly walked past but did NOT decode wheel revolution data from a power meter -- feeding it through the CSC-tuned WheelSpeedTracker would have silently halved the computed speed given the resolution mismatch; a real bug avoided by cross-checking rather than assuming code reuse was safe. SensorPermissions reused unchanged, not duplicated. Dropout/reconnect mirrors CscClient's proven structure exactly. NormalizedPowerCalculator and a new Power3sAverage are now genuinely fed live power samples; AvgPowerAccumulator exists with the same honest "no ride orchestrator yet" gap as AvgCadenceAccumulator/AvgHrAccumulator. Verified for real: :companion:core:test (CyclingPowerMeasurementTest 14, Power3sAverageTest 6, AvgPowerAccumulatorTest 4), :companion:pebble:testDebugUnitTest, :companion:sensors:assembleDebug and :companion:assembleDebug all green. No Bluetooth hardware in this sandbox -- AndroidCyclingPowerClient is compile-verified only, same honest disclosure as #18/#49.

Rows
Columns

BLE Cycling Power meter support #50

Goal

Acceptance criteria

Files

Notes