Default Minimum Slope needs correcting

[TecMunky]

The default minimum slope for the calibration algorithm is problematic. I originally noticed a problem calibrating some sensors last year. Adrian helped me resolve my issues, and created a new "DexParametersAdrian" class, which could be enabled when engineering mode is enabled. This method allowed me to continue using at least 6 of my sensors that would otherwise be useless, and still occasionally I need a slope lower than the default minimum (1.08). Since that time I have helped 5 or 6 other people enable this special mode to get their calibration slopes to fit the data. I am reasonably certain that for every person that discovers this issue, there must be many more that are not aware of it and may be throwing out perfectly good sensors.

I suggest the default minimums be changed for everyone -- copying the class DexParametersAdrian to DexParamters may be the proper solution. Except I would consider opening the ranges between lows and highs a little to allow for more flexibility - I had at least two sensors where I had to lower even the Adrian defaults to get them to calibrate properly. Maybe the DexParametersAdrian class could be kept, but extended even further for special situations.

I am submitting this issue in the hopes of helping more people without having them enable the potentially dangerous "engineering mode".

EDIT: This is in the dexdrip/Models/Calibration.java source file

[jamorham]

Do you know any of the example numbers for the slopes you had for reference?

Making the DexParametersAdrian the default values might be a good idea. @AdrianLxM should have some thoughts on this too.

I'd also be interested to know whether the Datricsae calibration plugin would handle the situation you experienced as that also allows for wider slopes than DexParametersAdrian

[TecMunky]

----------- This is my current code: ----------------------- DexParametersAdrian() { LOW_SLOPE_1 = 0.60; LOW_SLOPE_2 = 0.55; HIGH_SLOPE_1 = 1.5; HIGH_SLOPE_2 = 1.6; DEFAULT_LOW_SLOPE_LOW = 0.60; DEFAULT_LOW_SLOPE_HIGH = 0.55; DEFAULT_SLOPE = 1; DEFAULT_HIGH_SLOPE_HIGH = 1.5; DEFAULT_HIGH_SLOPE_LOW = 1.4; } ------------- this is the current released code --------------- DexParametersAdrian() { LOW_SLOPE_1 = 0.75; LOW_SLOPE_2 = 0.70; HIGH_SLOPE_1 = 1.3; HIGH_SLOPE_2 = 1.4; DEFAULT_LOW_SLOPE_LOW = 0.75; DEFAULT_LOW_SLOPE_HIGH = 0.70; DEFAULT_SLOPE = 1; DEFAULT_HIGH_SLOPE_HIGH = 1.3; DEFAULT_HIGH_SLOPE_LOW = 1.2; }

[TecMunky]

I have an issue using the Datricsae algorithm - when a calibration is performed, it moves ALL data points in the past (all the way back to the beginning of the first reading in the database) based on the new slope and intercept value - this action invalidates at the very least all data from previous sensors - and also, the characteristic response of sensors change over time, so it also invalidates information on the current sensor. This is a huge problem for me, as it makes the statistics useless. If it were to only affect the previous 30 readings, like the normal calibration algorithm does, it would be much more useful. In that case it might even be more accurate.

I was using the Datricsae plugin for a while, and was liking the results - until I noticed the above problem.

[jstevensog]

Just adding my $0.02. I believe that any new calibration should NOT affect ANY past readings. And any change to calibration algorithm should NOT affect ANY past readings. Altering past readings based on any change in slope/intercept, whether by calibration input or algorithm change simply should not impact any past data, for exactly the reasons Jim E states. It screws with the statistics and other data regarding sensors in the past. This is why in the original xDrip we had a setting to allow a person to turn off "backdating" a calibration, just to smooth out the trend (the only reason it was there in the first place). I still use the original xDrip, haven't had the time to go through xDrip+ to ensure I am happy with what it does as far as BGL recordings and readings are concerned. Too time poor right now. Hearing this, I am glad I have not changed.

Additionally, I believe we need to get over the fear of a negative intercept. There are a number of reasons for this regarding accuracy and increasing useful life of sensor. But that is an argument others with more knowledge in that area than I can undertake. I simply see the sense of their arguments. I understand why Dexcom (and others) have an issue with negative intercepts, but cannot help but think it is also advantageous to their bottom line.

Cheers

On Mon, Feb 27, 2017 at 11:23 AM, Jim E notifications@github.com wrote:

I have an issue using the Datricsae algorithm - when a calibration is performed, it moves ALL data points in the past (all the way back to the beginning of the first reading in the database) based on the new slope and intercept value - this action invalidates at the very least all data from previous sensors - and also, the characteristic response of sensors change over time, so it also invalidates information on the current sensor. This is a huge problem for me, as it makes the statistics useless. If it were to only affect the previous 30 readings, like the normal calibration algorithm does, it would be much more useful. In that case it might even be more accurate.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/NightscoutFoundation/xDrip/issues/76#issuecomment-282601633, or mute the thread https://github.com/notifications/unsubscribe-auth/AIQs8xrJmR-MO677P_RCDqVVpm9i-nBRks5rghdngaJpZM4MMioT .

-- John Stevens "You are how you live, not what you have."

[AdrianLxM]

@jamorham I'm using those parameters for quite a while now. Milos also uses them for a closed loop system. I'd be happy if they would become the default ones.

@jstevensog, xDrip+ still has the same default calibration method like xDrip-E. That's the one I use (with the wider range for allowed slopes). Only that with a plugin system you can opt for different algorithms. But for sure I agree, it should not change the past more than a few readings. (I haven't experienced that yet - not using the plugin system though).

cheers, Adrian

[jamorham]

@TecMunky @jstevensog @AdrianLxM The 24th Feb nightly has historical slope querying for calibration plugins so that they should behave the same as the original algorithm with regards to historical views.

[TecMunky]

@jamorham - could you point me to the relevant code for the historical slope querying? And possibly how I could look at the recent changes? thanks.

I much prefer the limited recent history change rather than a sudden jump to new values. This does mean that the NightScout site does not show the same data as xDrip+, however, but I can live with that.

I guess now we need to decide what final values to use. I prefer the values I am currently using - but I admit I am biased.

Oh, and I suppose we need to decide if negative intercepts should be allowed. I don't know the reasons for allowing or preventing these. Maybe someone could elaborate the arguments. EDIT: I always get negative intercepts - did you mean positive intercepts, or am I missing something?

[TecMunky]

@jamorham - I turned the Datricsae algorithm back on and will see how that works for me now.

Update: -- it is still affecting historical data. Back off again.

[TecMunky]

Datricsae ON vs OFF you can see a difference in the peak you can also see the lighter dots indicating the other values not being used

This is a snapshot of yesterday when I just turned Datricsae ON

This is Back OFF again -- same time period

[jamorham]

@TecMunky Historical slope querying for calibration plugins was introduced in this commit: https://github.com/NightscoutFoundation/xDrip/commit/2b10c1106de1dc0d6b105e227c1af46d4e99bbf2

The calibration plugins usually work as a dynamic overlay, so you're going to see a difference if you enable glucose from the plugin. In the screenshots above it looks to me just as if the secondary and primary plots swap over, which is exactly what I would expect.

What changed with the historical slope querying is that before it was introduced, your previous readings from a plugin (Datricsae etc) would alter based only on the most recent calibration. After the changes for historical querying it will show what it would have shown at that point in time.

So as it is now, if you had Datricsae enabled as your primary and you had a glucose number of 200 but then re-calibrated so that the same raw value would then result in a glucose value of 180, the graph will still show the 200 value at that historical point in time. The plugin is dynamically recalculating based on the calibrations present at that point in time as it would have been. This gives much more consistent results with what you would expect. It looks immutable but it is actually being dynamically calculated.

If you really want immutable data calculated from a plugin, it is possible to do it but I wouldn't recommend that at this point because of the experimental nature of the plugins. As it stands they don't normally alter the BgReading database table at all.

[TecMunky]

Thanks for the explanation @jamorham and the pointer to the code that changed.

Help me understand. Here is a hypothetical: I have the Datricsae Plugin enabled, "Plugin plot on graph" ON, "Use Plugin Glucose" OFF. I enter calibrations over time. Each time the xDrip algorithm and the Datricsae Plugin calibration graphs both change based on calibration data. Changing the "Use Plugin Glucose" selection to ON will change the plot over time based on the selected algorithm, and the new data would look the same as if the "Use Plugin Glucose" was ON the whole time - is this correct? If this is true, the historical data still changes back to the beginning, but changes to values they would have been if the Plugin was in use throughout that time. Do I have that correct?

If the above is correct - then I don't see a problem. If not, please explain. If you would rather take this conversation to another channel (email or facebook messaging) please do so.

AND -- if I understand correctly -- the actual BG readings in the database don't change at all, the data sent to NightScout, Dexcom Follow, and the Smart Watch, are still based on the BG readings in the database?

Finally -- the statistics are based on the database values, so they don't change either -- is this correct?

[jamorham]

the historical data still changes back to the beginning, but changes to values they would have been if the Plugin was in use throughout that time. Do I have that correct?

Yes this is correct. The only caveat to this is that the original xDrip algorithm has an option where it smooths data from the previous few hours to the current value at the point of calibration. Effectively bending the graph so that the curve appears smooth. It actually rewrites the history in the database itself. You can often see where this has happened because it doesn't rewrite the filtered plot so the grey line curve can show where it used to be.

This feature is controlled by the Rewrite History checkbox in xDrip+ Display Settings. Even with it turned off, we still rewrite the last couple of readings to avoid a sudden jump in the delta value which is calculated looking at the last few readings.

On the original topic of this issue, I believe we should move to using the "Adrian" slope parameters as the default and probably enable these universally, but before doing that I want to ensure that the current crop of changes to calibrations+plugins are all stable and any issues with those eliminated to avoid changing too many things at once.

[TecMunky]

I actually like the "rewrite history" option - and would like to see that implemented in the plugin - but since the plugin doesn't actually rewrite data into the database, I don't know how that would be accomplished. Unless the plugin result is affected anyway due to the original algorithm rewriting recent history.

On the original topic - while the "Adrian" slope parameters are better than the defaults, I suggest we widen the range of defaults similar to the values I currently use as my "Adrian" slope parameters, as mentioned my first response under "this is my current code".

[tzachi-dar]

Rewriting the history is not a great feature. The way that it was implemented is to change the values with a change that is bigger relatively to the time of the last calibration.

This looks great on the graph, but it can make a falling bg look like it is raising, or vice versa. This is espeicialy true if the calibration values have changed dramatically. This can lead to bad decisions about insulin usage.

A different approach can be to re-calculate all values for (let's say last hour) based on the last calibration values. In that case, bg going high will stay going high. If I understand correctly, this is what is actually going on with new plugin.

Tzachi

On Mon, Feb 27, 2017 at 11:48 PM, Jim E notifications@github.com wrote:

I actually like the "rewrite history" option - and would like to see that implemented in the plugin - but since the plugin doesn't actually rewrite data into the database, I don't know how that would be accomplished. Unless the plugin result is affected anyway due to the original algorithm rewriting recent history.

On the original topic - while the "Adrian" slope parameters are better than the defaults, I suggest we widen the range of defaults similar to the values I currently use as my "Adrian" slope parameters, as mentioned my first response under "this is my current code".

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/NightscoutFoundation/xDrip/issues/76#issuecomment-282865876, or mute the thread https://github.com/notifications/unsubscribe-auth/AHkw5Dc-aZupGZvAEqzIqEHWy289XU8qks5rg0TEgaJpZM4MMioT .

[jamorham]

I'm due to start a new sensor tomorrow so I'm going to run through it all with the AdrianSlopeParameters as an additional check that these at least appear sound tested locally. Then I plan to install those as the default slopes in a new nightly and provide a TecMunky set of slopes as an engineering mode option replacing the Adrian default slopes.

The only thing I'm not sure about is whether to provide an option to fallback to the current "classic" slopes. Are there any circumstances where these would actually be advantageous?

[TecMunky]

I have come to the conclusion that re-writing history is not something that I want anymore. Sure it looks great and has a smoother graph, but as tzachi-dar implied, it distorts reality.

I might reconsider if there was an option to see raw values on the graph so I could still see historical trends. Raw data would not have any jumps at calibration points either. (By raw, I mean the unfiltered data read from the sensor.)

[jamorham]

Widening of the slope parameters by making the "Adrian slope parameters" the default was added in this commit: https://github.com/NightscoutFoundation/xDrip/commit/be27a9ea07163f2d2718a72ee31da4f501f40fa2 It is still possible to use the old parameters through engineering mode should anyone want to do that.

The logic for adding these slopes is that, other than the original slopes, these have received the greatest testing. I've also tested locally for a week from starting a new sensor and in that single sensor test they worked correctly and appeared to my eye to perform better than the previous default slopes.

I'm running the Datricsae plugin with bluetooth meter automated calibration as well and the comparative accuracy status line also reports improved accuracy (presumably due to less use of default slopes) although it is still less than datricsae in my very limited testing which almost certainly doesn't hit enough of the edge cases to be in any way conclusive.

[Nargly]

I have to disagree with you TecMunky on the adjusting past values due to a calibration. If the calibration is off, then the recent past values are incorrect. So adjusting them seems like it makes sense to me.

[TecMunky]

Should this issue be closed - Or should the default slopes be made wider again?

[Nargly]

Instead of putting the decision on one person or a small group, just make the feature a selectable option in the settings for the app. That way you can fit any user's desire for their own control. Make sense?

[jamorham]

If we don't have a standardized set of slope parameters it makes it very hard indeed to diagnose issues related to calibration I think.

Any comments on these values to try to bring xDrip classic closer to the slopes that Datricsae supports?

class DexParameters extends SlopeParameters {
    DexParameters() {
        LOW_SLOPE_1 = 0.75;
        LOW_SLOPE_2 = 0.70;
        HIGH_SLOPE_1 = 1.5;
        HIGH_SLOPE_2 = 1.6;
        DEFAULT_LOW_SLOPE_LOW = 0.75;
        DEFAULT_LOW_SLOPE_HIGH = 0.70;
        DEFAULT_SLOPE = 1;
        DEFAULT_HIGH_SLOPE_HIGH = 1.5;
        DEFAULT_HIGH_SLOPE_LOW = 1.4;
    }

}

[gigabyte72]

TecMunky - Sorry for this in the public thread but github doesn't appear to offer a private messaging feature. Due to me typically being a very tight range, when i got outside of it (hypo/hyper), it gets very dangerous (glucose was "70" but in reality after waking up from having a glucagon injection), that wasn't my true reading. Looking for high-level steps of altering the slope manually (already have engineering mode enable/disable ability).

[TecMunky]

@gigabyte72 - the proper place to ask these questions is in the gitter channel: https://gitter.im/jamorham/xDrip-plus

In the calibration graph screen, the 3-dot menu allows you to override the slope and intercept. The overrides will go away when you next calibrate.

[Navid200]

@TecMunky Hi, Has this been addressed already? Thanks

[TecMunky]

@TecMunky Hi, Has this been addressed already? Thanks

Yes - this has been addressed to my satisfaction. I am closing the issue now. Others may still have comments.