Patch to use non-fixed Libre slopes with Libre2 Patched protocol

[nhatier]

For now the only way to use Libre 2 (Canada) with xDrip seems to be though a third-party app (Juggluco) which broadcasts to xdrip using Libre2 patched. With that protocol xDrip currently only allow a fixed slope.

The change is quite small, I just modified the getSlopeParameters function so the use_non_fixed_li_parameters also applies to Libre2App. I just duplicated the LiParametersNonFixed slope parameters.

I'm pretty sure this could - and probably should - be integrated to the main branch.

nhatier@a544c88

[Navid200]

If you mean using a plugin, that's a not a good idea.
Libre 2 should allow you to calibrate using its official app, doesn't it?

[nhatier]

Unless I'm missing something in the source code, I think Libre2 sensors that can connect to xDrip "natively" - without the need of a third-party app - are allowed non-fixed slopes.

I don't mind about a fair change of policy, but for now I feel Canadian Libre2 data - which can only be used through the Libre2 Patched protocol for now - is (unintentionally) being singled out.

[Navid200]

That may be the case. But, I don't think it is xDrip that is singling out any particular CGM.

My worry is that something bad will happen and we will all feel guilty then when it is too late to act.
I want us to be very careful with what we allow xDrip to do. If xDrip becomes known as an app that ignores safety, it will not do any of us any good.

Have you asked your doctor how you are supposed to calibrate considering the manufacturer of the CGM your doctor has prescribed for you does not allow you to calibrate it?

[nhatier]

I don't think the benefits of calibration are within the scope of this exchange.

I understand your concerns about safety. If someone confirms that European Libre2 sensors are able to use proper xDrip calibration with non-fixed slope, I hope you would agree that allowing the same to Canadian Libre2 sensors though the Libre2 patched protocol would make sense.

If the European Libre2 sensors are NOT allowed xDrip calibration (whether or not they can be calibrated using some proprietary method), I will not push the issue any further.

In all cases, I'm fine compiling my own fork for myself with my little change. Bringing this patch to the main branch is more a matter of convenience and sharing with my fellow Canadian Libre2+xDrip users than a matter of necessity for me.

[Navid200]

xDrip is not supposed to replace a doctor. Someone who uses xDrip still needs to control their diabetes under the supervision of a doctor.
The benefits of calibration are within the scope of what you need to talk to your doctor about.

There are individuals who calibrate when they shouldn't. Many people don't realize that their blood glucose meter should not be used as a point of reference for a factory-calibrated CGM because those both have errors that are not necessarily corelated. Therefore, there may be mismatches between the two while neither of them is perfect.
And none of that is outside the context of this forum. This forum is supposed to help people by providing info many may not be aware of, or may have never really thought about.

I would like to gradually phase out the entire plugin capability from xDrip instead of enhancing it.

[nhatier]

My doctor cannot recommend I use methods that are not officially supported by the manufacturer. But they are happy that I do, as the results prove for themselves.

Calibration has been a prominent feature of xDrip for years. I know not everyone is able to understand how and when to calibrate, but before removing such a big feature, you may want to determine who is the xDrip audience. In my opinion, xDrip users, on average, are likely to be more tech-savvy and understand more about glucose management than other CGM users, as those other CGM users will most likely use the official app.

I used calibration for years with Libre 1 in xDrip to get more accurate results even at the end of the sensor life.

When I switched to Libre 2 without calibration, I quickly saw that, while one sensor is usually coherent with itself during it's life are most sensors are acceptably accurate when the level is stable, there can still be a large variation for some sensors - to the order of ±2.5 mmol/L (45 mg/dL) in the middle of the normal range. Which means the sensor may show hypoglycemia when you are right at the perfect level... or worse, vice-versa. I also got one that was too low in the low range and too high in the mid-high range.

Once I got time to get xDrip source code, understand some of it and create this patch, those woes disappeared and I'm back on course with nice hbA1c results and less mid-night wake-up alarms for a false hypo reading.

Of course I could call the manufacturer each time I get a bad apple to get a free replacement, but they don't make that process quick and easy here. It gets boring quickly if I have to do it for one sensor out of maybe 5-6.

[PhilTU]

Unless I'm missing something in the source code, I think Libre2 sensors that can connect to xDrip "natively" - without the need of a third-party app - are allowed non-fixed slopes.

that option exists, Non-fixed Libre slopes is available in Other Settings > Less common settings > Advanced Calibration . Seems to be available with Patched app as the Hardware data source too based on a quick look (no patched app actually present). My recollection is that when the Libre 2 patched app was introduced the consensus was that the slope was pretty reliable but some sensors needed an offset.

As the Libre Patched App is dying and OOP2 is the preferred connection method I'm less familiar with the patched options, though I have used it. There are options within xDrip+ with OOP2 to not calibrate, calibrate using raw or calibrate using "glucose" which uses a similar preprocessing algorithm to the vendor app (and juggluco). Unfortunately OOP2 doesn't support US or Canadian sensors. The juggluco developer does not believe in offerring calibration.

Similar debates arise with web follower, should one take the output of another app as gospel, or expose it to calibration when the timing of the signal is somewhat obscured by the indirect route it has travelled.

[nhatier]

Thanks for the note.

My patch reads that exact setting to enable non-fixed Libre slopes when the Libre Patched App protocol is used, so Canadian and US sensors can use them too.

[PhilTU]

My patch reads that exact setting to enable non-fixed Libre slopes when the Libre Patched App protocol is used, so Canadian and US sensors can use them too.

ok, so it is ignored normally with patched app as the data source ?

[nhatier]

Roughly, the master xDrip code is

If IsLibre2App -> Fixed Slope

If IsLimitter, Check "Non-Fixed Libre Slope" setting. If Setting is on, -> Non-Fixed Slope, else Fixed Slope

If neither, Non-Fixed Slope.

[PhilTU]

thanks, that's pretty clear.

[Navid200]

I hate to be in @jamorham 's shoes. He has to make decisions that cannot make everyone happy. I am grateful to him for doing it.
Everything I have posted here is my view that I believe in. But, I will follow his call.

I would like to add the following.

My understanding is that Libre 1 is not really a CGM. You needed to manually scan it.
Then, there were other manufacturers that produced devices like miaomiao that continuously scanned Libe 1. But, there was a need for calibration as Libre 1 was a first generation sensor like Dexcom G5 that needed frequent calibrations.

xDrip had no choice but to offer calibration for Libre 1.
I suppose plugin may have been something that was added then for Libre 1 or perhaps other devices.

Libre 2 and G6 are second generation devices. They improve accuracy significantly by taking into account the impact of the immune system, which G5 and Libre 1 did not.
Therefore, there is no need for frequent calibrations.
Nevertheless, G6 offers a calibration option. And xDrip allows a G6 user to submit calibrations to the G6 transmitter. But, xDrip does not offer the user to calibrate a G6 other than by submitting the calibration to the G6 transmitter.

Why Libre 2 does not offer calibration the same as G6 does is a question for the manufacturer of Libre 2.

In my opinion, we should not offer the means for the user to calibrate the results from a Libre 2 for the same reason we do not allow it for a G6 or G7.

[PhilTU]

xDrip had no choice but to offer calibration for Libre 1.

Agreed, Initially the Libre reading was only of a raw glucose value without temperature correction or processing, that came later with OOP1 which applied (part of) vendor algorithm to raw data. So it was initially necessary to compensate for simple approach with calibration option. OOP2 also has improved vendor-type algorithm. These should make received value like that from vendor app or patched app. These are the results that have medical approval licences.

Personally I would draw a distinction between sensors that xDrip+ is reading and communicating with, and other cases where processed data is being recieved from another app or system. I imagine that OOP2 gets more data from a sensor than the glucose value received from a patched app.

In a way the non-fixed slops argument is a little separate. If you force a gradient of 1 then the only calibration effect is a fixed offset and this can lead to odd values of the offset which would perhaps not arise if y=mx + c was used.

[Navid200]

I disagree.

1- Improving the existing calibration scheme for Libre is something I have asked our Libre experts to advise me on. I am still waiting.
2- Plugin is something completely different. Plugin allows you to treat the incoming data as if it was raw. At least, that's my understanding.

Please don't mix 1 and 2.
Canadian Libre cannot be used. So, it is being read from the manufacturer's app. Therefore, what is being read is not raw. This discussion is about calibrating that, calibrating values coming from a manufacturer's app.

[nhatier]

While I understand this may be a different topic, if an app like Juggluco is able to communicate directly with Canadian Libre2, why is xDrip unable to do so?

[Navid200]

That's a good question. I will ask it from our developers.

Even if xDrip can directly communicate with Libre 2, which would eliminate the need for an app, I would still not want xDrip to calibrate it.

[PhilTU]

While I understand this may be a different topic, if an app like Juggluco is able to communicate directly with Canadian Libre2, why is xDrip unable to do so?

I think Juggluco is happier to incorporate more vendor code than others, you need the vendor app or apk present on the phone to install and use juggluco, as it reads some of the libraries or something. Or at least that was the case last time I installed it.

[Navid200]

@PhilTU Is Libre 2 approved for dosing?
I may have made an incorrect claim. If it is not approved, I will not have as much problem calibrating it.

[tzachi-dar]

Here is what I can tell:

1. When using european libre 1 and libre 2 we do allow a mode with calibration.
2. The canadian libre 2 is encrypted in a way that we do not understand so we can not use it directly.
3. Juggluco AFAIK is using libraries from the manufacturer. xDrip can also do the same but it requires work.
4. For some people calibration is a must. For other people it is needed sometimes. For other calibrations don't work well.
   I don't see a reason not to allow optional calibration for the canadian libre 2.

[PhilTU]

@PhilTU Is Libre 2 approved for dosing? I may have made an incorrect claim. If it is not approved, I will not have as much problem calibrating it.

Approved for insulin dosing - yes I believe so in the US the FDA say " however, fingerstick testing is not needed to inform appropriate care choices or to calibrate glucose levels with this system. " https://www.fda.gov/news-events/press-announcements/fda-approves-first-continuous-glucose-monitoring-system-adults-not-requiring-blood-sample

The vendor's UK web site FAQ at https://www.freestyle.abbott/uk-en/support/faq.html?q=insulin&p=1 says "

Can the FreeStyle Libre systems^ be used to make insulin dosing decisions?

Yes. People with diabetes can use FreeStyle Libre sensors with the FreeStyle LibreLink or FreeStyle Libre 3 app to better understand the impact of actions like eating, exercise, and taking insulin based on their glucose levels. They can also make day-to-day therapy decisions when using the apps with FreeStyle Libre sensors, including insulin dosing decisions, based on guidance from their healthcare professional."

[SimonPhilpott]

The idea that calibration being removed for any reason is wild. Even with an outstanding MARD, this still is only measured as an average. There are plenty of situations where calibration is essential. Case in point, my latest Libre 2 initiated with a MMOL reading of 14. I calibrated down to 8.

Situationally this was probably down to the 24h warmup but why would I want to be unable to rely on readings for over 24h if I could just calibrate and fix the problem.

Freestyle Libre 2 MARD: 9.3%. This figure is also reported as being much higher, 17.2% for example https://www.ncbi.nlm.nih.gov/pmc/articles/PMC10675113/
Contour NEXT MARD: 4.8%

Any statement by Abbott directly on the reliability of the Libre to make significant treatment decisions based on readings will be swayed. Any large doses I always back up with a blood glucose check, calibrate if needed in order to make accurate and safe decisions.

[Navid200]

No one as far as I know has suggested to remove calibration capability from xDrip.

[SimonPhilpott]

That's good, I think I've misread the comments here clearly. Apologies.

[PhilTU]

Case in point, my latest Libre 2 initiated with a MMOL reading of 14. I calibrated down to 8.

that is an interesting case in this context, because with a fixed slope the result is a calibration that subtracts 6 mmol/l

so as soon as the sensor is reading below 10 mmol/l you think you're heading into a hypo as the calibrated value is now 4 mmol/l.

This does support non-fixed slopes.

[nhatier]

It seems there is some sort of consensus about the principle.

Now, is the proposed patch good enough - binding an existing option to the same effect on a different process - or should it be done another way with yet another option?