PulseLoop 2.8.0 (42)
Pre-release
Pre-release
·
0 commits
to main
since this release
Test build for @Albabit — rc2, follow-up to rc1. Prerelease, so the in-app updater won't offer it to anyone else. Everything confirmed working in rc1 is unchanged.
Built from your SpO₂ capture on #59. All three of the risks you flagged turned out not to apply — the SpO₂ leg used none of the machinery you were worried about — but the capture exposed a different problem underneath: the leg returned the first plausible sample and stopped, which on your run is 96 % at t+13 s, thirty-seven seconds before the ring finished and before nine further samples arrived.
What changed
- SpO₂ now waits for the ring and settles the run, rather than answering on the first sample. It ends on
04 0elike heart rate does. - The settle takes the median. Your capture peaks at 99 and declines to 94, and one run can't say which end is honest — the median deliberately picks neither. This is provisional and marked as such in the code; more captures would settle it.
- SpO₂ gets the one-reading-per-measurement rule that heart rate got in rc1. It matters more here: your run streams twelve values, all of which would otherwise land in your history.
- The countdown is honest now. It sums only the legs your ring will actually run instead of all four, so it should read well under the 188 s you saw.
Rings that never send 04 0e (Colmi, CRP) keep the old fast path — waiting for a signal they don't send would just make their measurements a minute long for nothing.
What would help
- Does a spot SpO₂ still land on a sensible number, and does it end when the ring does (~50 s) rather than running to the window?
- Several more SpO₂ captures, if you're still willing. Whether the peak-then-decline shape is consistent is the one thing that would let me replace the median with a rule that's actually grounded.
- Whether the doubled HR readings reappear. Best guess is that the ring logs the spot reading into its own history and a later sync imports it alongside ours — which would explain why a measurement with no sync after it gave you exactly one row. If you see it again, roughly when the last sync ran is the useful detail.