Missing Data - A Tale of Two Systems

We've been lucky so far. We're on our third New Enlite sensor, using the same Guardian 2 Link transmitter and, with the exception of a 20-30 minute data 'freeze' last night we've only had a couple of unexplained 'glitches' in data transmission, always with a transient loss in data.

Others have not had such a smooth ride. Lewis has been blogging about his experiences, good and not so good, and has clearly had more data loss and CGM-drift issues than us.

Lewis' Dad was kind enough to share some of Lewis' raw CSV output data (from the Medtronic CareLink software - let's call it functional rather than a pleasure to use :-) ) and a snap of pump screen showing the data loss overnight:-

https://growingupwitht1d.wordpress.com/

Lewis and his Dad have already taken steps to reduce local RF interference (moving WiFi connected kit and turning off other 2.4GHz devices) but are still seeing data drop-outs.

I took a look at the CSV output, and specifically the "Raw-Values", which hold a number of status flags. I focused on four parameters:

• SENSOR_EXCEPTION=sensor_error [All is not as it should be in the 640g's world...]
• NOISY_DATA_INDICATOR=true [This could mean the transmitter is not happy with the ISIG - the weak signal from the Enlite - but I think it refers to transmission noise detected?]
• BACKFILL_INDICATOR=true [I assume this flag means the system has pulled some delayed data from the transmitter]
• DISCARD_DATA_INDICATOR=true [Not at all happy, throw data in the bin]

Please feel free to comment and add corrections to these assumptions.

So what did I find?

Data loss occurred for between 10 - 20 minutes during four overnight episodes:-

• As expected, the CSV file shows sensor glucose (SG) loss at the points marked by the gaps in the sensor plot line on the pump itself.
• The SENSOR_EXCEPTION=sensor_error flag was raised for each episode.
• The NOISY_DATA_INDICATOR=true flag was present for three out of four incidents.
• There was no evidence of delayed data re-transmission (using the BACKFILL_INDICATOR flag).
• There were no discarded data-points (using the DISCARD_DATA_INDICATOR flag). It should be noted that there were no episodes of a sensor error flag being raised and a SG value being recorded, so that's good to know.

So what's going on? Here's a possible answer, which could be wrong...

RF interference is corrupting data frames being sent by the Guardian 2 Link transmitter. After each missed packet, the pump asks the transmitter to change channel to find a clear(er) frequency (as per page 15 of the Guardian 2 Link manual). That process takes 10 plus minutes depending on how busy the channels are and data is resumed.

That might explain three out of four episodes (the ones with the noisy data flag raised). However, for the fourth, and longest (20 minute) data gap, I can't find an obvious reason: we see a Sensor Error but no noise flag.

What I don't understand from reading the manual, is why Lewis' missed data-packets aren't being re-transmitted and the SG data gaps remain visible?

Jumping back to Janki's system, last night we noticed apparent sensor loss at ~8pm and around 20 minutes later I manually cycled the sensor On/Off (that's the second gap in the graph below):-

On the CSV data, there's no obvious (to my mind) indication of why things packed up at 8pm: no sensor error flags, no noisy data warnings. What we do see is that once restarted, all but one of the missing data points are re-transmitted (with the delayed flag):-

What I find interesting is the very different log patterns from the two systems...

Janki does get the occasional sensor error flag (the first one came a week after we started using the pump and we're getting SENSOR_ERROR flags around 0.1% of the time i.e. ~ 1 in every 1,000 data samples; that's an average of 1 every 3-4 days of operation).

We also see a handful of NOISY_DATA flags (0.2% of readings), but nothing like the rate Lewis experienced overnight.

The most striking difference in the two datasets is that the vast majority of the time, if we drop a SG data point, it is usually recovered (delayed re-transmission). Remarkably, for the first sensor, we didn't lose a single SG data point on the CSV output, with ~1% of the data (2-3 SGs per day) received delayed by 5-10 minutes. The near complete recovery of data, with a delayed re-transmission is obvious in last night's unusual data; more often we'd see 1 or 2 isolated packets.

So, two 640gs with new Enlite sensors, Guardian 2 Link transmitters and two very different experiences in terms of data connectivity and recovery. More digging is required to fully explain these differences, be they due to the kit or the different local RF environment.

Strange things are afoot at the Circle K...