Very low BG displays incorrectly

[mortenfyhn]

Don't remember if I already fixed this but when "Below 2.8" the watchface didn't update.

[mortenfyhn]

2026-08-22-g0-v51-bg-lo.txt

[palmarci]

Moved to the watchface repo — pure display bug, no backend involved: mortenfyhn/pebble-glucose-watchface#10.

[palmarci]

Reopening the analysis: this is a backend issue after all, not a pure display bug.

Went through the log Morten attached above (2026-08-22-g0-v51-bg-lo.txt).

At 21:01:59, 21:07:00, 21:12:00 and 21:17:00 (four consecutive CGM readings, 5-minute cadence, 15+ minutes straight), the firmware logged:

SAKE: CGM edge rec 0e c3 00 00 4d 1c side=0

Decoded, each of these is a genuine 0 mg/dL off-scale marker, and side=0 means minimed_status_sg_below()/minimed_status_sg_above() both returned false at that moment. In minimed_sake_read.c's prv_parse_and_show():

if (!below && !above) {
    minimed_sake_log("SG: 0 marker, skip");
    return;  // BG display stays frozen at whatever it showed before
}

So the watch never shows LO here — it just sits on the stale value. That matches "when Below 2.8 the watchface didn't update" exactly.

But right after the first marker, at 21:02:02, the firmware also logged:

SAKE: annunc type=0x33b id=4049 status=0x0f sil=0 seq=680785 base=0

0x33b is "Severe low SG" in our own annunciation table. So two independent signals (the CGM stream's 0 mg/dL marker, and the annunciation stream's 0x33b) both agreed the glucose was off-scale-low for at least 15 minutes straight, but the third signal the display logic actually gates on — minimed_status_sg_below(), which comes from a separate IDD status/TAS field (SENSOR_MSG_SG_BELOW in minimed_status.c) — never flipped true during that whole window.

This dependency is unchanged in current dev/v4.36.2, so it's still live, not something the watchface-side rewrite since fixed. The gate should probably also trust the annunciation stream (which clearly saw it) rather than relying solely on the SENSOR_MSG_SG_BELOW status field, which this capture shows can lag or never confirm a real severe low.

[palmarci]

Untested: a fix is on the branch fix/off-scale-bg-from-history, commit ea461db71. It has only been built and host-tested, not run on the watch, and it is not merged. This issue stays open until it is verified.

The reported capture showed the watch skipping four consecutive 0 mg/dL CGM records because the IDD status never named a side. The pump's event log did: the SG Measurement record for each of them carries the below-range code (0x030d), and the history read that the "History Event Recorded" bit triggers already returns it (that bit was set on each of those readings).

The watch now reads the off-scale side from the newest SG record in the log, and re-reads the skipped CGM record with the side known, so LO (or HI) shows. The backfill sets the same state after a connect. A normal reading, or an "updating"/"starting" code, clears it. The IDD status still counts as before.

New log lines to check on a real off-scale low: minimed: SG history edge -> 1 and then *** BG LO ***. HI is assumed to mirror this (code 0x0308) but has never been captured.