Calibration issues about logger HOT 15 CLOSED

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.
It looks like noise level was high as well which is expected also when meter BG values are so far off the sensor values.

from logger.

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

from logger.

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.

from logger.

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:
1519363085 ########## 249856 134752

from logger.

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.

from logger.

+1 xdrip+ reports something like 'unclear sensor readings' when filtered and unfiltered diverge

from logger.

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.

from logger.

Agreed on both points. These changes are definitely something we need to do.

from logger.

Where / how should Logger report unclear sensor readings when filtered and unfiltered diverge? Is there a way to get that over to NS in the BG record?

from logger.

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.

from logger.

Looks like xdrip+ uses 38 for "error" ... and xdrip+ uses a hard range of only allowing 39 to 400 to go through.
https://github.com/jamorham/xDrip-plus/blob/d35274d20133c32008a21ed60a209b68bd7ff9bc/wear/src/main/java/com/eveningoutpost/dexdrip/Models/BgReading.java#L538

What does NS show for BG 38 value? Let me test that.

from logger.

from logger.

That's how 38 shows up in NS. Probably a good error indication.

from logger.

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

from logger.

Noise refactoring is complete. We are all set for now.

from logger.