G6 app bug blocks alerts

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.

I don’t personally use the fast fall alert. Just the urgent low soon, low and urgent low alerts. In my experience if the app has already told you that you are either going to be low soon or are falling the low alert will not sound but the urgent low will still work.

I had a pretty bad low once from this quirk where I was woken up by the urgent low soon alert, I treated it with glucose and went back to sleep but I remained low for a considerable amount of time without getting any more alerts until by BG was 55 and dropping. I too called Dexcom about this but didn’t get a satisfactory explanation either. All I was able to determine is that it wasn’t considered a glitch. It is built in to the software that way, although lord knows why.

I haven’t noticed the issue that you mention. But, I will keep an eye out for it.

My ‘fast fall’ alarm (via the app) is set to a police siren, so I tend to stop what I’m doing and acknowledge it. Except when I’m out walking the dog near the police station. I have, several times, assumed that it was an actual police siren sounding in the distance and didn’t recognize it was a Dexcom alarm. In that case, it did sound a multitude of times. That’s how I eventually realized it was a Dexcom alert.

I’ve been having a bunch of highs, so I think I could easily run some tests.

Do we have any well thought through test conditions for this event that would help clarify things?

Test conditions: the problem for me is that the test conditions are situations I try to avoid. :confounded: Fast change, especially when nearing a limit.

I suppose I see it most often when my bg has been high and I finally get it dropping. If it’s well over 200 when I first get the fast fall, I can let it sound several times before I take action. That was the case in the image I posted.

Letting it fast-fall down to my low alert setting is scarier. And of course I can’t predict exactly when it will get there. Sometimes I’m trying to catch it happening, but then either the locked alert times out first, or it stops dropping so fast, and I don’t get an observation.

A fast rise of course is less scary, but in that case I’m likely to be trying to treat even more quickly – I can stop a fast fall pretty reliably with a big gulp of glucose syrup, but a fast rise can take longer to deal with, depending on what caused it. (One thing I find interesting about CGM is seeing the result of taking glucose – a fast rise that suddenly peaks and stops.)

I suppose what would help clarify the most would be if I stopped and made notes when I started getting a fast change alert. The reason I’m not certain how many alerts are needed to block is that I forget how many I’ve ignored. :roll_eyes:

That’s funny about the police siren. I tried a lot of sounds and returned to the defaults – at least they are the defaults IIRC – because a scale (up or down) for fast change and an arpeggio (up or down) for breaching the limit has an easy-to-remember symmetry for me. I save the siren for urgent low – it seems to be able to awaken me even when I’ve slept through the milder alerts. :sleeping:

Oh, I didn’t mention, I have the fast-fall alert set for 2 points/minute. Obviously that makes it more likely that I’ll see that alert, compared with 3/min.

Just a few minutes ago, I got this sequence:

168 (alert sounded, did not clear)
153 (alert sounded, did not clear)
143 (alert sounded, did not clear)
136 (alert still showing but did not sound, did not clear)
129 (alert gone)

I did nothing to stop the fall until after the 129. IOW, I cannot plan on any event continuing. But the situation at 136 demonstrates the problem; it should have sounded again. (For those who don’t use the fast-change alerts, they appear to be based on an average of the past three intervals. Thus the drop from 143 to 136 is still in fast-fall because of the previous two intervals. I’ve seen cases where the last change is a rise – have taken glucose – yet I get one more fast-fall alert.)

Oh, why a fast fall? Took lunch insulin, but then that persimmon looked so good I had to eat it right away. Ah … almost like pure sugar. Quick rise, then quick fall.

1 Like

I don’t use the fast fall alert either. I do know it’s a toss up for me to set the urgent low soon every 15 minutes or 30 minutes. I hate the every 15 minutes because it’s like Pavlov’s dogs, you are tuned that you have to eat something when it goes off. I don’t like that signaling to my brain when whatever I took doesn’t have time enough to really hit completely. So I prefer the every 30 minutes.

I too got hit hard once, when I consumed something thinking I would be okay, but I never went above my low alert and kept dropping until the reaching 55 soon came on. I started dropping from a miscalculation of exercise effects, so it hit pretty hard. I wish they had a handy “snooze” button. You could “snooze” it to alert you again if wanted. That way you could have it alert you again if you are low in 15 minutes etc under certain circumstances.

I don’t have anything to add to what others have already commented. I wonder if you’ve considered attempting to manage the underlying cause that makes you vulnerable to missed fast fall or rise alarms.

It appears to me, and I may be mistaken, that the real source of your problem is excessive swings of blood glucose. Is this happening every day or several times per week? Perhaps this only occurs once per month. Please forgive me if this does not apply in your case.

Since you use the Dexcom G6, the standard deviation (SD) and coefficient of variation % (CV) measures provide information about your glucose variability. High glucose variability has been demonstrated to go hand in hand with an increase in hypoglycemia.

I don’t discount your observation that the G6 is letting you down in its failure to warn you about rise and fall rate alarms. But I wonder if your efforts may be better rewarded by asking yourself about the root causes of the need for these alarms.

Hi Terry,

I’m not really trying to address handling the effect on me. I’m trying to create publicity that might persuade Dexcom to fix an obvious bug. Reporting it directly by an individual seems to be about as effective as a similar effort related to the federal government.

I leave the fast-change alerts on because they, well, alert me. Except for one case 2-1/2 years ago, this behavior is just something I have to keep in mind. That occasion is a long story, a perfect storm. I was not aware of this issue at the time, but it’s not the most important of the issues that interacted then.

Persuading Dexcom to fix the bug might protect other, new users who are not aware of this odd behavior.

1 Like

Sorry to raise an issue you did not pose. You’re right to alert others to the bug you’ve found.

Huh? Where would a good forum be without topic shifts? The earth might cease its spinning …

I have a g 6 on iPhone and tslim.
I have a different issue w alarms that are just irritating

I get a predictive alarm at 160, hey you are predicted to go over 180. And that’s fine but then it alarms at 180 and will not alarm again as it heads up so if my tubing comes out it won’t warn me again. After I take insulin and it’s returning back toward the 180 it starts alarming again.

So it seems that it alarms as you approach the limit from either side but it doesn’t care which side of the line you are on.

It is bizarre but I just have learned to accept it.
I can’t go very long without checking it anyway out of habit.

1 Like