640g Connectivity - Data Loss and Data Corruption

My post the other day on Connectivity with the 640g has generated a lot of interest - thanks for the feedback and comments :-) That was always intended as a first dip into the whole topic. My initial enthusiasm was driven by looking into the possibility of getting the Medtronic port of the NightScout project running on the 640g. But reflecting on the fact that we're operating in a very crowded wireless environment (2.4GHz) and hearing about issues other 640g users, for example Lewis, have experienced, I thought it was worth revisiting sooner than planned...

Before I dive in, I think it's worth mentioning again, that, overall, I'm very pleased with our 640g performance to date (I have nothing to compare it to of course), including connectivity with the CGM, but clarification of any uncertainly over data integrity would be a significant boost in my confidence in the system for the four years ahead.

I'm discussing general principles here and I'm not armed with any 'inside information' on the workings of the Medtronic i.e. my assumptions might be incorrect..! If you're happy with that, stay tuned for protocols, Weetabix and the tiniest amount of maths :-)

For any wireless Medical Device, Regulators would be interested in assurance that the system can cope with both lost data and corrupt data. As a parent of a little PWD I'm concerned with the potential for both.

Lost Sensor Glucose Data
Data loss because of a crowded 2.4GHz spectrum is potentially going to affect this system at home, school and out and about because of the prevalence of other 2.4GHz devices (some with pretty poor RF "manners"). In my mind it's a case of whether such data loss is ever likely to cause a real-world issue? Well, with SmartGuard intending to 'fire' thirty minutes before a low event, and sensor glucose (SG) values coming in every five minutes, I don't want to lose too many data packets, otherwise that'll negate the usefulness of the predictive suspend (and potentially the low level suspend also).

We currently have a couple of unexplained 'blank' periods where we would expect 'back-fill' with delayed data coming in ten minutes later (according to the manual). I've asked Medtronic for clarification of exactly what we should expect in these situations. In practice, we've not experienced any situations where these transient data drops would have affected SmartGuard. I'll post up some more detail on this shortly.


Corrupt Sensor Glucose Data
Any potential for this - for me, with my Day Job hat on and as a parent - would be my biggest concern. The IEEE 802.15.4 standard incorporates a Frame Check Sequence (FCS) that's added to the end of each and every frame (sensor data packet) transmitted. It's essentially a 'magic number' generated by a pre-agreed algorithm held by both transmitter and receiver (usually the Guardian 2 Link and the 640g respectively for this system). The 640g receives the frame, calculates the 'magic number' (more accurately known as the CRC - Cyclic Redundancy Check) from the contents of the frame it received. It then compares its calculated number with that received in the FCS. If they match, you can be very confident the entire frame was transmitted successfully. If they don't, something went wrong / was corrupted during transmission and the data frame should be binned and a repeat transmission requested.

Medtronic actually confirm they use CRCs as part of their data integrity checks (on page 15 of the Guardian 2 Link User Guide). As CRC is baked into the 802.15.4 protocol (using a 16-bit FCS) I'd have been amazed if they'd somehow removed / changed it (all the common 802.15.4 chip-sets support it so that really would be insane...) Their reference to their 'proprietary data format' should just affect the data 'payload' part of the frame ,nothing else, otherwise we're not following the IEEE protocol.

A simpler analogy is to think of the CGM frame as a barcode, like the one on your packet of Weetabix (popular in this household as stage two of bedtime hypo treatment until our move to a pump). The 13-digit code is 5010029000016, of which the first 12 relate to the product and the last one is the 'checksum' making sure we didn't typo the first 12...

Just like the CGM frame, there are different components to this barcode:

50: Origin (Header / Introductions for the CGM frame)

10029: Manufacturer ( Address / Destination / Info on what type of data packet this is: ISIG or another request, on the CGM frame)

00001: Weetabix :-) (the ISIG data payload in proprietary Medtronic format on the CGM frame)

6: the checksum (the Frame Check Sequence on the CGM frame)

Misread or mistype the barcode and - thanks to that final checksum digit - the chances are you will generate an error and not end up with Rice Krispies instead of Weetabix (although Janki would be quite happy with that :-) )

So, in theory - in theory - you cannot are extremely unlikely* to  get corrupt Sensor Glucose data (or rather corrupt ISIG data - the raw, averaged tiny, tiny current generated by the Enlite) due to transmission interference. It would be spotted and rejected by the pump thanks to the Frame Check Sequence.

*Crudely, the probability of an error getting through is approximately 1 in 2^16 (2 raised to the power 16)

i.e. around 1 in 65,000 frames

i.e. Corrupt data may sneak in once every 7 - 8 months of full-time operation, with SG data sent every 5 minutes (that's assuming no more checks are made on the data packet - I'd hope and expect that they are)

[There are 2^16 possible FCS values for the 16-bit CRC in 802.15.4. If we assume random data and random transmission corruption, there's a 1/2^16 chance of the FCS matching the corrupted frame values by chance...]