HRV: default the nightly window to deep sleep, once deep staging holds up against PSG

[ryanbr]

What

NOOP already has a WHOOP-comparable HRV setting, and does not default to it. Both HRV defaults currently sit on the less WHOOP-like, more expensive side.

The two defaults

1. HRV window — WHOLE_NIGHT, where WHOOP uses slow-wave sleep.

HrvWindow (Units.kt) already carries both, and the enum's own doc comments say it plainly:

• WHOLE_NIGHT("whole") — "RMSSD averaged over every 5-min window of the night (NOOP's long-standing value)."
• DEEP_SLEEP("deep") — "RMSSD over DEEP (slow-wave) sleep windows only — comparable to WHOOP's reading."

An unset value resolves to WHOLE_NIGHT, so every install reads on the axis that does not line up with the number people compare against. The Settings copy already tells the user Deep sleep is the one "matching WHOOP", which makes the default the odd choice rather than the safe one.

2. continuousHrvOvernight defaults to false, so continuous capture runs 24/7.

Turning on "Continuous HRV capture" gives an all-day beat-to-beat stream unless the user separately finds and enables "Overnight only". WHOOP publishes no daytime HRV figure at all — its reading is an overnight one — so a 24/7 stream has no official-app analogue, and the setting's own copy says overnight-only "roughly halves the battery cost". The expensive option is the one you get by default.

(continuousHrv itself defaults to false, which is right and should stay.)

Proposed

Keep both configurable; move the defaults to the WHOOP-like side.

• continuousHrvOvernight → default true. Low risk: it only narrows a stream the user has explicitly opted into, matches what WHOOP actually reports, and halves the cost of the opt-in. Existing users who already enabled continuous capture should keep whatever they have set rather than silently narrowing.
• HrvWindow → default DEEP_SLEEP for new installs only. See below.

The part that needs care

Changing the HRV window is not cosmetic: setHrvWindow's own comment notes it "re-scores + re-baselines (the value itself moves)". Flipping the default under existing users would move every HRV number and every baseline built on it, in a direction they did not ask for — the same retroactive-score problem #963 and #983 caused, which is the kind of change that costs trust even when it is more correct.

So: persist the current value explicitly for existing installs on upgrade, and let only fresh installs pick up the new default. That means "default matches WHOOP" applies going forward rather than retroactively. Anyone who wants to move can, and the Settings copy already explains what changes.

Blocker to check first: DEEP_SLEEP pools RMSSD over deep-sleep windows, so it is only as trustworthy as deep-sleep detection. Staging changed in #987, and 5/MG staging is still being worked out. Defaulting to a window that depends on staging quality is only defensible once the benchmark says that staging holds — Tools/SleepPSG scoring the shipped stager against PSG truth is the check that would say so. If deep-sleep detection is not solid on a given strap, whole-night is the more honest default for that strap and the default may need to be family-aware rather than global.

Not in scope here

This does not address the underlying battery cost, which is #1007 — history offload spends ~2.4 h of radio a day regardless of any HRV setting. Narrowing continuous capture to overnight is worth doing on its own merits, but it is not the fix for #1005.

[ryanbr]

Status: half of this shipped in #1019; the other half should stay put, and the blocker now has a number.

Done — continuousHrvOvernight defaults to true. Wired at all three launch sites (NoopApplication.onCreate, StrandApp.init, StrandiOSApp.init) with the upgrade migration pinning existing opted-in users to their current value, plus twin tests on both platforms. Nothing outstanding there.

Not done, and shouldn't be yet — the DEEP_SLEEP window default.

The blocker above was "only defensible once the benchmark says staging holds". Tools/SleepPSG has since scored the shipped recipe against PSG truth over 31 subjects / 26 773 epochs, and it says the opposite:

	predicted	truth	bias
deep, pooled over all scored epochs	18.94 %	13.76 %	+5.18 pp
deep, mean of per-subject percentages	19.24 %	14.76 %	+4.48 pp

Four-class kappa is 0.356. The stager calls roughly 38 % more deep-sleep epochs than exist (pooled).

That matters here specifically, because the Deep window pools RMSSD over deep-stage 5-minute windows taken from NOOP's own staging (AnalyticsEngine.analyzeDay, deepHrvWindow), not from anything the strap reports. So the bias lands directly on the value: a window that is ~38 % over-inclusive pulls the "deep" reading toward the whole-night mean, which is the one thing the setting exists not to be. Defaulting to it would ship a number labelled WHOOP-comparable that is measurably less deep-specific than the label claims.

Two further points the benchmark reinforces rather than settles:

• The per-strap concern in the original text still stands. AnalyticsEngine already notes WHOOP-4.0 staging can be sparse, and chargeDeepWindowGap exists precisely for a night that banks under ~5 minutes of deep sleep and therefore scores no Charge at all. A global default would hand that failure mode to users who never chose the window.
• The over-call cuts against the empty-Charge risk (more predicted deep means fewer nights fall under the 5-minute floor), so the failure this would cause is a quietly wrong number rather than a visible blank. That is the worse of the two.

Leaving the window default as WHOLE_NIGHT. Revisit when the deep bias is inside a few points and kappa is materially better than fair — the benchmark is the gate, and it is now cheap to re-run.

[ryanbr]

One more thing found while checking whether the deep window needs a code fix rather than a doc one.

There is no minimum deep-window count. avgHRVDaily under the Deep window is deep.isEmpty ? nil : mean(deep) on both platforms, so a night with a single 5-minute deep window produces a full nightly HRV — against roughly 90 windows for whole-night. Combined with the +5.18 pp over-call above, one spurious deep window is enough to publish a confident-looking number built from five minutes of R-R.

Not changing it here: any threshold picked now is arbitrary, and raising it re-scores history for everyone already on the Deep window — the same retroactive-score problem this issue already flags. hrv nightSummary already logs nDeep, so the order is measure the distribution first, then set a floor. Worth settling before the default moves, not after.

Also checked and clean, so they don't need re-checking later: the Swift and Kotlin deep-window computations are structurally identical with the same iteration and summation order (no float drift), and the stage == "deep" filter is unambiguous — the stager and both importers agree on that spelling. Only wake has the two-spelling problem, and SleepStageVocabulary already handles it.

[pilleuspulcher-blip]

@ryanbr

Does it mean that Noop now has equal values to Whoop? Up to now (including the last night with the prerelease of 9.3.1) Noop doesn't have values comparable to Whoop or other apps (Polar, Suunto, Huawei) which use the SWS reading. 🤔

[pilleuspulcher-blip]

@ryanbr

9.3.1, Whoop 4, Android 17

The last two nights HRV and RHR differ from the Whoop data (I imported my Whoop history to have the correct personal range of SWS reading) in the way it was from beginning since I started to use Noop.

Deep sleep window and night only are the settings in Noop.

noop-strap-log-260804-0833.txt