Does an unbonded 5/MG stream realtime IMU? If so, an unbondable strap could still get a motion spine

[ryanbr]

On a 5/MG that cannot bond, everything downstream of the handshake is gone:
SET_CLOCK rides the same tail, the strap banks no motion, and SleepStager
says so directly:

A WHOOP 5/MG that cannot bond never banks motion at all, SET_CLOCK rides a
handshake it never completes, so grav is empty, there is no spine, and no
quantity of HR can stage the night (#1801)

A capture from such a strap shows exactly that. Nine consecutive nights, every
one with zero gravity samples against a dense HR series:

sleep-motion day=2026-08-29 grav=0 hr=153615 sparse=false stager=V2 family=whoop5
...
sleep-motion day=2026-09-06 grav=0 hr=168345 sparse=false stager=V2 family=whoop5

A 4.0 on the same nights banks gravity 1:1 with HR (grav=192504 hr=192475).
#1801's HR-only staging is carrying all nine, which is the fallback working as
designed.

The question

Offload is not the only way a 5/MG can produce motion. The strap also has a
REALTIME IMU producer, packet types 43 and 51, driven by START_RAW_DATA +
TOGGLE_IMU_MODE, and both platforms already implement that sequence for the
ground-truth capture.

Nothing in either send gate requires a bond. Android admits those three opcodes
on groundTruthImuCommandAllowed, iOS on rawCaptureInFlight, and neither
consults didBond. The stopUnexpectedRealtimeImu fail-safe exists precisely
because the producer can be left running.

So: does an unbonded 5/MG honour realtime IMU streaming?

If it does, a strap that can never offload motion could still supply a live
motion spine, and HR-only staging would stop being the only option for these
straps.

Why it is open rather than answered

No capture has ever recorded it. The fail-safe has never fired in any log I have
seen, and the ground-truth capture is opt-in, so no default install produces the
evidence either way. This is a hardware question, not a code-reading one.

It is stage 1 of the existing probe, not a separate question

Correcting the framing above, after reading further. The realtime IMU packets
arrive on the SAME puffin notify characteristics the offload does, and on a
normal 5/MG link those are never subscribed at all: only HEART_RATE_CHAR and
BATTERY_CHAR reach cccdQueue. A capture confirms it, showing all four
discovered and only 00002a37 subscribed.

So this is not an independent question. It is stage 1 of UnbondedOffloadProbe,
which already asks exactly the right thing and says so plainly:

subscribe the four puffin notify characteristics. An insufficient-authentication
status here is the whole answer, the offload needs an encrypted link and #1635
is a wall rather than a gate.

If those subscriptions are accepted unbonded, both the offload and a realtime IMU
producer become reachable. If they are refused, both are walled by the same
status code. One measurement settles both.

How to answer it

Opt into the unbonded-offload experiment on an unbonded 5/MG and read the
verdict, which the probe already grades (unbondedProbeSilentLine,
SERVES_NOTIFICATIONS vs ANSWERS_COMMANDS).

The reason no existing capture answers it: the probe is opt-in and had never
been enabled on the strap in question, and the skip was SILENT, so the log looked
the same as a strap refusing. #1950 makes that legible, adding the skip reason
and a pairing dump of what we hold on the link.

If the answer is yes

Then it is a design question, not a decode one, and a real one: 100 Hz 3-axis
for a whole night is a lot of data and real battery cost on both ends, and the
stager wants roughly 1 Hz of gravity. Downsampling at ingest and running it only
while a night is in progress would be the shape to consider. Not proposing that
here, only recording that the door is open.

If the answer is no

Then HR-only staging is the ceiling for an unbondable 5/MG, which is worth
knowing plainly and worth stating on the 5.0/MG status page.

[Zebsi235]

One data point for the "producer can be left running" half, from the MG ECG research work (#1941, #1969):

stopUnexpectedRealtimeImu has fired — not on IMU traffic, but on the type-43 realtime records the ECG gate (139) produces. On 2026-09-06 it saw type-43 frames it did not expect, sent its stop, and the live ECG window ended with it; the engine in the next PR carries an explicit "this producer is expected right now" guard for that reason. So the fail-safe cannot tell the IMU producer from the ECG producer by record type — it is doing its job (an unrequested realtime producer got stopped), but "unexpected IMU" is a narrower reading than what it catches. The left-running case is real too: one lost 139=0 left a strap generating type-43 for ~40 minutes across a disconnect and a reinstall, with the fail-safe silent because the link was down — raised separately.

On the actual question — whether an unbonded 5/MG serves those notifications — no data: this MG bonds. If stage 1 of UnbondedOffloadProbe comes back SERVES_NOTIFICATIONS, the same answer covers the ECG producer.