HR not displaying while band is active

[Jenssaibe]

NOOP version

8.5.2

Platform

iOS

OS version

iOS 26.5

WHOOP strap model

WHOOP 4.0

Where the data is coming from

Live Bluetooth (strap connected)

Test Centre profile

Connection & Sync

What happens

Noop is not displaying and live HR althought my band is connected.

By the way, log are saying that banked data is AHEAD in time.

noop-master-iOS-v8.5.2-260709-1829.zip
noop-connection-iOS-v8.5.2-260709-1832.zip

What you expected instead

Live HR showing.

Steps to reproduce

1. Connect band
2. open live console

Strap log

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).

[digitalerdude]

Traced this via the connection log export attached above. The actual mechanism: Realtime HR toggles off/on every 10-40s all session, each cycle paired with a fresh backfill session start — live REALTIME_DATA frames only showed up in the last ~10s of the whole 9-minute capture. The strap's RTC was reading 7868h-28445h ahead of wall clock throughout (the known #928 fault).

beginBackfill() itself never touches realtime HR — the toggle pairing comes from the once-per-connection BLE handshake, so its frequency points at the link itself reconnecting that often, most plausibly the existing #80 marginal-radio loop (its ~20s window matches), aggravated by realtime + historical-offload traffic competing for the same link.

Opened a partial, safe mitigation: digitalerdude#11 — feeds the already-tracked future-dated-clock signal into BackfillPolicy's rate limiter so a known-bogus-clock strap's automatic retries back off (mirroring how the existing empty-streak backoff works), reducing redundant BLE traffic on every reconnect. This does NOT fix the reconnect churn itself — that's deeper BLE radio-arbitration behavior that needs real-hardware verification I can't do here. Flagging clearly in the PR that it needs testing on a real WHOOP 4.0 before merge.

[ryanbr]

Reopening after merging #170.

#170 lands the retry-throttling half of this: a strap with a future-dated RTC (#928/#1012) now backs off its automatic .strap/.periodic backfill retries instead of re-attempting every 10–40s and competing with realtime HR streaming for the link. That should reduce the airtime contention, but it does not address the deeper cause — the BLE reconnect / radio-arbitration churn itself (a #80-style marginal-radio loop) that leaves live REALTIME_DATA frames only trickling in.

Keeping this open to track that root cause ("HR not displaying while the band is active"). Investigating the reconnect/arbitration side next.

[ryanbr]

Root cause traced.

Live HR is armed on a WHOOP 4.0 by periodically re-sending TOGGLE_REALTIME_HR — the firmware lets the realtime stream lapse unless it's re-armed, which is the job of the 30s keep-alive. But that re-arm sits behind guard !backfilling in BLEManager.keepAliveFire() (BLEManager.swift:2199 — "never poke the strap mid-offload"). So while any backfill session holds the link, realtime HR is never re-armed.

On your strap the RTC reads future-dated, which made .strap/.periodic backfill re-trigger constantly (every 10–40s in your log). That kept backfilling == true almost continuously → the keep-alive kept bailing at the guard → realtime HR lapsed and never recovered. That's exactly why REALTIME_DATA only showed up in the last ~10s of your capture (the brief moments backfill went idle).

Two fixes now in flight:

• Backfill: back off retries for a strap with a future-dated clock (#160) #170 (merged) — throttles the future-clock backfill retries, which alone should give the keep-alive room to re-arm live HR again.
• Backfill: skip (not just throttle) automatic offloads for a future-clock strap (#160) #196 (open) — goes further: skips the recurring automatic offloads entirely for a known future-dated strap, so they stop holding the link at all. A one-pass-per-connection sync still runs (so a corrected clock is picked back up).

Could you retest on the next build once these land and report back whether live HR shows? Separately, if you can get your strap's clock corrected (it's reading ~hours ahead), that removes the trigger entirely. Keeping this open until you confirm.

[Jenssaibe]

Ok will try. Thanks.

How can I correct strap clock ?