-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Calibration issues #54
Comments
Thanks for logging this issue. Can you drag-n-drop the entire file here instead of cut-n-paste? I can't read some of the columns in this format as they are #### . How old was this sensor? From what I can see, it looks like there is some significant variability from the g5 unfiltered value in last 5 calibrations. This level of variability usually indicates an old (or dying) sensor. The unfiltered value comes directly from the g5 sensor and the calibration comes from the meter. |
also, is it all the same sensor or is there a sensor change in the midst (i don't see one but just want to confirm). |
was this calibration correctly entered? seems like it should have been closer to 235 than 135?!
we probably need to find a way to throw out calibrations that don't make sense. |
Filtered diverges a ton from unfiltered at that same time, so something odd was going on with the sensor, probably not a good time to calibrate when they diverge: |
Yes, when they diverge like that, in my experience the sensor is on the way out. this brings up an enhancement idea ... shouldn't Logger be able to present this type of divergence to the user? Should noise factor divergence of filtered / unfiltered raw data from the sensor? I think it should. |
+1 xdrip+ reports something like 'unclear sensor readings' when filtered and unfiltered diverge |
noise can factor it in, but separately what about calibration - i think we also need to avoid using calibration data like that, since the noise can go away but the calibration will still be very broken. |
Agreed on both points. These changes are definitely something we need to do. |
Where / how should Logger report |
I'm not sure but for sure it should report a high level of noise when that's the case. Sometimes the BG is being reported as 38 or 39 in think. Will look it up. |
Looks like xdrip+ uses 38 for "error" ... and xdrip+ uses a hard range of only allowing 39 to 400 to go through. What does NS show for BG 38 value? Let me test that. |
That's how 38 shows up in NS. Probably a good error indication. |
we did disallow calibrations a while ago, when there is a high difference between filtered & unfiltered ("variation"). also fwiw, fixes for noise calculations and additional noise indications when native data is unavailable, are also going on currently... |
Noise refactoring is complete. We are all set for now. |
Following the issues I saw with the calibrations on logger, below is the content of the requested files:
g5.csv
Calibration-Linear.json
[{"slope":893, "yIntercept":26262, "formula":"calibratedbg=(unfiltered-yIntercept)/slope", "yError":19794, "slopeError":63, "rSquared":0.91372, "numCalibrations":8, "calibrationType":"LeastSquaresRegression"}]
calibrations.csv
The text was updated successfully, but these errors were encountered: