I’m interested in whether others have encountered this bug in the G6 Android app, which has almost bitten me several times, and possibly bit me bad once.
I’ve observed it a number times in the previous version of the app. I’ve seen enough to know that it also appears in the recent update (v1.8). I’ve pretty sure it also occurs in the receiver. I have no way to check the iOS app.
Report it? I did report it to Dexcom, but customer support is a brick wall trained never to bother software development. I’ve told my endo, who was surprised.
OK, I’m not intentionally being coy, just wanting to set things up right.
Problem: if a fast fall alert is ignored three times (or maybe it’s four), then that alert stops sounding, and more critically, blocks a low alert.
Lots of qualifications there. But “blocks a low alert” should get everyone’s attention.
Start with the fast fall alert. Probably all Dexcom users quickly learn that it doesn’t much matter whether you acknowledge the alert. Unlike with a low alert, if the fast fall condition still exists five minutes later, it will sound again right then. So shy bother? Whether it sounds again in five minutes depends not on your action but solely on whether the condition continues to exist.
But there is a difference after it sounds three (or perhaps four) times without acknowledgement. At that point it blocks. You can see one result in this screenshot of my lock screen: The alert is for a fast fall at 171, but the current reading is already down to 139:
This is actually 15+ minutes after the alert – I also have screen shots where the current value was 160 and 150. Normally the alert would be updating the bg value every 5 minutes. And though the screen shot does not include sound effects, I know that the fast fall alert had been sounding until my bg reached 171, and not afterward.
Eventually the alert will sound again if the fast fall continues to exist. I’ve seen it happen but have not ascertained how long it takes. Fifteen minutes would be consistent with other parts of the app.
Now, that’s bad enough. In an extreme situation, the app could be giving you fast fall alerts at 170 and go silent until you reach (say) 100, still in fast fall.
But even scarier, that locked fast fall alert doesn’t just block subsequent fast fall alerts. It also blocks the low bg alert! So – with my settings of 2 for fast fall and 90 for low alert – I could have a readings sequence of 130 (start), 119 (FF alert), 108 (FF alert), 97 (FF alert), 86 (low and fast fall but NO ALERT), 75 (ditto). I’m down to 75 in fast fall and the app is silent.
I do not know whether an urgent low ALARM could also be blocked. I really don’t want to do the experiment necessary to determine.
I assume all the above stuff also happens in reverse with fast rise and high bg alerts. Those don’t happen to me as often and I pay them less attention, so I haven’t documented them. (As they say, low bg is dangerous on a time scale of minutes but high bg is dangerous on a time scale of years.)
This MAY have contributed to a nasty episode on August 26, 2018.After eating a large mango, my bg was 350, so I took 2 units of Humalog – no more because I was leaving on a bike ride. At the time I was using the G5 receiver, After a few minutes it started buzzing fast fall, but this was OK because I was so high. About 40 minutes later, the last thing I remember is pulling off the road into a sidewalk. A few minutes later a passerby called 911, and I woke up looking at an EMT. While my analysis pointed at a perfect storm of about half a dozen causes, I was not then aware of this possible additional cause: if the fast fall and low alerts were blocked, I may have continued riding when I should have stopped and guzzled the glucose syrup that was in my pocket.
This of course depends on the receiver having the same bug as the Android app. I keep trying to turn on the receiver when a fast fall is expected, but I have not managed to turn on the receiver at the right moment. But otherwise they seem to work identically except for parts of the UI and capabilities the receiver simply lacks.