Duplicate G7 CGM Sensor Insert

[Knighth4wk]

Hello,

I am using xDrip+AAPS+NS setup. I recently updated to version 20240419 of xDrip and noticed mutiple duplicate entries every hour for CGM sensor start in my NS and AAPS treatments. AAPS is setup to receive BG data from xDrip and upload to NS.

I went through previous treatments entries and confirmed the duplicates started showing up right after updating xDrip to latest stable release.

Current xDrip Version: 20240419
Previous xDrip Version: 20230716
xDrip Data Source: G7 sensor
AAPS version: 3.2.0.4
Nightscout: 15.0.2
Phone: Samsung Galaxy S24 Ultra running Android 14

[Navid200]

xDrip has changed significantly for better performance with G7. You should use a more recent release as suggested in the guide: https://navid200.github.io/xDrip/docs/Dexcom/G7.html

Are you only uploading to Nightscout from AAPS and not also from xDrip?

[olorinmaia]

I've checked my son's AAPS and I notice the duplicate entries are there also. There are no duplicates in Nightscout however, therefor no duplicates in AAPS follow app, AAPSClient which is the app I mostly browse treatments history in, that's why it has been hard for me to discover this. Or if this has been happening earlier.

@Knighth4wk you are sure this didn't happen before 20140419 release? If so it is probably this commit 1d77e78 that has changed something within AAPS how the broadcast information is received. I've asked Milos for advice, I'll let you know what he says.

No duplicates in NS:

Duplicates in Treatments log > Careportal and User entry (They seem to be added every 5 min or recieved BG?):

User entry	Careportal

[Knighth4wk]

I have double checked NS, the duplicated entries are showing there too for me.

The previous version I was using 20230716 did not have this issue.

[olorinmaia]

Are you using NSClientV1 or NSClientV3?

[Knighth4wk]

I am using NSClientV3.

[olorinmaia]

NSClientV1 here. That could be the reason for why you get duplicates in NS and I don't. It's very hard for me to see in the logs why this is happening in AAPS, need help from @MilosKozak or someone more experienced. Here are logs from AAPS in a period this issue is occuring:
AndroidAPS_LOG_1717346137057.log.zip

[MilosKozak]

18:29:32.658 [DefaultDispatcher-worker-7] D/BGSOURCE: [XdripSourcePlugin$XdripSourceWorker.doWorkAndLog():102]: Received xDrip data: Bundle[{com.eveningoutpost.dexdrip.Extras.NoiseBlockLevel=200, com.eveningoutpost.dexdrip.Extras.BgSlope=7.348103020404346E-5, com.eveningoutpost.dexdrip.Extras.VersionInfo=2124052808 c67b74f-2024.05.28, com.eveningoutpost.dexdrip.Extras.Raw=0.0, com.eveningoutpost.dexdrip.Extras.Display.Units=mmol, com.eveningoutpost.dexdrip.Extras.Time=1717345763598, com.eveningoutpost.dexdrip.Extras.CalibrationInfo=-1, com.eveningoutpost.dexdrip.Extras.NsNoiseLevel=null, com.eveningoutpost.dexdrip.Extras.SensorStartedAt=1716739867561, com.eveningoutpost.dexdrip.Extras.Noise=-9999.0, com.eveningoutpost.dexdrip.Extras.SensorBattery=-1, com.eveningoutpost.dexdrip.Extras.BgSlopeName=FortyFiveUp, com.eveningoutpost.dexdrip.Extras.BgEstimate=150.0, com.eveningoutpost.dexdrip.Extras.SourceDesc=G6 Native / G5 Native, com.eveningoutpost.dexdrip.Extras.SourceInfo=G7, com.eveningoutpost.dexdrip.Extras.Collector.NanoStatus=  }]
18:34:33.391 [main] D/CORE: [DataReceiver.onReceive():35]: onReceive com.eveningoutpost.dexdrip.BgEstimate Bundle{ com.eveningoutpost.dexdrip.Extras.NoiseBlockLevel => 200; com.eveningoutpost.dexdrip.Extras.BgSlope => 0.0; com.eveningoutpost.dexdrip.Extras.VersionInfo => 2124052808 c67b74f-2024.05.28; com.eveningoutpost.dexdrip.Extras.Raw => 0.0; com.eveningoutpost.dexdrip.Extras.Display.Units => mmol; com.eveningoutpost.dexdrip.Extras.Time => 1717346064332; com.eveningoutpost.dexdrip.Extras.CalibrationInfo => -1; com.eveningoutpost.dexdrip.Extras.NsNoiseLevel => null; com.eveningoutpost.dexdrip.Extras.SensorStartedAt => 1716739868294; com.eveningoutpost.dexdrip.Extras.Noise => -9999.0; com.eveningoutpost.dexdrip.Extras.SensorBattery => -1; com.eveningoutpost.dexdrip.Extras.BgSlopeName => FortyFiveUp; com.eveningoutpost.dexdrip.Extras.BgEstimate => 150.0; com.eveningoutpost.dexdrip.Extras.SourceDesc => G6 Native / G5 Native; com.eveningoutpost.dexdrip.Extras.SourceInfo => G7; com.eveningoutpost.dexdrip.Extras.Collector.NanoStatus =>   ; }Bundle

Sensor start is received multiple times with different timestamp.
AAPS does deduplication on exact timestamp only

Here:
Sun May 26 2024 18:11:08 GMT+0200 (středoevropský letní čas)
Sun May 26 2024 18:11:07 GMT+0200 (středoevropský letní čas)

[Navid200]

This was a mistake. Rounding to minutes will reduce the number of instances users experience the start time fluctuating as shown in the first post in this discussion and I am attaching the screenshot here again.

If we round to minutes, there will still be AAPS users who will see this if their G7 start time is close to 30 seconds.
So, yes, there will be less instances. But, there will still be people who are going to complain. And what are we going to do then?
I'd rather fix the problem once and be done with it.

I can open a PR to broadcast what we get from G7 as well as what we are broadcasting now.
But, it would be pointless if AAPS cannot or will not use it.
Can AAPS be modified to do the necessary calculations?

[Navid200]

I thought I had a solution. I was going to round not to 0. I was going to round either to 0 or 30. But, I realized that G7 also includes Stelo. Stelo runs for 15 days. Over 15 days, the drift could be 20 seconds! There is no simple solution like a clever rounding that can address that much drift.

[Navid200]

Can we take a step back and look at this from a different angle?
Why does anyone care when the sensor started as an absolute value of time?
Why is it not enough to ask "how long ago did the sensor start"?
That value will never fluctuate.

We can broadcast that value. If AAPS shows that value, instead of the absolute time, the problem will be solved.

[jgslade]

Oh man, this is tricky.

Looking through the AAPS code I think this is how AAPS gets the start time in
app.aaps.plugins.source.XdripSourcePlugin.kt

 fun getSensorStartTime(bundle: Bundle): Long? {
            val now = dateUtil.now()
            var sensorStartTime: Long? = if (sp.getBoolean(R.string.key_dexcom_log_ns_sensor_change, false)) {
                bundle.getLong(Intents.EXTRA_SENSOR_STARTED_AT, 0)
            } else {
                null
            }
            // check start time validity
            sensorStartTime?.let {
                if (abs(it - now) > T.months(1).msecs() || it > now) sensorStartTime = null
            }
            return sensorStartTime
        }

In app.aaps.core.interfaces.receivers.Intents.kt it looks like these are defined:

        // xDrip -> AAPS
        const val ACTION_NEW_BG_ESTIMATE = "com.eveningoutpost.dexdrip.BgEstimate"
        const val EXTRA_BG_ESTIMATE = "com.eveningoutpost.dexdrip.Extras.BgEstimate"
        const val EXTRA_BG_SLOPE = "com.eveningoutpost.dexdrip.Extras.BgSlope"
        const val EXTRA_BG_SLOPE_NAME = "com.eveningoutpost.dexdrip.Extras.BgSlopeName"
        const val EXTRA_SENSOR_BATTERY = "com.eveningoutpost.dexdrip.Extras.SensorBattery"
        const val EXTRA_SENSOR_STARTED_AT = "com.eveningoutpost.dexdrip.Extras.SensorStartedAt"
        const val EXTRA_TIMESTAMP = "com.eveningoutpost.dexdrip.Extras.Time"
        const val EXTRA_RAW = "com.eveningoutpost.dexdrip.Extras.Raw"
        const val XDRIP_DATA_SOURCE_DESCRIPTION = "com.eveningoutpost.dexdrip.Extras.SourceDesc"
        const val ACTION_NEW_BG_ESTIMATE_NO_DATA = "com.eveningoutpost.dexdrip.BgEstimateNoData"
        const val NS_EMULATOR = "com.eveningoutpost.dexdrip.NS_EMULATOR"
        const val ACTION_REMOTE_CALIBRATION = "com.eveningoutpost.dexdrip.NewCalibration"
        const val GLIMP_BG = "it.ct.glicemia.ACTION_GLUCOSE_MEASURED"
        const val DEXCOM_BG = "com.dexcom.cgm.EXTERNAL_BROADCAST"
        const val DEXCOM_G7_BG = "com.dexcom.g7.EXTERNAL_BROADCAST"
        const val EVERSENSE_BG = "com.senseonics.AndroidAPSEventSubscriber.BROADCAST"
        const val POCTECH_BG = "com.china.poctech.data"
        const val TOMATO_BG = "com.fanqies.tomatofn.BgEstimate"

I have some background in programming, but I don't know java/kotlin so there is probably stuff I'm missing.

[jgslade]

I have been running with that patch for about 40 minutes now and have not gotten a connection to my sensor yet. I am getting a no valid timestamp error.

[Navid200]

@olorinmaia Does the AAPS code look at the sensor start time and when it changes concludes that there must be a new sensor?
If yes, can a threshold be added to it? For example, can it be changed to if the sensor start time changes by more than 5 minutes, we conclude that we must have a new sensor?