rc7 stops importing hourly SpO2 while keeping HR from the same record

[Albabit]

Since installing rc7 my Blood Oxygen history is empty from Sept 9 afternoon to now, while Heart rate for those same days is complete.
The only SpO2 reading I have is one spot measurement I ran a few minutes ago.

On rc6 this worked : Sept 9 morning showed hourly SpO2 readings at 7:00, 8:00, 9:00, 10:00 alongside the spot ones.

The ring still has the data. I read its memory directly with my Python client. 43 composite 05 18 records between Sept 9 12:00 and now, each carrying both values in the same record :

09-10 08:00   HR 96   SpO2 97
09-10 09:00   HR 85   SpO2 98
09-10 11:00   HR 53   SpO2 92
09-11 07:00   HR 56   SpO2 94
09-11 08:00   HR 59   SpO2 95
09-11 10:00   HR 89   SpO2 98

Every one of those hours shows up in the app's HR list. None of them shows up in the SpO2 list. So it's reading the record and dropping half of it rather than missing the record.

Worth noting the spot measurement I ran today did store, so it's specifically the ones coming from 05 18 history that are lost, not SpO2 generally.

I can't tell whether this came in with rc7 or rc6, since I only noticed after installing rc7. If it helps narrow it, the last hourly SpO2 the app has is Sept 9 at 10:00, and I installed rc6 on the morning of Sept 8.

Raw 05 18 payloads attached, same framing as the sleep dump on #63 : complete notifications off be940003, with each frame annotated by the records its payload declares. Six frames, 20 bytes per record, SpO2 at offset 9 and HR at offset 6 within each.

spo2_raw_dump.txt

[foureight84]

@Albabit — I ran your dump through the app's own decoder rather than by eye, and it clears the part I'd have suspected first: the decode is not what's dropping it. All six frames, all 43 records, every 05 18 field lands where we read it — SpO₂ at offset 9, and your annotations match ours record for record (12:00 → 98, 16:00 → 91, 09-11 10:00 → 98, and the 10:12 one with HR 0 that is your spot measurement). The values are 91–98, inside the 70–100 plausibility band, and the timestamps are inside the 8-day history window. Nothing in that path rejects them.

So the fault is either before the decode (the app never got the record) or after it (we wrote it and something removed it, or the screen isn't reading it). I can't tell which from this dump, and that is not a shortcoming of the dump — it came off the ring via your Python client, so it shows what the ring holds, not what the app asked for or received. Two things would split that, and the first is 30 seconds of your time:

1. Check HRV, respiratory rate and blood pressure for those same hours. All four values ride in the same 05 18 record — your 09-09 12:00 record carries SpO₂ 98, HRV 38, respiratory rate 17 and BP 105/71. So:

• If HRV, respiratory rate and BP are also missing for those hours, the whole record never landed, and this is a sync/transfer problem rather than anything SpO₂-specific.
• If they're present and only SpO₂ is missing, the record landed and something is specific to SpO₂ — a much narrower search, and one I'd look at very differently.

That one observation halves the problem, so it's worth having before I change any code.

2. A diagnostics export from Settings after a sync. This is the instrument that shows what the app sent and what came back — whether it asked for 0x09, how many data frames arrived, and whether the terminal block matched. It is the only artefact that can distinguish "never received" from "received and dropped", and thanks to the masking fix from #58 it will actually say so now. Health values are masked; the command bytes aren't.

On the timing

You're right to be unsure whether it was rc6 or rc7. For what it's worth I went through both diffs: rc7 touched the sleep parser and its tests and nothing else, and rc6's only changes near this path were the written return on the history write and a SportTelemetry branch for Colmi. Neither reads or writes SpO₂ history. So I don't yet have a code change that explains a clean break on Sept 9 afternoon, which is another reason I want the export rather than a guess — if this is older than rc6 and you only noticed now, that changes where I look.

Something I found next door, not the bug

Your 05 18 record carries heart rate at offset 6 and we don't read it — we take HR from the dedicated 05 15 history instead, which is why your HR list is complete. It's not the cause of anything here (the same hours are covered either way), but it does mean the composite record is a second source of HR we're ignoring, and I'd rather note it than rediscover it later.

Meanwhile

v2.8.0+49-rc9 is up, but it does not touch this — please don't read it as an attempted fix. It carries four fixes from a review pass (details on #60 and #63). Installing it is fine and won't make this any worse, but the two things above are what will move this issue.

[foureight84]

One warning before you do anything else, and it's my fault for not leading with it: do not roll back from rc9 to an earlier build without exporting a backup first.

rc9 upgrades the database (v24 → v25). Every rc up to rc8 was v24, so swapping between them was harmless — that's no longer true. A downgrade falls back to a destructive migration, which wipes the local database: measurements, sleep, coach conversations, everything the app holds that the ring can't re-supply.

This matters here specifically because rolling back to rc6 is the obvious way to answer "was it rc6 or rc7" on this issue, and it's a reasonable instinct. If you want to do that:

1. Settings → export a data archive first.
2. Then install the older build.
3. Restore the archive afterwards if anything's missing.

Or skip the bisect entirely — the diagnostics export from rc9 will tell us more than knowing which build it started in, because it shows whether the app asked for the record at all. I'd rather have that than have you risk two weeks of history.

[Albabit]

@foureight84 ,
Diagnostics export attached. It answers both questions, and the second one more sharply than I expected.

On your first question, I can't check. Vitals on this ring only offers Heart Rate and Blood Oxygen. There's no respiratory rate, HRV or blood pressure card at all, presumably gated off the capability bitmap, which declares all three absent. So I have no way to see whether they're present for those hours from the UI.

The export makes that moot though.

The records arrive

05 09 is asked and answered :

OUT  05 09 06 00 b2 0c
IN   05 09 10 00 2a 00 05 00 00 00 48 03 00 00 ba 01

0x002a = 42 records, 0x0348 = 840 bytes, and 840 / 42 = 20. That's the record size I've been decoding all along.

And the data follows : 57 incoming 05 18 frames in this session.

They arrive and aren't decoded

Every one of them is logged as unknown :

IN  05 18 42 00 e2a9363259014d684462102902000f000000a946f9b736329b014c6744620f2805000f00
    decoded: unknown

That payload is three 20-byte records. Taking the first : timestamp, steps, then 59 HR 89, 01 4d … 68 SpO2, 44 … 62 … and the 0f temperature filler. All four values are sitting right there in a frame the app received and threw away.

So it's not a sync or transfer problem. The record lands, the parser doesn't know it.

And 05 1a is never answered

OUT  05 1a 06 00 81 16     x10
IN   (nothing, ever)

Ten requests across the session, zero responses. Your own R10M notes say this family has no dedicated SpO₂ log, and the export confirms it on hardware : the ring simply doesn't reply. If SpO₂ history is sourced from 05 1a with 05 18 as an unhandled fallback, that would explain the shape of this exactly, HR surviving because it comes from 05 15 instead.

I don't know what changed on Sept 9 to start it, and given the above I'm less sure the timing means anything. Happy to pull more exports or run anything else.

pulseloop-diagnostics-2026-09-11T12-07-06.669087Z.json

[foureight84]

@Albabit — found it, and your export is the whole reason. Fixed in v2.8.0+50-rc10 (install the universal APK over rc9).

The records arrive, and the app throws away the whole block on a self-consistency check. Your 05 09 header declares 5 packets for 840 bytes. The ring then sends 6. The app required those two numbers to agree, and when they didn't it nacked the block, retried once, and skipped the type — every transfer, six for six in your export. The bytes and the CRC were correct every single time.

The ring isn't lying, it's estimating. It packs whole 20-byte records into each frame — 7 × 20 = 140 bytes — rather than filling the frame, so its header's ceil(bytes / frame) comes out one short of what it actually sends. And the vendor never checks that number: at Sync_Block_Verify its DataUnpack reads the two count bytes into locals it never compares, sizes its buffer from the terminal block's length, and accepts on the CRC alone. We were stricter than the ring's own app, and this firmware punishes that.

So the header's totals now only size the buffer, and a transfer is judged on what the terminal says arrived plus the CRC. A genuinely short transfer still fails, and that's still tested.

Why it looked like rc7

It only bites above one packet. While your composite history was small enough to fit one frame, the header said 1, the ring sent 1, they agreed, and the record imported — which is your hourly SpO₂ up to Sept 9 morning. Once it grew past a frame the counts diverged and every sync from then on was discarded. Nothing changed in the code on Sept 9; your data crossed a boundary. Your instinct that the timing might mean nothing was right, and my checking both diffs and finding nothing near this path was the same fact from the other side.

Where your reading was right, and the one place it wasn't

Right: the record lands and the app doesn't use it; 05 1a is never answered, so 05 18 is the only SpO₂ history source on this family, which is exactly why HR survived from 05 15 and SpO₂ didn't. That framing is what sent me to the transfer layer.

The one thing to correct, because it'll save you time next capture: decoded: unknown on a history data frame is normal. Those frames are accumulated and only decoded when the terminal block completes the block, so an intermediate frame legitimately decodes to nothing. Your own export has 427 05 13 sleep frames all marked unknown, and sleep imports fine. It wasn't evidence of the parser not knowing the record — the parser never saw it.

What this also restores

That record carries respiratory rate, HRV, blood pressure, temperature and blood sugar alongside SpO₂. Your ring's capability bitmap declares BP, HRV and respiratory rate absent, which is why there are no cards for them — so you may not see any change there, and that's the ring's call rather than ours. But if any of them do start appearing, that's this fix, not a new problem.

What would confirm it

• Hourly SpO₂ for the last few days appearing after a sync on rc10. The ring holds about a week, so Sept 9 onward should backfill rather than only starting from today.
• Whether the count then keeps up over the next day, since the failure grew with the record.

And a caution I owe you from earlier: rc9 and rc10 are database v25, so don't roll back to rc8 or earlier without exporting an archive first — a downgrade wipes local data.

Thank you for this one in particular. Six lines of an export answered a question that two dumps and a week of guessing hadn't, and the fix is one the vendor's own source had been sitting on the whole time.

[Albabit]

@foureight84 ,
rc10 confirmed. Hourly SpO2 is back.

Sept 11 backfilled with a full day of hourly readings and today is filling in as it goes. Sept 9 is still there from before the break. So the fix works and it does backfill rather than only starting from install.

Sept 10 didn't come back, and that one's the ring, not you. I read its memory straight after syncing : the composite block now only holds Sept 11 12:00 onward, 22 records. Sept 10 isn't in there to fetch.

Worth noting how fast that window moves. Yesterday the same block held about 43 records going back to Sept 9 12:00. Today it's 22 going back to Sept 11 12:00. So retention on this block is roughly two days at hourly cadence, nothing like the seven days the ring's manual claims. Sept 10 aged out while the transfer was still being discarded.

Which is a small argument for the fix mattering more than it looks : on this ring a broken import doesn't just delay data, it loses it permanently within about 48 hours.

And thanks for the correction on decoded: unknown. I'd read it as the parser not knowing the record and reported it that way, when the parser simply hadn't been handed it yet. Good to know for next time which part of an export means something.

[foureight84]

Closing — confirmed on hardware by @Albabit on rc10: hourly SpO₂ is back, Sept 11 backfilled a full day, and the current day fills as it goes.

Cause: the app required the terminal block's packet count to equal the one the header declared. This ring's firmware contradicts its own estimate one frame later — the 05 09 header declares 5 packets for 840 bytes and the ring then sends 6, because it packs whole 20-byte records per frame (7 × 20 = 140) instead of filling it. Bytes and CRC were correct on every transfer; the app nacked all six, retried once and skipped the type. The vendor never checks that number either: at Sync_Block_Verify its DataUnpack reads the two count bytes into locals it never compares, sizes its buffer from the terminal's length, and accepts on the CRC alone.

It only bit above one packet, which is why the record imported while the day was young and stopped once it grew — and why it looked like a regression from a release that had touched nothing nearby.

Scope: the composite 05 18 record is the only SpO₂ history source on this family (the dedicated 05 1a query went unanswered ten times in one session), which is why HR survived from 05 15 and SpO₂ didn't. Respiratory rate, HRV, blood pressure, temperature and blood sugar ride in the same record, so they were being discarded too wherever a ring reports them.

One thing worth recording from @Albabit's follow-up, because it changes how urgent this class of bug is. The composite block's retention on this ring is roughly two days at hourly cadence, not the seven the manual claims — the window went from 43 records reaching back to Sept 9 to 22 reaching back to Sept 11 in a single day. Sept 10 aged out while the transfer was still being discarded and is gone for good. So a broken import here doesn't delay data, it destroys it inside 48 hours, which is an argument for treating "a metric went quiet" as urgent rather than cosmetic.

And a diagnostics-reading note for the future: decoded: unknown on a history data frame means nothing is wrong. Those frames are accumulated and only decoded when the terminal block closes the block, so an intermediate frame legitimately decodes to nothing — the same export carried 427 05 13 sleep frames marked unknown while sleep imported perfectly. When a whole metric is missing and its neighbours are not, look at what the transfer did with the block before suspecting the parser.

Ships with #62. @Albabit — thank you; the export you attached had the answer six lines in, and your reading of it ("the record lands and the app doesn't use it") is what pointed at the transfer layer instead of the decoder.

[foureight84]

@Albabit — this shipped as a normal release: PulseLoop 2.8.0. Same code as rc10, so nothing new to test; the in-app updater will offer it and you can take it straight over the prerelease you're on.

Everything you reported over the last two weeks is in it — the spot heart rate settling, deleting readings, the split-night sleep records and the SpO₂ import. Thank you for the captures, the ring read-backs and the vendor decompile; most of what changed came from evidence you gathered rather than from guesswork here.