The time has come for a few corrections and additional information.
First CorrectionAs I said in a previous post, the Libre can potentially use several temperature compensation methods, as described in their patent (1, 2 or 3 points). To summarize the options
1 point: at least one point (skin) is certain. There’s the huge thermistor sitting in its nice well, and I can interpret its data in relative terms.
2 points: the “skin and board” option, used to estimate the temperature at the sensing site. That option was my favorite for a couple of reasons: other TI FRL processors offer thermistors and I systematically saw two temperature values move as I heated and cooled the sensor. One of those two values was always a bit ahead of the other, which fit nicely with a diffusion gradient. But there is a catch.
3 points: with skin, board and in-situ thermistors. After having looked at microscopic images of the sensing wire, I think that option can be excluded, but as usual can still be wrong.
The catchIt is simple and stupid at the same time. Back in 2014-2015, I immediately split the 6 bytes immediate Libre record into 3 words. One for BG, two moving on temperature changes, with some flags. I was aware of the existence of flags, and did not drop them as I masked the observed values. That left me with a temperature value (thermistor value) that I could interpret directly based on experimental correlation and another that I had no choice but to consider as a delta.
On the plus side
- I really liked the 2 points compensation design.
- I had decently working code that I could reliably use for thermal compensation.
- I was forced to use one value as LSB, the other as MSB and mask and keep the flags.
- my temperature data had a resolution of 0.7C
Here’s an example of where I stand right now, with both the immediate values and the historical data.
A few comments
- that situation doesn’t warrant temperature compensation, at least from my own algorithm point of view, therefore G and Temp compensated G match. It could require a slight tweak if the temperature remains at a lower (relative) level, but I know from experience that a small temperature change needs a few minutes to impact the glucose oxydase activity.
- the scan and my interpretation match closely (176 vs 180) but that isn’t always the case. While a lot of my sensors match my algorithm nicely, some sensors may appear “off” if one uses a constant interpretation.
- I have noticed significant behavior differences between my 2014-2015 sensors and the 2016-2017 ones.
- I am aware that the condition flags would benefit from being displayed in binary form and correlated with events and situations – I have another visualization for that… Maybe later.
- the interpretation of historical data (the eight hours stored in the FRAM of the reader) is a bit tricky, in the sense that it is delayed, post-processed (smoothed mostly) by the reader and ends up being a bit different when exported by the PC software.
SECOND CORRECTIONBlog reader R.Z. brought to my attention an additional thermistor that I had missed on the skin temperature sensing circuit. I am told that this type of circuit is a standard, but probably will have to redo my experimental temperature measurements at some point.
In a way, one can say that I lost a thermistor (correction 1, much to my dismay) and that I gained another one….
TO GO FURTHERI’ll keep logging data and situations as I enjoy the hobby.
But, to be honest, I am still depressed when I see open or semi open source solutions, sometimes even commercial add-on products, use a basic approach that I rejected in late 2014 or 2015…
A concerted strategy to make progress (legal progress that is…) would be to collect and document as many situations as possible, too hot, too warm, trending up, trending down, not available, noisy, clean etc… completely. By completely I mean
- complete data dump (NXPTagInfo for example).
- simultaneous official scan
- simultaneous error log if any