In a recent post [Why I overlap CGM sensors] I showed the normal (for me) behaviour of a Dexcom G6 sensor starting. The first 24 hours or so can’t be trusted, although it will usually eventually come into line by itself.
Obviously when using a Dexcom G6 transmitter this eats into the 10-day limit to sensor lifespan that the transmiter imposes. No so much of a problem with Anubis transmitters and their 60-day limit.
“Pre-soaking” a G6
So I’ve been doing some experiments where I apply the new sensor and place the transmitter in it, but leave it for a day before starting the sensor session. Here’s a recent example:
The pink dots start appearing once the warmup period has finished, and as you can see this bcomes stable a lot more quickly. It indicates that most of the first-day instability for me is probably due to a physical reaction to the sensor rather than significantly also affected by the transmitter’s “insertion trauma compensation” algorithms.
We assume the numbers would have been jumping around as usual in that first day, but we just don’t see that as the session hadn’t been started yet. When stuck with a standard Dexcom G6 transmitter this does at least give me one more day of sensor data at the end before the transmitter terminates the session.
It’s not so important with an Anubis transmitter where I can see the weird data and when it settles (although that does require me to have enough software to track two sensors).
What about the G7?
The G7 doesn’t allow us to pre-soak. The sensor session is started as soon as we lift the inserter away from the sensor (it’s triggered by a magnet moving away, akin to the way early Dexcom G4 transmitters were auto-started when removed from the box).
Earlier in 2025 I used a string of six G7s and came to the conclusion that the data wasn’t good enough for use with automated insulin delivery. But this week I did have an opportunity to test another one.
So here’s the first day of a G7 (alongside an already-running G6). Data starts from 30 minutes after insertion.
While it does seem to have trended low overnight, within about 12 hours it was fairly close to reality. That’s a lot faster than most of the G6s I’ve used. Of course I had hypo warnings disabled for that sensor as I expected it to go weird.
So if I have to use G7 sensors I’ll want to wait 12 hours before switching to the new one. Using single-sensor software this just means inserting the new sensor 12 hours before the old one is due to finish, switching to the new one when the old one finishes (hoping it doesn’t die early), and then getting the remaining 10 days of the new sensor’s life (they should last 10.5 days each).
G7 problems
However, there are a few other issues which are still putting the G7 out of the running for my AID use:
Gaps in connectivity
This isn’t shown in these graphs, but the G7 has a horrible habit of not being contactable for random periods. When it does finally reconnect it will back-fill the missing data, but meanwhile the system has not been able to make insulin decisions. The longest outage I commonly see is 25+ minutes, which especially after a meal is not a good amount of time for the system to be hamstrung.
As an example, right now this G7 sensor is showing that it’s only been connected on-schedule for 96% of the last day. That means that out of the last 24 hours, it’s missed almost an hour of real-time data transfer.
Meanwhile the G6 sensor is showing that out of the last 24 hours it’s missed nothing. That is, new data has been reliably supplied every 5 minutes.
We can cope with a bit of missed data, but once it builds up enough the performance of the AID system can start to suffer. My experience over the last 5 years can be summarised as when the real-time capture rate gets down to 97% I start to look for what might be wrong with the system (or recognise that I might have left the receiving device behind in another room for a while by accident). In this case the G7 and G6 data are being received by the same device and both sensors are on the same side of my body, so the rates should be comparable.
Incidentally, some of the earlier G7s I tested came in at around 93% capture rate.
There’s obviously more problem with longer gaps (as compared to a 50% capture rate where it might be reliably connecting every 10 minutes instead of 5). The G7 definitely has longer gaps which aren’t identified by that single capture percentage metric.
But in cases where the gaps are not long, with any CGM system if it gets down to 95% I know something is seriously wrong and it’s going to affect the glycaemia outcomes. With longer gaps it’s worse.
Noisy data
In this graph the G7 sensor (pink) is a few days old, but as you can see it still jumps around a lot. It’s “noisy”. G6 sensors can occasionally have noise too, although that’s usually a sign that the sensor is about to die. The G7 seems to just treat it as “normal”.
Here you can see the pink dots jumping up and down overnight. Not huge jumps most of the time, but still they will cause the AID system to stop/start the insulin flow unnecessarily.
Keep in mind that if the value drops, the system will assume we might be about to go hypo and thence suspend insulin delivery. If this then happens to be a time that the G7 transmitter goes offline for half an hour, when it comes back we might find the actual glucose levels rising.
Conversely, if the data showed a jump up the system might want to deliver more insulin but when it comes back we might find ourself heading to an actual hypo. Good AID systems are designed to be conservative and minimise this risk, but it’s still not ideal.
Temperature sensitivity
Towards the right of that graph there’re some bigger jumps. And there’s a reason.
I’d been working in my home office after a morning online meeting, and the 10:00 rise is the result of my breakfast. It crested nicely around 7 mmol/L (around 130 mg/dL) and started drifting down. Not too bad considering I don’t announce or bolus for my food.
Around 11:00 I had a shower, and this is what triggered the jumps. Something I’ve discovered over multiple sensors is that the G7 is extremely sensitive to hot showers, reporting falsely-elevated values. Once out of the shower the values soon dropped, although they then oscillated around for a while.
This seems to be due to the way the filament is somewhat exposed to the elements through the hole in the top of the transmitter, although with this particular sensor I was trying to minimise that with the entire unit being covered in a single layer of Opsite Flexifix. It can be more extreme with uncovered sensors.
The G6 was covered with a layer of Opsite Flexifix Gentle. Occasionally with uncovered G6s I can see jumps with showers, although it’s unclear how much of that is temperature related and how much is due to occasional water ingress between sensor and transmitter). But with covered sensors G6s are always stable for me, while G7s are very volatile.
G7 still not to be trusted
For now Dexcom G7 unfortunately still proves itself to be an unreasonable system to base automated insulin delivery on, and I’m very glad we still have access to G6.