[hrv] HRV & Autonomie - value of hrv taken over night

[pilleuspulcher-blip]

NOOP version

8.5.0-staging

Platform

Android

OS version

16

WHOOP strap model

WHOOP 4.0

Where the data is coming from

Live Bluetooth (strap connected)

Test Centre profile

HRV & Autonomic

What happens

Noop takes a hrv reading at some point during the night and displays the value in the morning. Compared to Whoop, Polar, Suunto or Huawei (which take a reading in the first 4 hours of sleep or in the last deep sleep stage - slow wave sleep) the value of Noop is much higher.

I (66 years old) have a baseline of 20 to 35 in the mentioned apps, 45 to 60 in Noop.

I know that the tendency is important, not the value itself. It happens to me that Whoop shows a decrease of hrv, noop an increase and vice versa.

Nevertheless I would prefer a similar reading of hrv in Noop to compare to other apps. We have the option to take a manual hrv reading at every moment on the live screen.

What you expected instead

I would prefer the same time window of taking the hrv value as other apps and Whoop.

Steps to reproduce

noop-strap-log-260709-0940.txt

Strap log

<details><summary>Strap log (last 40 lines, redacted)</summary>


09:24:03  → GET_BATTERY_LEVEL payload=00
09:24:04  [connection] frameTiming type=COMMAND_RESPONSE t=1783581844s
09:24:04  [battery] bank soc=64.5 t=1783581844s
09:24:04  [connection] frameTiming type=REALTIME_DATA t=1783581844s
09:24:33  → TOGGLE_REALTIME_HR payload=01
09:24:34  [connection] frameTiming type=COMMAND_RESPONSE t=1783581874s
09:24:34  [connection] frameTiming type=EVENT t=1783581874s
09:24:34  [connection] frameTiming type=REALTIME_DATA t=1783581874s
09:25:03  → TOGGLE_REALTIME_HR payload=01
09:25:03  → GET_BATTERY_LEVEL payload=00
09:25:04  [connection] frameTiming type=COMMAND_RESPONSE t=1783581904s
09:25:04  [battery] bank soc=64.5 t=1783581904s
09:25:04  [connection] frameTiming type=REALTIME_DATA t=1783581904s
09:25:29  [connection] frameTiming type=EVENT t=1783581929s
09:25:30  [connection] frameTiming type=REALTIME_DATA t=1783581930s
09:25:33  → TOGGLE_REALTIME_HR payload=01
09:25:34  [connection] frameTiming type=COMMAND_RESPONSE t=1783581934s
09:25:34  [connection] frameTiming type=EVENT t=1783581934s
09:25:34  [connection] frameTiming type=REALTIME_DATA t=1783581934s
09:25:43  [display] deviceMetrics size=411x838pt @2.6x sizeClass=n/a/n/a safeArea=t0 b0 l0 r0 dynamicType=1.15 orientation=portrait theme=dark
09:25:44  [display] frameSummary frames=60 mean=13.8ms p95=44.7ms hitches=4 worst=66.4ms threshold=33.0ms
09:25:44  [display] dataVolume dbRows=969073 importedDays=10 workouts=25 lastRenderRows=12
09:25:44  [display] frameSummary frames=60 mean=12.4ms p95=11.4ms hitches=1 worst=77.4ms threshold=33.0ms
09:25:45  [display] frameSummary frames=60 mean=11.8ms p95=11.2ms hitches=1 worst=44.3ms threshold=33.0ms
09:25:46  [display] frameSummary frames=60 mean=12.4ms p95=11.5ms hitches=2 worst=55.3ms threshold=33.0ms
09:25:47  [display] frameSummary frames=60 mean=12.2ms p95=11.1ms hitches=2 worst=44.3ms threshold=33.0ms
09:25:47  [display] frameSummary frames=60 mean=15.1ms p95=22.1ms hitches=2 worst=154.9ms threshold=33.0ms
=== Capture check ===
universal: present (dayOwner day=)
sleep: present (gate run=)
connection: MISSING (clockDrift )
workouts: MISSING (session event=)
display: present (dataVolume dbRows=)
import: MISSING (import parser=)
steps: MISSING (stepsEst )
battery: present (battery series=)
recovery: MISSING (charge score=)
hrv: MISSING (hrv rmssd=)
INCOMPLETE: missing connection, workouts, import, steps, recovery, hrv
bundle ok files=2 report=present meta=present screenshot=present crash=present leaks=0

</details>

Before you submit

• I attached my exported NOOP .zip (not a screenshot of the Live screen). If my bug is a clearly reproducible UI issue I described exactly how to see it instead.
• I attached or pasted a strap log above — or my bug is a clearly reproducible UI issue that doesn't need one (e.g. a typo, a button that does nothing) and I've described exactly how to see it.
• I checked the Troubleshooting guide — especially "history syncs but no data" (most often the strap isn't banking history to flash; charge it to 100% and reconnect).
• I checked the FAQ and — if I'm on a WHOOP 5.0 / MG — the 5.0/MG status page, and this isn't an already-known limit (e.g. SpO₂, or recovery/sleep on the 5/MG).
• I've left out anything personal (strap serial, account email, raw export).

[ryanbr]

Thanks for the detailed report — you're right, and this is expected behaviour rather than a calibration glitch. NOOP has been computing nightly HRV as the whole-night RMSSD mean (across all sleep stages), whereas WHOOP reports HRV from the last slow-wave (deep) sleep window only. Deep-sleep RMSSD runs lower, so a whole-night average reads roughly 1.5–2× higher — exactly the gap you're seeing.

I've just shipped two things for this:

1. Confirm it's the window (optional, but worth a look).
Turn on the HRV capture under Test Centre → HRV, then open your latest night. In the log you'll see a line like:

hrv nightSummary reported=45 wholeNight=45 deepOnly=23 lastSWS=22 nWin=… nDeep=…

deepOnly / lastSWS should line up closely with your WHOOP number, while reported/wholeNight is the higher value NOOP has been showing.

2. Switch to the WHOOP-style window.
Settings → HRV window → Deep sleep. This re-scores your recent nights over the deep-sleep window so the displayed HRV matches the methodology WHOOP uses. The whole-night option stays the default for anyone who prefers it.

Two heads-ups when you flip it:

• Charge recalibrates over the next few nights. The HRV baseline is re-anchored so recovery compares like-for-like (deep vs deep) — it just needs a few nights to settle, same as the "Recalibrate Charge baseline" button.
• Body Age may tick up slightly. It scores HRV against an age norm that's already deep-sleep-based, so the whole-night value was quietly over-crediting it. The deep-sleep number is the more accurate input there.

Let me know what your deepOnly= shows vs WHOOP — if it lines up, that confirms the fix is doing the right thing for your data.