Monday, September 25, 2017

Libre: the "other" bytes (part 2)

Let's now have a look at the behavior of the Libre thermistor derived data in my archetypal case.

Here is the April 2015 view of the incident.

Quick reminder: in a stable BG situation, the impact of a temperature change (bath), compounded by the Libre predictive algorithm, led to a very significant error by the "official" Libre reader. Outside of outright malfunction, this is the only situation where I felt the Libre could have been dangerous.

And here is the "thermistor" informed version.
From a stable condition, jumping into a warm bath, here is what happened to my son's sensor.

T2: a thermistor value I am fairly sure of, at least in relative terms (see previous post), starts to climb. That is expected.

T1: a thermistor related value also shows a marked increase, at least in my interpretation, it is also noisier, as expected based on my understanding. Please note that it is not shown to scale in this chart. My interpretation of it is somewhat arbitrary, and so is the scaling.

RAW measured IG: the green line, starts to rise. This is most likely due to the sensing site becoming warmer as my kid lies in his bath. Since the mass of his body is huge compared to the mass of the sensor and the enzymatic reaction has its own inertia, measured IG starts to rise more slowly. In fact, it is still rising as my son steps out of the bath.

The official Libre scan gives a reading of 194 mg/dL which almost perfectly fits a basic linear prediction based on the few pas minutes (incidentally, the behavior of that prediction algorithm matches almost exactly one prediction algorithm previously documented by Abbott for the calibration of its "full" Navigator CGM. But then, many prediction algorithms would match).

The actual BG was stable. It was double checked with our BGMeter and fit perfectly with the Libre scans prior to the bath and my own interpretation of raw data.

The key question, at least for me, was what could I do with that data.

Well, I could tell when the temperature was rising, what it seemed to add to the raw BG measures, when and how the delay compensation algorithm kicked in. That may seems a lot, but it could also be summarized as "Max, please do not trust the Libre after sudden temperature changes or when the predictive algorithm shows its ugly side." In practice that is all you need to know.

As far as "standard users" are concerned, I could have come up with an algorithm that reflected what I thought an appropriate correction would be and that could have been used in third party implementations. But let's be real for a minute here:

  • I am not foolish enough to believe my algorithm wouldn't be shaky at times. I can't run clinical tests.
  • the Abbott teams are not fools. I would be delusional if I thought I could better them based on incomplete, guessed information.
  • my algorithms (I tried a few) were of course inspired a bit by my own thoughts and a lot by the literature. Even if they had worked flawlessly, I probably would have knowingly and unknowingly trampled a few patents.
  • as I understand things, covering the sensor would not have been a good thing in general.
  • I did not know, in depth, what I was doing. (and I still don't :) )
  • standard users don't care.
That being said, for a while, running a Dexcom/U. Padova inspired smart sensor algorithm on thermal compensated Libre raw data was fun, if very inconvenient. 

Sunday, September 24, 2017

Libre: the “other” bytes (well, some of them at least)

Personal comment

Back in early 2015, when I started my “running the Libre as a full CGM” experiments, I quickly became aware that the core problem was much more complex than simply figuring out the translation of the so-called Dexcom “raw” signal to human readable values. There’s a reason: in the Libre FRAM, what we are seeing is a real “raw” signal. While the measure of the glucose signal itself is fairly reliable, it is heavily post-processed by the Libre firmware. Specifically - and in no particular order – temperature compensation, delay compensation, de-noising… all play a role. That understanding and, to some extent, my MD training, led me to extreme caution and prevented me from releasing my “solution”, which I knew to be both incomplete and unable to handle some error conditions.

The main driver behind my decision was the well known “first do no harm” (primum non nocere) motto, an essential part of the Hippocratic Oath which I symbolically took. I still stick by it today.
However, by the time I came to realize the full extent of the problem, I had already released enough pointers for developers to build partial solutions upon (and have no doubt my meagre contribution would have quickly been replicated anyway, had the Libre been more widely available back then).

Today, there are a lot of add-on devices that aim to transform the Libre into a full CGM. To be honest, in general, I do not like either the results they provide or their (in)convenience. None of those I have tried delivered results that would lead to an approval by a regulatory agency, none of them were stable for long periods of time. But, apparently, patients still feel they are helpful and there is now a thriving community that aims at improving them.

That is the reason why I will release a bit more information about my own experiments. Keep in mind that I can be wrong.

Personal situation

Max is now a real teen (almost 17), with all the warts of that age. We have been running both the Dexcom G4 (with the 505 algorithm) and the Libre in parallel for more than a year now. This is both a “belt and suspenders” and an optimal results strategy. We mostly use the Dexcom at night, when it is most convenient and the Libre during activities, where we benefit from the added speed. We use what we have when one of them fails (rare) or becomes detached.

As far as we are concerned, the main conclusions shared in 2014/2015 and 2016 on this blog remain true. The Libre is faster and more accurate on the whole. An “anal” calibration strategy brings the Dexcom in the same overall accuracy range, but that strategy is now just a fond memory (teen warts…). The Libre sometimes has a mind of its own (predictive failure and poor temperature compensation. My subjective (and almost statistically significant) impression is that both systems have improved a lot in terms or reliability and post insertion period.

Let me stress that this is not gospel: the performance and the length of reliable operation of a CGM sensor has a lot to do with its eventual encapsulation as a foreign body: your mileage may vary as your macrophages fuse into giant cells and encapsulate the sensor. For some people, I am sure, the Dexcom wire will behave better.

Thermal compensation

As I have shown here before, the Libre and the Dexcom (like all enzyme based bio-sensors) are sensitive to temperature variations (and pH, and potentially other things). This is extremely basic bio-chemistry. You can see an example of this here for example (as a side note, since I am an ill tempered old fart, I quickly grew tired of arguing with non believers Winking smile). Some info on a possible Dexcom temperature compensation strategy can be found here.

That means that the raw signal of a glucose oxydase based sensor has to be compensated for temperature (and ideally pH and pO2, especially for compressions). There are several methods to measure the temperature at the sensing site.

At that point, let me say that I do not know _precisely_ which method is used in which sensor, I can only make reasonable guesses based on patent parsing, probabilities and side indicators. The Dexcom could very well use its platinum electrode wire as a RTD, for example by driving it from time to time with excess current and measuring its resistance.

The Libre thermal compensation

Some of the things I will say in this paragraph are confirmed, some of them are best guesses. Some of them, I am sure will be wrong. Bear with me. The thermal compensation of the Libre signal is described in this patent. Like all “good” patents, there is some obfuscation as many methods are described.

I have worked on the assumption that the Libre follows the 2 point calibration method given in the patent.

Very briefly, that means that the Libre relies on both a “skin thermistor” – that one and its small well in contact with the skin is clearly visible – and a board thermistor. Assuming a certain core temperature (say 34°C), you need to estimate the temperature of the sensing site (below but close to the skin, say 5mm) by measuring a skin temperature that is dependent on the core temperature and the external temperature. A second thermistor, the “board thermistor” located a bit above the skin thermistor adds another measure point that allows you to compute the gradient between the core temperature and the outside world (which can be quite close to the core temperature under clothes for example) if you know the exact distance and thermal conductivity between those two thermistors. In practice, you could also rely on a one point measure (which is what I am doing currently) but there are interesting pluses and minuses to 1, 2 and 3 points gradient estimations.
In a wider context, this method fits with
  • the Libre not having a metallic wire that can be uses as a RTD, could allow lower cost for electrode design.
  • Abbott having the Libre approved for the arm site only (core temperature is different from abdomen which is higher and stabler). (see senseonics troubles with the wrist for additional pointers)
  • Abbott discouraging the covering and not replacing misbehaving sensors that were covered (it potentially messes up the gradient temperature computations)
and a bunch of other anecdotal pieces of evidence.

I can still be wrong, of course:

Abbott could be using one point compensation, but I believe they do not because I see data fitting a 2 thermistors scenario.

Abbott could be using three point compensation with a metallic wire I missed or some other fancy property of their sensing wire they could use as a RTD.


At this point you may begin to think “It sounds great, but where is the data to back this”? Let me show you. But first, let’s have a thought for our sensor 0M0000U0Q68 that suffered a quick and painful death thanks to an impromptu meeting with a door frame.

We’ll be assuming T2 is one of the temperature of interest. Let’s pick the sensor up and put it in my jeans pocket. There will be no glucose measure as the sensor wire is now out the body. Ah, it seems my jeans pocket is warmer than the air outside… (dataset: warmedinpocket)


Let’s drop it on my “lab” table. 21C ambient, should be about right. (dataset: postremovalsuite)

Oops, I forgot it for a while, but now comes a week-end. Let’s take a heating bed and put it at 40C (dataset: 41c)


And let’s slowly bring the temperature down to 36C (dataset 36c)

then 32C (dataset 32c)

then back to room temperature (around 20-21) (dataset 21c)

and finally outside (9C reported by external thermometer dataset 9c4)

Those measures and data sets clearly show there is some validity to the interpretation.
Things to keep in mind: amateur temperature measurement are a pain – breathing on the setup, the height of the table, etc… have an impact. The values are relative, they fit and track the circumstances, but the Libre doesn’t necessarily see them that way. We are not talking “skin” “board” or even delta between skin and board here. Just ambient as a whole.


Let’s look again at what happens during the most drastic change, when the sensor was placed on the heat bed, this time with a bit of code

Mandatory disagreable note: at this point, the reader is expected to know which 2 bytes I am talking about. If he doesn’t know, he just looks them up in the data dump.

t2, high first [12417, 12417, 12417, 12417, 7040, 4992, 4224, 4224, 4224, 4480, 4480, 4736, 4736, 4992, 4992, 4992]
for i in sortedimmediatevalues:
    r2 = hex_str_to_int(i[3])
    r2m = r2 & bitmask14
comment: interesting, values go down as temperature increases as expected fromresistance based thermistors. 

t2 inverted [3966, 3966, 3966, 3966, 9343, 11391, 12159, 12159, 12159, 11903, 11903, 11647, 11647, 11391, 11391, 11391]
temperatures2inverted = [16383-x for x in t2h]
comment: but I am a human, and want them to go up. (dirty hack!)

Temperatures 2, TI [13.83, 13.83, 13.83, 13.83, 30.76, 36.77, 38.97, 38.97, 38.97, 38.24, 38.24, 37.51, 37.51, 36.77, 36.77, 36.77]
def ConvertTemperatureTISpec(counts):
    a = 1
    b = 273
    c = -counts
    d = (b**2)-(4*a*c)
    sol1 = (-b+cmath.sqrt(d))/(2*a)
    return round(abs(sol1), 2)
comment: the TI FRL thermistor formula gives reasonable looking results but my room is definitely not that cold

Temperatures 2 final [20.51, 20.51, 20.51, 20.51, 35.4, 41.07, 43.2, 43.2, 43.2, 42.49, 42.49, 41.78, 41.78, 41.07, 41.07, 41.07] 
def ConvertTemperature(counts):
    sol1 = counts*0.0027689+9.53
    return round(abs(sol1), 2)
comment: that works much better for my purpose… 
This works with my setup, in the temperature range I am interested in. I have exactly zero idea if that is how the FAL sees things. The result I am using could very well be totally off in terms of absolute values. I could be in the linear part of some complex spline or a dangerously exponential function that I would not know about it. I am not an electrical engineer, just a tinkerer. I am particularly concerned about the bottom range of the temperatures: did I hit a hard limit? Not sure. At some point, but I don’t know precisely where, the Libre reader just reports “too cold”. And please note that, in order to avoid a shutdown on no decent glucose values, I could not use the official reader during the experiment.


Yes, I have ideas about the other two bytes. But they are noisy (as the patent hints they would be) and I am currently considering (but not using) them as a delta. I’d rather not talk about them in public. It is easy to see patterns when there are none.

Finally: I am not currently actively looking at the Libre anymore. I just decided to share past data in the hope more competent people could have a look at it.

 download dataset