Spike B: HRM sample period and battery cost on Time 2 #5

New issue

Open

opened 2026-08-31 17:14:34 +02:00 by robert · 0 comments

robert commented

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

(Migrated from git.butzei.de)

Goal

health_service_set_heart_rate_sample_period(1) is a suggestion to the firmware, not a guarantee. Measure what the Time 2 actually delivers before designing the ride view around it.

Acceptance criteria

health_service_metric_accessible(HealthMetricHeartRateBPM, ...) confirmed true on the device
Sample period requested at 1 s; actual HealthEventHeartRateUpdate cadence logged over 30 minutes of wear
Battery drain measured over the same window and compared against idle
Behaviour of HealthMetricHeartRateRawBPM vs the filtered HealthMetricHeartRateBPM compared while cycling
Confirmed that resetting the sample period to 0 on exit actually stops the elevated sampling
Chosen production sample period recorded with its rationale

Notes

Time 2 also exposes HRV via peak-to-peak intervals; note whether that is accessible, for later use.

Update — 2026-08-31: pass/fail targets agreed

This spike now has a bar, not just a measurement (NFR-B1):

The watch must lose no more than 25% of its battery over a 4-hour ride with the HRM at its
production sample period.

If 1 s sampling breaks that budget, the production sample period drops until it fits - 5 s or 10 s
sampling that lasts the whole ride beats 1 s sampling that dies at hour three. Record the drain at
each candidate period so the trade-off is visible rather than guessed.

Update — 2026-08-31: gabbro is the binding battery case

The Pebble Round 2 claims roughly two weeks of standby against the Time 2's thirty days, so the same
25% budget is about twice as demanding in absolute terms — partly offset by there being no HRM to
power. NFR-B1 must be verified on both devices, and gabbro is the one expected to fail first.

The HRM part of this spike applies to emery only.

Update — 2026-09-02: link drain belongs to #4, not here

This issue stays the HRM sample-period and battery curve. The cost of the link — watch drain at
1 Hz with and without map slices — moves to #4, where the transport is already being exercised (D38,
NFR-B5). NFR-B1 is now owned jointly: #5 for the sensor, #4 for the radio.

Update — 2026-09-03: gabbro is in hand and NFR-B1 binds both watches

Both watches are now physically available. NFR-B1 is verified on both emery and gabbro, and
gabbro is the tighter case — this spike therefore measures both, not Time 2 alone. Before
running anything on gabbro, settle D56:
the SDK exposes no platform define for HRM presence, and the gabbro emulator reports heart rate
as accessible, so the only trustworthy check is health_service_metric_accessible(HeartRateBPM) on
the physical Round 2 — which is now possible and takes a minute.

health_service_metric_accessible(HeartRateBPM) run on the physical gabbro — this single
check also resolves D56, whose outcome decides how the Effort page hides heart rate
The 4-hour drain budget measured on gabbro as well as emery

## Goal `health_service_set_heart_rate_sample_period(1)` is a *suggestion* to the firmware, not a guarantee. Measure what the Time 2 actually delivers before designing the ride view around it. ## Acceptance criteria - [ ] `health_service_metric_accessible(HealthMetricHeartRateBPM, ...)` confirmed true on the device - [ ] Sample period requested at 1 s; actual `HealthEventHeartRateUpdate` cadence logged over 30 minutes of wear - [ ] Battery drain measured over the same window and compared against idle - [ ] Behaviour of `HealthMetricHeartRateRawBPM` vs the filtered `HealthMetricHeartRateBPM` compared while cycling - [ ] Confirmed that resetting the sample period to 0 on exit actually stops the elevated sampling - [ ] Chosen production sample period recorded with its rationale ## Notes Time 2 also exposes HRV via peak-to-peak intervals; note whether that is accessible, for later use. ## Update — 2026-08-31: pass/fail targets agreed This spike now has a bar, not just a measurement (NFR-B1): - **The watch must lose no more than 25% of its battery over a 4-hour ride** with the HRM at its production sample period. If 1 s sampling breaks that budget, the production sample period drops until it fits - 5 s or 10 s sampling that lasts the whole ride beats 1 s sampling that dies at hour three. Record the drain at each candidate period so the trade-off is visible rather than guessed. ## Update — 2026-08-31: gabbro is the binding battery case The Pebble Round 2 claims roughly two weeks of standby against the Time 2's thirty days, so the same 25% budget is about twice as demanding in absolute terms — partly offset by there being no HRM to power. NFR-B1 must be verified on **both** devices, and `gabbro` is the one expected to fail first. The HRM part of this spike applies to `emery` only. ## Update — 2026-09-02: link drain belongs to #4, not here This issue stays the HRM sample-period and battery curve. The cost of the *link* — watch drain at 1 Hz with and without map slices — moves to #4, where the transport is already being exercised (D38, NFR-B5). NFR-B1 is now owned jointly: #5 for the sensor, #4 for the radio. ## Update — 2026-09-03: gabbro is in hand and NFR-B1 binds both watches Both watches are now physically available. NFR-B1 is verified on **both** `emery` and `gabbro`, and `gabbro` is the tighter case — this spike therefore measures **both**, not Time 2 alone. Before running anything on `gabbro`, settle [D56](https://git.butzei.de/robert/PedalPebble/src/branch/main/docs/DECISIONS.md): the SDK exposes **no platform define for HRM presence**, and the gabbro emulator reports heart rate as accessible, so the only trustworthy check is `health_service_metric_accessible(HeartRateBPM)` on the physical Round 2 — which is now possible and takes a minute. - [ ] `health_service_metric_accessible(HeartRateBPM)` run on the **physical gabbro** — this single check also resolves D56, whose outcome decides how the Effort page hides heart rate - [ ] The 4-hour drain budget measured on `gabbro` as well as `emery`