Enlite Sensor Error Flags - Closing in on the Issues?

We've been lucky with most of our new generation Enlite sensors with Janki's 640g system. We did however have to replace a sensor last week after it finally gave up in the morning after around four days of service. The writing had been on the wall, with data drops and more 'rogue' values popping up and a 'reboot' not solving our issues.

Clearly I jinxed things by writing about how well the earlier sensors had performed on Janki :-)

The current sensor is performing well.

We've also been lucky enough to be able to set up a little "experiment" last week (don't worry, no ethics approval required...) as we've been on holiday, getting away from it all (apart from T1D of course). And that includes most of the 2.4GHz gadgets (ours and neighbours) that could feasibly interfere with Janki's Guardian 2 Link transmitter and pump. We also had mobile phones set to Airplane mode overnight.

As I posted a few weeks back, I thought it was unlikely / impossible for RF interference to corrupt SG data from the transmitter to the pump. What was possible is that data would be delayed (or lost) due to excessive interference.

So what have we found?

The Sensor Error flag appears to be independent of RF (radio-frequency) interference.

I must stress that this is for our system. It doesn't mean that the flag can't trigger due to RF interference, but based on the error-rates we encountered last week (across two sensors), it must be a small element (if any) of the total. The source of our sensor errors appears to be strongly correlated to the Enlite sensor and not the local RF environment. In fact we had a particularly high error-rate, due to a rogue sensor for part of the week. Once that sensor was swapped out, we had no Sensor Error flags.

I have asked Medtronic UK to confirm what all of the sensor data flags mean and they passed on my query to the US a while back. It would be nice to have them officially confirmed and explained so we can all work towards removing as many SG data issues as possible, particularly for users who haven't been as fortunate as us in our experience to-date.

It's a shame there's no one in Medtronic UK who is able to focus on the more technical / data queries, although that's not unusual in this day and age of global medical device companies (I get routed to the US, Israel or Germany for heavy-duty help with the MDs I use at work, which, with my scientist hat on I find rather depressing, in terms of UK investment in these skills). I should say support from our local Medtronic reps in other regards has been excellent; these questions and issues are just outside their remit.

So what's next? For us, it's now a case of digging through the error logs. Of particular interest to me is to look into the source of the apparent SG 'flutter' that sometimes accompanies these errors. My gut feeling is that this is a feature of the SG calculation, either with the algorithm's averaging of recent ISIG or the calibration factor calculation, or both. More soon...

By the way, whilst we could have done the ice-cream with a pen and BG readings, we certainly felt more confident dealing with a small holiday ice-cream with a pump and CGM available and it was nice for Janki to be just like all the other kids and be able to enjoy a (carb-packed) treat :-) When you're three, it's never too cold for ice-cream!