Sync takes "ages" and some errors in the strap log I don't understand

[Geg0r]

NOOP version

11.8.0

Platform

iOS

OS version

27.0

WHOOP strap / Oura ring model

WHOOP 4.0

Where the data is coming from

Live Bluetooth (WHOOP strap connected)

Test Centre profile

Not a test-mode bug

What happens

I had a 23h back fill running this morning and the sync took ages.

After a successfull back fill I have checked the log and saw some errors and strange messages from the strap I don't understand.

===== current app session ===== strap: j ,4 � reported, error code 0x05, extra info 0x00 29, 4 strap: j ,4 �015493984: CAPSENSE: Error reported while processi strap: j ,4 �ng command 29, 4015493987: IQS7223B: INFO - RDY l strap: j I4 �ine already low. 29, 4015511290: SUPERVISOR: SOC strap: j I4 �report: 43.10 29, 4015517055: IQS7223B: Error rep strap: j I4 �orted, error code 0x05, extra info 0x00 29, 40155 strap: j I4 �17055: CAPSENSE: Error reported while processing c strap: j I4 �ommand 29, 4015517057: IQS7223B: INFO - RDY line strap: j I4 �already low. 29, 4015518977: IQS7223B: Error repo strap: j I4 �rted, error code 0x05, extra info 0x00 29, 401551 strap: j I4 �8978: CAPSENSE: Error reported while processing co strap: j I4 �mmand 29, 4015518980: IQS7223B: INFO - RDY line a strap: j@�4 �lready low. 29, 4015528591: IQS7223B: Error repor strap: jH�4 �ted, error code 0x05, extra info 0x00 29, 4015528 strap: jH�4 �591: CAPSENSE: Error reported while processing com strap: jH�4 �mand 29, 4015528593: IQS7223B: INFO - RDY line al [07:59:37] Backfill: hist clock chunk=267 offset=+1s staleGate=closed rr=33 secs=32 pack=1.03 max=2 span=38s dens=0.87 [07:59:37] → Historical Data Result payload=013bba000033000000 strap: j �4 �ready low. 29, 4015549739: IQS7223B: Error report strap: j �4 �ed, error code 0x05, extra info 0x00 29, 40155497 strap: j �4 �40: CAPSENSE: Error reported while processing comm strap: j �4 �and 29, 4015549742: IQS7223B: INFO - RDY line alr strap: j �4 �eady low. 29, 4015551662: IQS7223B: Error reporte strap: j �4 �d, error code 0x05, extra info 0x00 29, 401555166 strap: j �4 �2: CAPSENSE: Error reported while processing comma strap: j �4 �nd 29, 4015551665: IQS7223B: INFO - RDY line alre strap: j �4 �ady low. 29, 4015553585: IQS7223B: Error reported strap: j �4 �, error code 0x05, extra info 0x00 29, 4015553585 strap: j �4 �: CAPSENSE: Error reported while processing comman strap: j �4 �d 29, 4015553588: IQS7223B: INFO - RDY line alrea [07:59:38] Backfill: hist clock chunk=268 offset=+1s staleGate=closed rr=33 secs=32 pack=1.03 max=2 span=38s dens=0.87

Maybe worth checking by you @ryanbr?!

Thanks in advance.

What you expected instead

Faster sync and no errors in the log

Steps to reproduce

1. Wake the phone in the morning, have the strap on close by
2. Fast sync of historical data

noop-strap-log-260922-0801.zip
noop-strap-log-260922-0806.zip

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, or — if I'm on an Oura ring — the Oura ring support table, and this isn't an already-known limit (e.g. SpO₂, recovery/sleep on the 5/MG, or no Recovery / HRV on a ring-only day).
• I've left out anything personal (strap serial, account email, raw export).

[ryanbr]

Thanks for the logs, and for attaching both. They answer this, and your two complaints turn out to be one thing rather than two.

The messages are your strap talking, not NOOP

IQS7223B is the capacitive-sensing chip the strap uses to tell whether it is on your wrist. The triad repeating through your log is its own firmware narrating a problem to itself:

IQS7223B: Error reported, error code 0x05, extra info 0x00
CAPSENSE: Error reported while processing command
IQS7223B: INFO - RDY line already low.

NOOP does not generate any of that; it only echoes what the strap sends. So nothing you did caused it and nothing in the app is failing there.

But they are very likely why the sync took ages

That is the part worth having. Your strap's console output is 2,148 of 6,783 lines (32%) of the active session in the 08:01 log, and 5,087 of 11,640 (44%) in the 08:06 one. That chatter shares the radio with the history transfer.

The offload has a 60-second inactivity watchdog, and the code's own note says why it is set that high: a raw console flood "eats BLE airtime, so genuine offload frames can arrive in bursts with multi-second lulls between chunks". With this much chatter the lulls get long enough to trip it anyway. In the 08:01 log the session ended on reason=timeout six times, and in the 08:06 log four more. Two of those restarts transferred nothing at all before timing out again.

So the shape of your morning was not one slow sync. It was a sync that kept being cut off and restarted.

How fast it actually goes when it is running

Between 07:25 and 07:59 the gap to the strap went from 73,356 seconds to 503, so roughly 20.4 hours of history moved in about 34 minutes of wall time, near 36x real time. That is the known protocol cost for a 4.0: NOOP pulls history record by record because the bulk-transfer command has not been reverse engineered, where the official app moves a day in a minute or three. The restarts sit on top of that and make it worse.

One thing that IS ours

The reason those strap messages look like gibberish, with j ,4 and stray control characters, and start mid-word:

strap: j ,4 ^A015493984: CAPSENSE: Error reported while processi
strap: j ,4 ^Ang command

That is a decoding bug on our side: the 4.0 console decoder starts the text six bytes early, so every line carries a few raw header bytes and the text is cut where the frames were chunked rather than where the sentences end. The content is fine; the rendering is not. Yours is the second device to show it, which is useful, because I have been unable to fix it properly without a raw capture of the frames rather than their decoded output.

If you are willing: Test Centre, turn raw capture on, leave it for one session that includes a history sync, then export and attach as you did here. The export redaction covers Bluetooth addresses and strap serials. That would let me correct the decoder against the actual frame layout instead of guessing at it.

What I cannot tell you yet

Whether your strap's capsense error rate is unusual. I have no healthy-4.0 log to compare against, so I do not know if this triad appears on every 4.0 at some rate or whether yours is noisier than most. If any other 4.0 owner reading this can say whether their log carries the same IQS7223B / CAPSENSE lines, that would settle it quickly, and it decides whether this is a strap-specific fault or something every 4.0 pays.

[ryanbr]

Correction to my own comment above, on its main point. I read the timeouts wrong.

reason=timeout is how a WHOOP 4.0 normally ends a productive offload. The strap simply goes quiet when it has handed over the chunk it was working on, rather than sending an explicit completion, and the codebase says so in as many words: a field log shows a session banking 17,205 rows across a night and still exiting reason=timeout. I treated six timeouts as six interruptions. They were not.

Your own sessions say the same thing, on the line immediately after each one:

07:25:10  reason=timeout   ->  persisted  56,879 rows
07:42:05  reason=timeout   ->  persisted 183,266 rows
07:46:18  reason=timeout   ->  persisted  37,645 rows
07:47:19  reason=timeout   ->  persisted      74 rows
07:48:19  reason=timeout   ->  (nothing)
07:55:29  reason=timeout   ->  persisted  40,386 rows

Roughly 318,000 rows banked. That is a sync that worked, not one that kept being cut off. Only the 07:48 session handed over nothing, and one empty attempt among six is not what made your morning slow.

So the honest answer to "why did it take ages" is the plain protocol cost, not the errors and not the timeouts. NOOP pulls a 4.0's history record by record, because the bulk-transfer command has not been reverse engineered, where the official app moves a day in a minute or three. Your numbers: the gap went from 73,356 seconds to 503 between 07:25 and 07:59, so about 20.4 hours of history in roughly 34 minutes, near 36x real time. That is the expected shape today, and it is the thing worth fixing, which is tracked separately.

What stands from my earlier comment: the IQS7223B and CAPSENSE lines are your strap's own firmware and nothing to do with NOOP; the console chatter really is 32% and 44% of those two logs; and the mangled rendering of those lines is our decoding bug, for which a raw capture would still help a lot.

What does not stand: I linked the console volume to the timeouts and presented that as the cause of the slowness. I had the mechanism the wrong way round, and the row counts were sitting in your log one line below the timeouts the whole time. Apologies for the noise.

[Geg0r]

Thanks @ryanbr for that detailed answer.

I will provide a new log tomorrow by using the raw capture (connection & sync).

[Geg0r]

noop-connection-iOS-v11.8.0-260923-0740.zip

Please find attached the new logs from this morning.
I have the feeling that today the sync was "quicker" but I think this is more a coincidense.