Spot heart rate never completes on a YCBT ring: warm-up value kept, completion event ignored

[Albabit]

Following on from #56 : Detection works now, the ring pairs and syncs fine.
This is a separate problem.

On my Ale-Hop2211 E1C7 (YCBT, ColmiSmartHealthCoordinator), a spot heart rate measurement always ends with :
"Couldn't get a steady reading. Keep the ring snug and your hand still, then try again.",
and the card then shows 46 bpm, Resting 46 · Peak 46, which was never my heart rate.
SpO2 on the same ring works fine (96%).

What the ring actually does :

I instrumented the BLE stream with a Python client.
Started the measurement with 03 2f {01 00}, sent no stop command, and logged every frame with timestamps:

t+ 0.1s   03 2f reply: 00                (accepted)
t+14.1s   47 bpm
t+15.1s   47 bpm
t+16.1s   47 bpm
t+22.1s   46 bpm
t+23.1s   46 bpm
t+24.1s   46 bpm
t+26.1s   84 bpm
t+27.1s   84 bpm
t+28.1s   84 bpm
t+32.1s   82 bpm
t+33.1s   81 bpm
t+34.1s   81 bpm
t+35.1s   81 bpm
t+35.1s   04 0e {00 01}                 <- ring ends the measurement itself

So the measurement succeeds, in about 35 seconds, well inside the 173 s window the app allows.
The ring emits 04 0e with {sensor 0x00, status 0x01} when it's done, and stops streaming.
Samples arrive in bursts of three, a few seconds apart.
The PPG takes roughly 26 seconds to converge. Everything before that is warm-up, and on this ring the warm-up sits around 46–47.

What I think the app is doing :

Two things, either of which alone would produce what I see :

1. It keeps an early sample rather than the last one. The displayed 46 is a warm-up value from t+22–24 s. The final reading was 81.
2. It doesn't appear to act on 04 0e. The ring goes quiet at 35 s, the app keeps waiting, and at the end of its window reports that the reading was never steady.

The error message is a bit unlucky here: the warm-up values are extremely stable (47 47 47, then 46 46 46), so a stability heuristic will happily accept them unless warm-up is discarded explicitly.

Suggestion :

Treat 04 0e with status 01 as the completion signal, and take the last value received before it rather than the first stable one.
If a floor is wanted, discarding samples before the first significant jump would work. The warm-up-to-real transition on this ring is a clean step from 46 to 84.

I don't know whether the 26 s convergence and the 35 s self-termination are consistent across YCBT rings or specific to this one, so a fixed threshold is probably worse than reacting to 04 0e.

Happy to run more captures or test a build.
I still have the ring and the client.

[foureight84]

This is good data. I will make the changes and get back if more data is needed. We don't have these devices on hand and these types of contributions are immensely useful.

[Albabit]

@foureight84 ,
Glad it helps, and thanks for the quick response ☺️.

Happy to test a build whenever you have one, and to run more captures if anything else needs pinning down.
I can also try the same instrumentation on SpO2 if it would be useful to confirm whether it self-terminates the same way.

Separately, I've opened #60 suggesting the ability to delete individual readings from history.
It's partly prompted by this bug, since every failed attempt leaves a bogus 46 bpm in my record with no way to remove it, but I think it stands on its own regardless.

[foureight84]

@Albabit — your capture was enough to fix this without the hardware, thank you. A test build is up: v2.8.0+41-rc1 (PR #62). It's a prerelease, so the in-app updater won't push it to anyone else; install the universal APK over your current build.

Both of your hypotheses were right, and there was a third cause underneath them:

1. 04 0e really was ignored. The decoder acknowledged it and deliberately declined to read its fields. It's now decoded, and the layout is the vendor's rather than a guess — BaseMeasureActivity.onDataResponse matches bArr[0] against the measurement type and switches on bArr[1] (1 success, 2 failed, else cancelled). Note it reads no value from that frame; on success the vendor app re-syncs history instead. So we use it purely as "stop waiting", which is what you suggested.

2. The warm-up plateau outvoted the real reading. The settle took a median over the whole window, and as you spotted, the plateau is not just early — it's more stable than the converged signal, so it won on consistency. The settle now looks at the tail of the window instead. Replaying your capture through it: 82 bpm, not 46.

   One distinction your report helped clarify: the existing 5 s discard is for a cached echo (the ring answering instantly with a stored bpm). Your ring sent nothing for 14 s. A pre-converged plateau turned out to be a different problem needing a different rule, and conflating the two is part of why this survived.

3. The one you couldn't see from the ring side. The contact-lost abort fires after a 3 s gap — but your bursts are separated by 4–6 s (16.1 → 22.1 is a full 6 s). So the leg was very likely aborted at ~t+19 s, before the sensor had converged at all. That alone reproduces both symptoms: the failure message, and the stale warm-up value still sitting on the card. The gap is now 8 s, and the warm-up value no longer reaches the display.

I also raised the HR window to 45 s for YCBT rings — your ring self-terminates at ~35 s, and the old 30 s cut it off within a few samples of the real reading. That's only safe because the leg now ends on 04 0e, so it isn't a slowdown for rings that finish sooner.

Yes please to the SpO₂ instrumentation you offered. Spo2Complete has exactly the same gap and I'd much rather fix it from a capture than by assuming symmetry with HR — your ring has already shown that HR and SpO₂ behave differently on these devices.

What would confirm the fix:

• A measurement ending when the ring does, with a plausible number.
• That it holds over several attempts, not just one.
• That a genuinely bad attempt (ring loose, hand moving) still fails rather than settling on something — I'd rather this be honest than confident.

[Albabit]

@foureight84 ,
Here's the SpO2 capture you asked for. Same method as before : 03 2f {01 02} to start, no stop command sent, everything timestamped. I've added the gap between samples since that turned out to matter.

t+ 0.1s   03 2f reply: 00
t+13.1s   96 %
t+14.1s   96 %   (+1.0s)
t+15.1s   96 %   (+1.0s)
t+39.1s   99 %   (+24.0s)     <- 24 second gap
t+40.1s   98 %   (+1.0s)
t+41.1s   98 %   (+1.0s)
t+42.1s   98 %   (+1.0s)
t+45.1s   96 %   (+3.1s)
t+46.1s   96 %   (+0.9s)
t+47.1s   95 %   (+1.0s)
t+48.1s   94 %   (+1.0s)
t+49.1s   94 %   (+1.0s)
t+50.1s   04 0e {02 01}        <- ring ends it, sensor 0x02, status success

You were right not to assume symmetry. Three things differ from HR on this ring :

The gap is 24 seconds. Not 4 to 6. If SpO2 shares the contact-lost rule you just widened to 8 s, it would abort at roughly t+23 s, before the second burst ever arrives. On this ring the whole middle of the measurement is silence.

It runs for 50 seconds, where HR self-terminated at 35. You raised the YCBT HR window to 45 s : if SpO2 uses the same window it gets cut five seconds short, right at the point where the ring is about to say it's done.

The tail declines. HR converged and stayed there, so taking the tail was the right call. Here the peak is 99 at t+39 and the reading drifts down to 94 by t+49. A tail-weighted settle would land on 94-95 while the sensor's best signal was several points higher. I don't know which of those is the honest number, and I'm not going to guess from one capture. But the rule that fixed HR doesn't transfer unchanged.

The good news is 04 0e behaves identically : sensor byte 0x02, status 0x01, and the ring stops streaming right after. So the "stop waiting" half works the same for both.

Happy to run this several more times if you want to see whether the 24 s gap and the declining tail are consistent or just this one attempt. That seems worth knowing before you pick a rule, and it costs me nothing.

Installing the rc1 build now, will report on the HR fix and on #60 separately.

[Albabit]

@foureight84 ,
Tested rc1. Short version : the HR fix works.

Three consecutive measurements gave 76, 82 and 81 bpm. Plausible every time, no warm-up plateau. The countdown runs to 188 s but the measurement ends well before that, which I take to be the 04 0e handling doing its job.

The bad attempt fails properly. I loosened the ring and moved my hand during a measurement : it stopped with the error and nothing was recorded. That's the behaviour you asked for.

On SpO2, all three measurements settled on 99 %.

Deleting a reading works, and the delete button behaves as described. I haven't yet tested the part that matters : deleting a reading that came from ring history and letting the day re-sync. I'll report on that separately.

One thing I can't fully explain :

After those three measurements I had six HR readings, two per measurement, paired on the same minute :

10:09 AM   81 bpm
10:09 AM   81 bpm
10:08 AM   79 bpm
10:08 AM   82 bpm
10:07 AM   76 bpm
10:07 AM   76 bpm

That contradicts "a spot measurement's output is one reading now" from #60, so I tried to reproduce it cleanly : deleted all six, ran a single measurement, and got exactly one reading (76 bpm). It survived closing and reopening the app.

So I can't reproduce it on demand. The six were recorded shortly after installing rc1, so they may predate the fix taking effect, or come from a first sync re-importing readings that were already there. I'd rather flag it than quietly drop it, in case it points at something. Happy to keep watching for it.

A suggestion, separate issue if you prefer :

Being able to run HR and SpO2 independently would help. My captures show they behave quite differently on this ring : 35 s versus 50 s to complete, with very different sample spacing. Running them from one button forces a compromise on both.

[foureight84]

@Albabit — thanks for both. rc2 is up with a fix built from your SpO₂ capture: v2.8.0+42-rc2.

Glad the HR fix holds across three runs, and particularly that the deliberately bad attempt failed — that was the part I was least sure of, since it's the case where a wrong rule looks like a working one.

Your SpO₂ capture — you were right, for a reason neither of us had

I checked all three risks against the code, and none of them apply, because the SpO₂ leg turns out to use none of the machinery you were worried about:

• The 24 s gap is harmless. The contact-lost rule lives in the HR sampling window; the SpO₂ leg never touches it. Nothing was going to abort at t+23 s.
• The 45 s window isn't its window. SpO₂ has always had its own, at 60 s. Your 50 s run fits.
• There was no tail settle to mis-apply — and this is the part that matters.

Because the SpO₂ leg didn't settle at all. It returned the first plausible sample and stopped. On your capture that's the 96 % at t+13 s — handed back thirty-seven seconds before the ring finished, with nine further samples still to come. It also meant the 04 0e handling I added in rc1 was unreachable for SpO₂, since the leg had already returned before the ring ever sent it.

So "the rule that fixed HR doesn't transfer unchanged" was the right instinct, and your insistence on not guessing from one capture is what stopped me shipping the tail rule onto a metric that declines.

What rc2 does: the leg now collects the run and ends on 04 0e, and settles on the median. I picked the median specifically because it refuses your open question — it privileges neither the 99 peak nor the 94 tail. It's marked provisional in the code, and it's a separate tested class precisely so it's cheap to replace once there's evidence.

Yes, please, to more captures. Whether the peak-then-decline shape is consistent or was one attempt is the single thing that would let me replace a deliberately non-committal rule with a grounded one. Three to five runs would do it.

One consequence worth knowing: SpO₂ now takes ~50 s instead of answering in ~13 s. That's the cost of not answering with a pre-convergence sample. Rings that never send 04 0e keep the fast path.

The doubled readings — I don't think you should drop it

Your instinct to flag it was right, and there's a plausible mechanism. The vendor app's entire reaction to a successful 04 0e is to call syncData() — the ring logs the spot reading into its own history. So a later history sync would import it as a second row alongside the one we store for our settled value: same minute, and values that can differ slightly, which is exactly your 10:08 → 79, 82 pair.

That also explains why it wouldn't reproduce. Your clean retest was a single measurement with no history sync after it, so only our row existed. The six appeared right after installing rc1 — an app restart and reconnect, which runs a full history sync.

I haven't fixed it, because it's a question of who owns the reading (us or the ring's log) rather than a bug with an obvious patch, and I'd rather confirm the mechanism than guess. If you see it again, the useful detail is roughly when the last sync ran relative to the measurements.

Also in rc2

The countdown. You spotted it reads 188 s while the measurement ends far earlier — that was the sum of all four legs including two your ring may not run. It now sums only the legs that will actually run. Related: your suggestion about separate HR and SpO₂ buttons is a good one and I'll open it as its own issue — your two captures are the argument for it, since 35 s and 50 s with completely different sample spacing is not one measurement wearing two hats.

[Albabit]

@foureight84 ,
Five more SpO2 captures. The first four were taken one to two minutes apart in identical conditions (sitting, ring snug, hand resting still). The fifth was later, hand suspended rather than resting, still sitting. Same method throughout : no stop command, everything timestamped.

Capture 1        Capture 2        Capture 3        Capture 4        Capture 5
t+27.1  99 %     t+26.1  99 %     t+27.1  99 %     t+15.1  98 %     t+14.1  97 %
t+28.1  98 %     t+27.1  98 %     t+28.1  98 %     t+16.1  98 %     t+15.1  97 %
t+29.1  98 %     t+28.1  98 %     t+29.1  98 %     t+17.1  98 %     t+16.1  97 %
t+30.1  98 %     t+29.1  98 %     t+30.1  98 %     t+49.1  86 %     t+45.1  99 %
                                                   t+50.1  86 %     t+46.1  99 %
                                                   t+51.1  86 %     t+47.1  98 %
                                                   t+57.1  87 %     t+48.1  98 %
                                                   t+58.1  87 %     t+49.1  98 %
                                                   t+59.1  87 %     t+62.1  99 %
t+63.1  04 0e    t+63.1  04 0e    t+63.1  04 0e    t+63.1  04 0e    t+63.1  04 0e

There is no consistent shape. Three captures are a single tight burst with no decline at all. Capture 4 falls off a cliff, 98 down to 86. Capture 5 goes the other way, 97 up to 99. My original capture rose to a peak then drifted down. So late samples aren't systematically lower, and one capture genuinely couldn't have told you the shape.

Where that leaves the median. It's fine on four of the five. It breaks on capture 4, where the median is 87 while three measurements taken minutes either side say 98. On a metric where eleven points is the difference between normal and alarming, that's the failure worth knowing about. Last-value gives 87 there too; only the first burst gives 98.

I'm not proposing first-value instead, since that's effectively what rc1 did and your read of my original capture showed why it's wrong. Five captures don't settle this either. But the failure mode is narrower than "the tail declines" : the median only breaks when a late burst collapses, and it collapses in one run out of five with nothing obviously different about it.

If it's any use, capture 4 is also the one where the first burst arrived earliest, t+15 against t+26 to t+27 for the tight ones. Capture 5 also started early, at t+14, and didn't collapse, so that may be nothing.

One thing does look solid : 04 0e arrives at t+63.1 s in all five, to the tenth of a second, no matter when samples arrived or stopped. It isn't triggered by the data ending, and in capture 5 a sample lands at t+62.1, one second before it. Worth noting this differs from my first capture, where completion came at t+50.1 s, so it isn't a fixed constant across sessions. The only thing that changed on my side in between was enabling all-day HR at a 30 minute interval.

Happy to run more, and happy to run them under deliberately varied conditions (loose ring, straight after walking) if that's more informative than more near-identical ones. Tell me which would help. Installing rc2 next and will report separately.

[Albabit]

@foureight84 ,
Correction to my last comment, and I think this settles the settle rule.

After installing rc2 I noticed my SpO2 history had entries at 9:32, 9:37, 9:42, 9:47 and 9:57.
Those are the exact times of the five captures I ran from my Mac. The ring logged each of them into its own history, which is the mechanism you described for the doubled readings on #60. So I read them straight out of the ring's memory with my Python client and lined them up against the raw streams.

Capture	Samples	Last	Median	Ring stored
1	99, 98, 98, 98	98	98	98
2	99, 98, 98, 98	98	98	98
3	99, 98, 98, 98	98	98	98
4	98×3, 86×3, 87×3	87	87	87
5	97×3, 99, 99, 98×3, 99	99	98	99

Last value matches all five. Median matches four. It parts company on capture 5, where the ring stores 99 and the median gives 98.

So the firmware settles on the last streamed sample, which is what your HR fix already does, and what you deliberately didn't do here.

And my worry about capture 4 was wrong. I said the median would return 87 where the truth was 98. It wouldn't: the ring itself records 87 for that run. That measurement was simply bad, and the ring says so.
There was no eleven-point error to avoid, and the shape of the curve was never the thing to reason about.

I should have checked this before arguing from the shape. It's also a method you can reuse : this ring writes its own spot readings to history, so its answer to any given stream can be read back and compared. If that holds on other YCBT rings it's a ground truth rather than an inference.

Two caveats. All five captures are from one ring in one sitting, so "last value" is five for five rather than proven. And I had all-day HR running at 30 minute intervals during them, with automatic measurements at 9:30, 10:00 and 10:30. None coincide with my captures and the collapse at 9:47 is nowhere near a boundary, but I can't rule out interference entirely.

Happy to repeat this with HR spot measurements too if a second metric would help confirm it.

[Albabit]

@foureight84 ,
Third source on this, and it agrees with the other two. I decompiled the vendor APK (com.zhuoting.healthyucheng 1.27.96) and read its measurement screen.

It doesn't settle at all. BloodOxygenMeasureActivity.onEvent receives each realtime frame (1538 = 0x06 0x02) and overwrites the on-screen text with it:

Integer num = (Integer) map.get("bloodOxygenValue");
if (num == null || num.intValue() == 0
        || num.intValue() < TransUtils.BLOOD_OXYGEN_VISIBLE_MIN
        || num.intValue() > TransUtils.BLOOD_OXYGEN_VISIBLE_MAX) {
    return;
}
this.tvLottieData.setText("" + num);

No median, no average, no window. Whatever arrives last is what's on screen. The only filter is plausibility : BLOOD_OXYGEN_VISIBLE_MIN = 70, BLOOD_OXYGEN_VISIBLE_MAX = 100, and zero is dropped.

And the displayed value isn't what gets stored. BaseMeasureActivity handles 1038 (0x04 0x0e) exactly as you described:

byte b2 = bArr[1];
if (b2 == 1) {
    toast(measure_success);
    syncData();          // re-reads the ring's history
} else if (b2 == 2) {
    toast(measure_failed);
} else {
    toast(measure_cancel);
}

So the vendor app never decides the number. The ring decides, the app re-reads it. Which matches what I measured : across five captures the ring's stored value equalled the last streamed sample every time.

That also confirms your reading of bArr[1] (1 success, 2 failure, anything else cancelled) against the source rather than inference.

So three independent things now point the same way : the raw stream, the value the ring writes to its own history, and the vendor's code. I think last-plausible-value is defensible for YCBT, with 70–100 as the plausibility band since that's what the vendor uses. Your Spo2SampleWindow being isolated and marked provisional makes that a small change if you agree.

Still just one ring, and I'd rather you weigh it than take my word for it.

I haven't gone looking at anything else in that APK, but it's decompiled on my machine now, so if a specific question comes up about what the vendor does, I can look it up rather than guess.

[foureight84]

@Albabit — your three sources settled it, and rc3 is built on them: v2.8.0+43-rc3 (prerelease; install the universal APK over rc2).

Reading the ring's own history back against the raw streams was the right move, and it's a better method than anything I could have done from here — the ring's stored value is the answer to "which sample is honest", and it makes the vendor's syncData()-on-success make complete sense. Thank you for going and checking rather than arguing from the shape, and for saying so.

What rc3 does

• SpO₂ settles on the last plausible sample, filtered by the vendor's 70–100 band and nothing else. The median is gone. Your five captures are now the regression tests, each asserting the value the ring stored — including capture 4 settling to 87, which the code comments now describe as a bad measurement the ring correctly called bad, not a rule failure.
• The window is 75 s on this family. Your 04 0e at t+63.1 s was landing three seconds after the old 60 s ceiling, so rc2 was timing out and settling on its own just before the ring spoke. This is why I'd rather have the completion signal than a value-based exit: capture 4's late burst changed the answer, so "a value in hand" is not "done".
• The doubled readings are handled, now that you've confirmed the mechanism. Our settled reading is stored, and when a later sync imports the ring's copy of that same measurement (same kind, within 90 s), ours yields to the ring's. The ring's row wins because it's the one that regenerates on every sync, so it's the one a deletion can hold down.

Also folded in from a review pass: BP and HRV no longer mistake the ring's success verdict for a failure (those legs read no value from 04 0e), and the one-reading rule can no longer be slipped by samples still queued while storage catches up on a busy sync.

What would confirm it

• A few spot SpO₂ measurements, each checked against your read-back of the ring's stored value. They should now agree.
• Then a sync: the reading should stay one row in the Readings list, and it should be the ring's.
• Whether the leg ends when the ring does (~63 s on that session) rather than running to 75.

You offered to repeat the read-back for HR spot measurements — yes please, if it's no trouble. HR settles on the tail of the run rather than the last sample, and if the ring's stored HR turns out to be "last sample" too, that's worth knowing before this merges.

[Albabit]

Ran the HR read-back you asked for. Three spot measurements from my Mac, no stop command, then I read the ring's history back before letting any app near it.

The ring stores the last sample for HR too. Three for three.

Capture	Stream	Last	Ring stored
1	47×3, 46, 46, 45×3, 46, 46, 47, 55, 65, 65	65	65 at 08:14:28
2	47×3 … 44×3 … 49×3, 51, 51, 53, 53, 54, 55, 57, 58, 58	58	58 at 08:18:18
3	47×3, 46×3, 47, 47, 55, 66, 72, 72	72	72 at 08:21:44

And this one is discriminating, unlike SpO₂ where tail and last coincided. Here the value is still climbing when the ring stops, so the last six samples of each run are :

Capture 1:  46, 46, 47, 55, 65, 65
Capture 2:  53, 54, 55, 57, 58, 58
Capture 3:  47, 47, 55, 66, 72, 72

Any tail-weighted settle lands below the ring's answer on all three, and by a lot on 1 and 3. So if you want HR to agree with what the ring records, last-plausible-sample looks like the rule there too.

One thing that came out of this and isn't about the settle rule :

The ring ends the measurement while the value is still rising. Capture 1 stopped at 34.2 s on 65, capture 3 at 34.2 s on 72. My capture on Sept 3 reached 84 at t+26 s and finished at t+35 s on 81. Completion times here were 34.2 s, 49.2 s and 34.2 s, so the duration varies run to run and the ring will happily stop mid-climb.

Which means "the ring's stored value" is the honest answer to which sample the firmware chose, but it isn't always a converged reading. That looks like the same mechanism behind the 48–50 bpm automatic readings I mentioned on #60 : the firmware sampling a window too short for its own PPG to settle.

I'm not suggesting you correct for that. The ring's number is the ring's number, and inventing a better one in the app would be worse. Just flagging that on this ring the two questions "which sample" and "is that sample any good" have different answers, and only the first is yours to solve.

Installing rc5 now and will report on the app-side checks separately.

[foureight84]

@Albabit — the HR read-back settled it, thanks. On the branch now: for this family the reading is the last plausible sample of the run (vendor band 40–220, the same filter HeartRateMeasureActivity.onEvent applies), so the app should agree with what the ring stores, as SpO₂ already does. Your three captures are the regression tests. Rings that never send 04 0e keep the tail rule. Details, and a reply to your PR offer, on #63.