Default Slopes

[TecMunky]

I have found that the default slopes in the G5-Beta branch, and therefore probably the main branch as well, are problematic for at least two of my sensors - one which I replaced today which was in use for 20 days (both from the same box) - and for the one I just put in today. I noticed when using the previous sensor (the first one from a new box) that after a calibration the graph would show a line with the default slope of 1.08 through the last calibration point, and not being "fit" through the rest of the data. To resolve this issue (per Adrian Mittermayr's suggestion) I "gitted" (is that a word) the g5-beta branch and built the app myself using modified default slope constants. Using my build, I have had high accuracy, and have had calibration slopes between 0.73 and 1.03 (all of these below the default low slope).

Here is my modified code (from the g5-beta "calibration.java"): class DexParameters extends SlopeParameters { DexParameters(){ LOW_SLOPE_1 = 0.70; // 0.75; // 0.85; // 0.95; // LOW_SLOPE_2 = 0.65; // 0.70; // 0.80; // 0.85; // HIGH_SLOPE_1 = 1.3; HIGH_SLOPE_2 = 1.4; DEFAULT_LOW_SLOPE_LOW = 0.70; // 0.75; // 0.90; // 1.08; // DEFAULT_LOW_SLOPE_HIGH = 0.75; // 0.80; // 0.95; // 1.15; // DEFAULT_SLOPE = 1; DEFAULT_HIGH_SLOPE_HIGH = 1.3; DEFAUL_HIGH_SLOPE_LOW = 1.2; } }

I left in (as comments) all the values I tried before settling on the current values. Note that the DEFAULT_LOW_SLOPE_LOW value is still near the lowest calibration slope I got for my first sensor in the new box, so this value should probably be lowered even further.

I know that changing these values could be an issue, especially with people who are not diligent about how and when they calibrate, but the current values do need to be adjusted. It also might be possible that a different algorithm could improve results.

[AdrianLxM]

The slopes I would have needed 24 hours after sensor insertion would have been: 0.7 0.755 0.68

So I guess with newer sensor batches we will need the possibility for lower slopes. These are the parameters I've been using since February: https://github.com/StephenBlackWasAlreadyTaken/xDrip-Experimental/compare/adrianCalibrationParams

    public static final double LOW_SLOPE_1 = 0.85; //0.95
    public static final double LOW_SLOPE_2 = 0.80; //0.85
    public static final double HIGH_SLOPE_1 = 1.3;
    public static final double HIGH_SLOPE_2 = 1.4;
    public static final double DEFAULT_LOW_SLOPE_LOW = 0.9; //1.08
    public static final double DEFAULT_LOW_SLOPE_HIGH = 0.95; //1.15
    public static final int DEFAULT_SLOPE = 1;
    public static final double DEFAULT_HIGH_SLOPE_HIGH = 1.3;
    public static final double DEFAUL_HIGH_SLOPE_LOW = 1.2;

(This is from before refactoring - and who can spot the typo ;))

[jstevensog]

The problem is I don't variance between batches of sensors, and even sensors in individual batches. The First Two sensors in my last batch were accurate from day one, yet my latest is just not as accurate. The default slopes really should only impact things until you have x number of calibrations, and then you should be running on a calculated shoppe IMHO. The default slopes are meant for the first calibration, or if the linear regression calculation comes up with a slope and intercept that are just too far out to be real.

---- AdrianLxM wrote ----

The slopes I would have needed 24 hours after sensor insertion would have been: 0.7 0.755 0.68

So I guess with newer sensor batches we will need the possibility for lower slopes. These are the parameters I've been using since February: https://github.com/StephenBlackWasAlreadyTaken/xDrip-Experimental/compare/adrianCalibrationParams

public static final double LOW_SLOPE_1 = 0.85; //0.95 public static final double LOW_SLOPE_2 = 0.80; //0.85 public static final double HIGH_SLOPE_1 = 1.3; public static final double HIGH_SLOPE_2 = 1.4; public static final double DEFAULT_LOW_SLOPE_LOW = 0.9; //1.08 public static final double DEFAULT_LOW_SLOPE_HIGH = 0.95; //1.15 public static final int DEFAULT_SLOPE = 1; public static final double DEFAULT_HIGH_SLOPE_HIGH = 1.3; public static final double DEFAUL_HIGH_SLOPE_LOW = 1.2;

(This is from before refactoring - and who can spot the type ;))

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[AdrianLxM]

I had a solution for me in mind but then found it too cumbersome to always merge back the changes from xDrip-E. Do you think this would be something for an official version?:

• No matter if a default slope is used or not: Always (also) store the slope and intercept calculated by linear regression.
• On a Calibration use the algorithm as is.
• In the Calibration Graph add a toggle button to switch to the "no tresholds" calibration result.

This would force the user (me) to look at the calibration graph after a calibration to enable the non-treshold (or wider-threshold) version. For those who don't care, everything stays the same.

[tzachi-dar]

I would take the adrian offer even one step further:

Allow a calibrator mode, that will allow one to do much more with calibrations. It will not be possible to enter this mode with official betas, only people that have built by themselves will be able to use it. On such builds, one will have to press on some secret place a few times to move to this build(like getting into debug mode on android).

This will allow us to have new calibration code, without influencing the not so sophisticated users.

[TecMunky]

This is a great idea - but I would add one feature - the ability to remove (or ignore) invalid calibration points. I might even allow this special mode to be entered by the official build, but only document that feature on GitHub.

[AdrianLxM]

The problem exists for people who can and people who can't build their own apk. I'm not fan of shutting one group out.

[AdrianLxM]

I also think having to set a compile flag for features will lead to a lot of custom apk's floating around that will be hard to support.

[jstevensog]

I agree with Adrian. We cannot have it support a plethora of apks in the wild. We need some method within the official releases to allow people to choose the calibration method. And we should not release a method until we have thoroughly treated it ourselves.

---- AdrianLxM wrote ----

I also think having to set a compile flag for features will lead to a lot of custom apk's floating around that will be hard to support.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[tzachi-dar]

I guess that we all agree that we need to make improvements to our calibration algorithm, and that we can not release a new algorithm until we thoroughly test it. So, we need some way to allow us to write other algorithms, test them first, but not to give them to the public. I think that my suggestion is the best way for it. One code base and different behavior, for different people.