Back-smoothing or not back-smoothing? Is that the question?

As many will have seen, the Dexcom G7 never had, and recently the G6, has removed back-smoothing from the apps on the phone, for various reasons. Does that matter? To most people, probably not, but let’s have a look at comparisons of the data with the two devices plugged into me.

In all the images of data side by side, the version with the green dots is a Dexcom ONE visualised via Drip Companion App setting, and Blue dots are Decom G7 visualised using the companion app setting in an xDrip Variant version, which allows multiple xDrips to be run on the same phone. This allows us to:

  1. Visualise the two side by side;
  2. Work around the limitation that makes screenshots in the Dexcom G7 app impossible on Android devices.

What we’ve heard from various user groups on the Social Media is that they feel that the G7 doesn’t produce as smooth data as the G6 (or the ONE), so here are a few pictures of the ONE and G7 side by side to try and see if that’s true in an n=1 sense, and what the impact might be.

It’s worth mentioning that both these sensors were applied at the same time and are therefore the same age.

Side by Side

In both these pictures, screenshotted from widgets on a Samsung phone, there appears to be more Jitter or noise in the Blue dots than in the green dots. If we then dig into the underlying data within xDrip, you see the following:

Some of the data here (pre-5.30am) can be put down to compression lows causing jumpy readings, however, after 5am, there is a notable lack of smoothness in the output, compared to the green dots of the ONE. At this point, the sensors should both have overcome their first couple of days of instability, as both were a little over two days old. 

But even now, when we’re seven days into the sensors, there’s definitely a difference in the readings, and still some clear jitter, even though it seems to have calmed down a bit on the G7.

So how much does this “noise” matter? .From an everyday perspective, perhaps not too much, although, it could interfere with your reading at a point in time when you were perhaps about to dose insulin for lunch. The lack of backsmoothing, also doesn’t really matter greatly in this use case.

But what about with an AID system? That’s a very different question.

Jitter and AID systems

The amount of noise that can be seen in these shots of the G7 is probably too much for a non-filtered system to work with. Where a system is delivering correction boluses, a sudden sharp jump might encourage over-correction resulting in delivery of too much insulin. But most AID systems are smarter than that, and use something to manage that jumpiness, for example, something like a Kalman filter, which is, I understand, how CamAPS FX deals with it. 

Similarly, in the Open Source world, a smart individual has written a smoothing algorithm to reduce the jumpiness of the data, that is, in essence, not a long way from a Kalman filter. This is available in Dev in AndroidAPS right now to test out. I’d recommend that Loop might perhaps want to introduce similar functionality with the microbolusing code that is now available, to enhance the safety of the system. This also all helps with the variations outside of this level of jitter, from compression low rebounds, for example.

What’s causing this jumpy, noisy data?

So far, I’ve tried three G7 sensors and seen the same across all of them. Others have also used multiple sensors and had similar difficulties. My initial speculation was the difference in how the sensor sits in tissue. In addition, it would suggest that maybe the onboard algorithms in the two different sensors have differences.

In the G6, and previous Dexcom devices, the sensor is at an angle into the body tissue. In the G7, it is vertical. I assume that this somehow makes it less stable and more prone to move within the scar sheath that it makes on entry. But that is only speculation. Since then I’ve heard that others have discussed this issue directly with Dexcom, and had a similar opinion in response. It’s somewhat frustrating to see this happening, and one wonders what the end result will be. It also makes me wonder just how much “magic” is going on in the Abbott sensor algorithm, given that all those sensors are vertical rather than angled.

Any impact on commercial AID systems?

This will depend entirely on how they use CGM data. If the don’t rely solely on the Dexcom data and apply some kind of filtering of their own, then I suspect that the key point will be testing. If however, they rely solely on the data, then I suspect there will be more of a delay in releasing G7 enabled devices as they figure out how to manage this. Unfortunately, it’s not clear from any of the documentation who does what.

So where does it leave us as end users? In the open source world we’re making progress. In the commercial world? If you’re already managing filtering, probably not too worried. if you’re not? Then you’e a whole heap of work to do.

Be the first to comment

Leave a Reply

Your email address will not be published.


*