Repository navigation
Proposal: complete WHOOP 5/MG features with Astra-assisted PRs #2580
Description
The problem
WHOOP 5.0/MG has a large installed base and hardware capabilities that are not fully available in NOOP today. MG support remains incomplete across heart specific sensing, live and historical collection, motion, optical data, capability detection and validation.
The result is that users can connect an MG but cannot reliably access the full set of measurements the hardware can produce. Blank, unsupported and experimental states also need clearer separation.
The idea
Create a coordinated WHOOP 5/MG full feature implementation programme, with a bounded sequence of reviewable PRs. OpenAI Astra could assist with repository analysis, implementation, test generation, fixture handling and review preparation, under maintainer review and with real MG hardware validation.
The work should cover:
- Stable MG transport, bonding, reconnect, clock sync and history offload.
- Complete capability detection for MG versus WHOOP 5.0 and firmware versions.
- MG heart functions: ECG/Labrador command sequencing, electrode/contact state, raw and filtered capture, save/offload paths, record decoding, calibration and signal quality.
- Live and historical heart rate, R-R and HRV inputs.
- Optical records, skin temperature, respiration, SpO2 and other fields where the hardware and firmware genuinely provide them.
- IMU, pedometer and workout motion data, including commands 81, 82, 105 and 106 where validated.
- Recovery, sleep and workout analysis based on measured inputs, with unknown or unsupported fields labelled clearly.
- Swift and Kotlin parity, shared fixtures, migrations and user facing capability labels.
First principles of health means preserving raw measurements, timestamps, quality flags and source provenance before deriving scores. It should not mean inventing values or presenting unvalidated estimates as medical facts.
Alternatives considered
Continuing with isolated MG probes leaves transport, storage, analytics and UI gaps disconnected. A coordinated roadmap with small PRs would let each protocol fact and derived metric be reviewed and tested separately.
Additional context
Suggested delivery sequence:
- Capability matrix and MG diagnostic capture.
- Transport and history reliability.
- Heart specific MG capture and decoding.
- Optical, IMU and pedometer completion.
- Cross platform persistence and UI.
- Derived analytics only after raw data validation.
Acceptance criteria:
- Every shipped MG field has a firmware boundary, decoder fixture and provenance.
- Experimental probes remain gated and reversible.
- Real MG captures validate command effects and packet layouts.
- Official WHOOP exports provide comparison data without copying proprietary code or algorithms.
- No unsupported value is silently filled, and no medical claim is made.
Activity
ryanbr commentedon Sep 28, 2026
@danielrossdanielross Thanks for writing this up properly rather than as a one-line ask.
The acceptance criteria are the strongest part and I want to say so before anything else. "Every shipped MG field has a firmware boundary, decoder fixture and provenance", "experimental probes remain gated and reversible", and "no unsupported value is silently filled, and no medical claim is made" are the rules this repository already tries to hold itself to, and it is genuinely useful to see them written down by someone else in the same terms. The sequencing instinct is right too: raw capture and validation before derived analytics, not the other way round.
Three things to settle before this becomes work.
#761 is already this roadmap
You cite it as something this builds on, but #761 opens with "create a single WHOOP 5/MG deep-data roadmap that ties protocol capability, storage, analytics, and UI behavior together" and links eleven threads underneath it. The scope lists are close to the same list. So the useful question is not whether the programme is a good idea, it is what #2580 adds that #761 does not already hold. If the answer is a delivery sequence, that could be a comment on #761 rather than a second umbrella beside it. Two umbrellas over the same threads tends to mean neither gets closed.
Two of the headline items are gated by the strap, not by missing code
This is the part I would most want you to have before spending effort.
ECG. #891 is a null result with an ambiguous cause: all three
TOGGLE_LABRADOR_*commands return SUCCESS on a WHOOP 5 MG and produce no data at all, and the reporter lists six hypotheses they cannot distinguish alone. "ECG/Labrador command sequencing" reads in your list like something to implement. It is currently something to explain. #1969 is open and admits the four probe opcodes behind a send gate that stays shut, which is the right shape of step while the cause is unknown, and it does not assume the answer.Transport, bonding and history offload. #1635 is HCI-confirmed: the strap refuses SMP with
0x05, so a bond cannot be formed, and "Live HR not fully paired" is the designed end state rather than a defect. A strap log taken this morning on 11.8.0 shows the same thing on a live MG:bond=BOND_NONE didBond=false, CLIENT_HELLO suppressed because the strap never acknowledges it and the write itself drops the link, andBackfill: deferred - connect handshake not done yet. The same install had never persisted a single history row while streaming live HR and R-R perfectly well all day. No amount of implementation bonds a strap that declines to bond, so "stable MG bonding and history offload" is not a deliverable anyone can accept against today.That does not make the programme pointless. It means the two items most likely to be picked first are the two least likely to move, and a plan that leads with them will read as stalled when the strap is what stalled.
The provenance control needs to be concrete
You say "without copying proprietary code or algorithms", and that is the right line. The practical question is how a reviewer would know.
This repository's protocol work runs on clean-room FACT citation: a decode fact may be cited from another project, the expression may not, and every such decoder says so at the point of use. NOOP's own history is not clean-room in origin, which is exactly why that discipline is enforced now rather than assumed. A model generating decoders from training data is the case where expression can come back in without anyone intending it, and a reviewer reading a plausible decoder cannot tell by looking.
So: what is the check? A concrete answer might be that every generated decoder cites the capture or fixture each field was derived from, that no decoder is accepted without a real MG capture it reproduces, and that anything matching a known third-party implementation is rejected on sight rather than argued about. I am raising it as something to specify, not as a reason to say no.
What I would suggest instead
Pick one bounded item from #761 and do it end to end: a capability matrix and MG diagnostic capture, which is your own step 1, is a good candidate because it needs no new protocol facts and its output tells the next step what is actually reachable. A single reviewable PR with a real MG capture behind it is worth more here than a programme, and it establishes the working relationship that a larger effort would need anyway.
If you have an MG and can run captures, that alone is scarce and valuable: #891 is stuck precisely because one person's hardware cannot separate its six hypotheses.