Minimizing CGM gaps

This article describes the way I’ve been managing my CGM so that I get continuous data, with only a few 5-minute updates missed for many months now.

For most people using CGMs (such as the Medtronic and Dexcom systems) each time they start a new sensor there’s a big gap in their CGM coverage. Not just the time to remove the old sensor and insert the new one. There’s then a 2-hour gap while the system “warms up” the new sensor.

Even the Libre system has a 1-hour warmup.
The Medtronic system also needs you to recharge the transmitter before starting the warm-up.

Am I too picky?

Many people are happy to accept a gap where they run without CGM, but I think most of those people are running on “manual” where they only make corrections (boluses, temp basals, food intake, etc) several times a day. But for people like me who have their pump adjusted every 5 minutes by our closed-loop systems, the stakes are different.

My pump basal rates have been tuned so that in general I can go for long periods with no adjustment, but that’s a fallback for if my loop was to fail. If I’m eating a meal, a snack, drinking with friends, doing exercise, being stressed, or just living life in general then I’m definitely more comfortable when I know my loop is making real-time adjustments.

Note that on average I spend about 97% of my time between 3.9 and 7.8 mmol/L (70-140 mg/dL) and that’s largely due to my loop doing its job. A CGM outage means a loop outage, and I then have to fall back to occasional fingerpricks and coarser adjustments. So I do what I can to minimise those outages.

Calibrating a new sensor

The loop keeping my BG stable also means that when it’s time to calibrate the CGM, my BG is much less likely to be changing (if it was changing, that would mean it’s not the right conditions to calibrate unless I want to end up with an inaccurate CGM). Calibrating on a loop is so much easier than without a loop.

It might be surprising to see how easy it is for your BG to be rising/falling after 2+ hours of CGM blackout, right when you’re trying to get good calibrations going for the new sensor.

Sensors take a while to stabilise

Many people find they can’t really trust the numbers from a sensor until it’s been running for at least a day. This can be due to multiple issues:

• Insertion trauma. It can take a while for the body’s inflammatory reaction to the new sensor to settle down. In some people a lot longer than 2 hours.
• Initial calibrations being sub-optimal (see above) and taking a while to be “flushed” out of the system.

“Pre-soaking” is a common technique for managing insertion trauma. This is where we insert a sensor many hours before activating it. This may be complicated with the upcoming Dexcom G6, where the algorithm works by assuming there’s some insertion trauma going on. The G5’s in-transmitter “native” calibrations seem to assume a little, but the G6 even more so.

Note that with a Dexcom sensor it’s important to have a transmitter installed into the sensor to physically protect it (even if that’s just a dummy transmitter).

Overlapping Libre sensors

In the Libre system there’s no shared transmitter, with just a new sensor every fortnight. When I was using this full-time I would know when the current sensor was going to end (the system gives you warnings) and insert a new sensor on my other arm 6-12 hours beforehand.

If you’re using a single device (e.g. Libre Reader) then it will only talk to one sensor at a time, so there’s still a 1-hour gap after starting that new sensor. But if you have two Readers (or a Reader plus LibreLink on a phone, or a MiaoMiao/Blucon transmitter) you can start the new sensor an hour before the old one expires, and achieve almost continuous data.

Overlapping Medtronic sensors

I know people who have two Medtronic transmitters, and use a similar pre-soak and overlap routine. They still have a short outage while warming up the new sensor (as only one transmitter can be connected to the pump or phone app at a time) but they have streamlined the process.

This can be useful for people using Medtronic’s 670G closed-loop system, but not everyone is able to afford a second transmitter.

Overlapping my Dexcom sensors

I have to admit my privilege here: I have more than one G5 transmitter. With replacement batteries and rechargeable options this can be a lot more cost-efficient than the standard Dexcom list price of AU$540 for each 3-month transmitter. But even so it’s not easily accessible for many people.
Now that I’m set up I have minimal ongoing transmitter cost. But given that I have this privilege, let me describe what I’m able to do with it.

Eventually my sensor will show signs of degrading. Those signs can include: higher-than-normal noise levels (“jittery” or “jumpy” data), unusual susceptibility to compression lows, or drifting calibration needs.
When my current sensor is showing these signs, I put a second sensor in with a freshly-charged and reset transmitter. How long a sensor lasts for will vary, but for me over the last two years it’s been averaging 25 days each before inserting another.

Before I had two transmitters I would pre-soak with a dummy transmitter, and then swap my transmitter into the new sensor at changeover. But now I’m able to seal up the whole thing under a layer of Fixomull Transparent dressing as soon as it’s in. That dressing not only provides added stability (which can help with sensor longevity) but also helps reduce water issues when showering/swimming (sometimes we can get slight “spikes” and outages when water gets between the sensor and transmitter).

Managing two transmitters

As soon as the new sensor and transmitter is in place, I start the sensor using a different instance of CGM software than the one that’s managing the older sensor (and feeding my loop). This means that I can see how the new sensor is behaving. It usually jumps around a lot for quite some time, especially compared to the older sensor. After it’s been running for a few hours I sometimes delete the initial calibrations and give it a fresh start.

Having confidence in the sensor

Only when I can see that the new sensor is behaving better than the old sensor will I switch things over so that the loop uses that sensor. Sometimes that can take longer than a day.

No more putting in a new sensor and wondering if it’s working right. Is it a dud? Will I need to replace it? Maybe so, but hopefully meanwhile my system is still running off the old sensor (even if it is getting a bit noisy at that point).

Yes I’m wearing two CGM sensors for a while, but then I get to remove the old one and proceed with one that I trust.

Using the Dexcom app (or Tandem pump)

The Dexcom app only allows you to communicate with one transmitter at a time from one phone. But the calibrations and sensor session are maintained in the transmitter, which does give some flexibility.

If I started the new sensor on a different phone (e.g. a cheap Android) then once it was stable I could disconnect that phone from the transmitter, and get my main phone (or Tandem pump) to join the running sensor session on the new transmitter. Almost no outage!

Do note that the Dexcom phone app will not let you connect to a different transmitter unless you’re connected to the internet and it’s able to reliably communicate with the Dexcom servers. Not something you want to be trying during a trip away from civilisation, on a plane or ship, or during a natural disaster!

Using xDrip+

This is what I usually use, and I don’t have to carry around a second phone to manage the second transmitter! Plus I’m not reliant on internet access in an emergency.

Firstly, unlike the Dexcom app xDrip+ is able to continue using a sensor for long periods, without the 7-day session plus 2-hour warmup gap imposed by the Dexcom app. Usually gaps only come into play when it’s time for a new physical sensor. But even those we can eliminate.

I have multiple “build variants” of xDrip+ installed on my phone. These are usually used for developers to test things without disturbing their primary CGM, but I use them in “production”.

Each one has its own “widget” on the Android home screen, which makes it easy to visually compare the sensors.

It’s also possible to use Android’s split-screen mode to compare things in more detail.

Each app has been configured with almost exactly the same settings. It can be a tedious process getting this set up as they don’t share config files, but by taking a photo of a config QR code with a second phone it is possible to import those settings back into a different instance of xDrip+.

Switching sensors in a multi-xDrip+ config

The description from here on is slightly out of date (I’m experimenting with a variation to see if I can solve some of the configuration issues) but at least shows how I was using it for much of 2019.

Only one of the xDrip+ copies is set to:

• Upload data to my Nightscout site.
• Broadcast data to AndroidAPS on the same phone.
• Give out-of-range BG alarms, along with alarms about missing data.

I could have some of the alarms instead managed centrally by AndroidAPS, but xDrip+’s alarm system is much more configurable so I prefer to use that.

When I’m calibrating I feed the same numbers into each CGM app. I have experimented with having AndroidAPS broadcast the calibration to all the apps, but sometimes one or more of them will ignore the calibration (even though they have received it) so I prefer to do it manually.

When it’s time to switch my loop from the old sensor to the new one, I go into the settings for each instance of xDrip+ and either turn off or on the appropriate features. Then on the next update AndroidAPS receives data from the new sensor, without any changes on its end.

Managing sensor age in Nightscout

I do put CGM Sensor Insertion events into Careportal in my Nightscout site, which lets AndroidAPS and the SAGE plugin both track the age of the current sensor. Because I enter these events via AndroidAPS I don’t have to be connected to the internet at the time. It stores the updates to send to Nightscout later.

But I have to make a manual note as to when I inserted the new sensor, and then wait until after I’ve switched the loop to the new sensor. Only then do I put in a (back-dated) CGM Sensor Insertion event for the current sensor.

So far the only side-effect of this is when reviewing CGM history. Just because a sensor-insertion point is shown on the graph doesn’t mean that the BG data immediately following it was using that new sensor. For now I insert a Note event at the time I do the switch.

Beware! Not a turn-key solution!

Changing the settings in multiple xDrip+ instances is not a simple process. There’re usually at least 5 settings I’m tweaking in each copy. Plus updating the records in Nightscout.

This is not fool-proof, and getting it wrong could mean I’ve for example left some of the important alarms disabled. Or the loop is receiving two sets of data. So I don’t advise that people follow my example exactly.

But consider it in the light of what is technically possible. Imagine a future system that could manage multiple sensors from within a single CGM application. Imagine one that dynamically compared each to determine a more-trustworthy value.

In the meantime, I’m liking living with a loop that runs 24 hours a day every day.