Skip to content

PulseLoop 2.8.0 (42)

Pre-release
Pre-release

Choose a tag to compare

@github-actions github-actions released this 03 Sep 20:58
· 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 0e like 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.