Default Slopes about xdrip-experimental

[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.