alerts not firing on values that are too low.

[tzachi-dar]

We have had an issue where a hypo was not alerted.

Here is the situation:

1. intercept is a very big negative number (for example -60).
2. due to noisy sensor, there is no alert, (or actually alert is on the wrong time, when bg is still high).
3. when snoozing is over, bg is already on 9, which means that there are no alerts for it.

It seems that the main issue starts from the code:

public static BgReading create(double raw_data, double filtered_data, Context context, Long timestamp) {

        if(calibration.check_in) {
            double firstAdjSlope = calibration.first_slope + (calibration.first_decay * (Math.ceil(new Date().getTime() - calibration.timestamp)/(1000 * 60 * 10)));
            double calSlope = (calibration.first_scale / firstAdjSlope)*1000;
            double calIntercept = ((calibration.first_scale * calibration.first_intercept) / firstAdjSlope)*-1;
            bgReading.calculated_value = (((calSlope * bgReading.raw_data) + calIntercept) - 5);

        } else {
            BgReading lastBgReading = BgReading.last();
            if (lastBgReading != null && lastBgReading.calibration != null) {
                if (lastBgReading.calibration_flag == true && ((lastBgReading.timestamp + (60000 * 20)) > bgReading.timestamp) && ((lastBgReading.calibration.timestamp + (60000 * 20)) > bgReading.timestamp)) {
                    lastBgReading.calibration.rawValueOverride(BgReading.weightedAverageRaw(lastBgReading.timestamp, bgReading.timestamp, lastBgReading.calibration.timestamp, lastBgReading.age_adjusted_raw_value, bgReading.age_adjusted_raw_value), context);
                }
            }
            bgReading.calculated_value = ((calibration.slope * bgReading.age_adjusted_raw_value) + calibration.intercept);
        }
        if (bgReading.calculated_value < 10) {
            bgReading.calculated_value = 9;
            bgReading.hide_slope = true;
        } else {
            bgReading.calculated_value = Math.min(400, Math.max(39, bgReading.calculated_value));
        }

}

In this case, at least when things are not coming from share, we should not have values under 39 even if the calculation gives <10.

More than that, it seems to me (needs some more checking) that this function will never be called from share, only from wifi, or bt code, so fix should be easy.

Thoughts?

Can this be called from the share?

[AdrianLxM]

For very low values (impossible values) it shows the hourglass or "?AD". This is code 9 as far as I remember.

It should not simply show "LOW" as it is a value that is so low it cannot be reached if not by a faulty calibratio, a bad sensor, a scrambled transmission or a disconnected transmitter. But the "?AD" is not good as people don't understand it. Probably it should be just "BAD READING"?

Having no low alert means it jumped from above 55 to below 10 in 5 minutes. On a living person I would strongly hope it is a problem with the system.

We should make sure that the sql statement fetching the last reading for the "Missed Reading Alert" does not fetch values below 10. This is "BgReading.getTimeSinceLastReading()" respectively "BgReading.last()". If we use this function for the "minutes ago" as well, we might need to write a separate one as the "minutes ago"... but I'm not sure about that as I have no IDE atm.

[tzachi-dar]

A few notes:

1. As for the drop from 55 to 10 in a short time. Well here is what have happened: consider an alert on 80 and on 55.
2. bg behaves like this: 110, 105,100,95,90,85,80,75,70,65,60,55,50,45,40,35,30. quite reasonable, although falling fast for night time.
3. Due to noise + pressure on sensor the value are shown as: 110, 105, 79, 60, 55, 85 ... On 79 one wakes up and measures on fingers. He sees that things are at 110, snoozes and goes to sleep. BG continues to fall... After ~25 minutes, the 55 is first crossed due to noise again. since not much time has passed one does not measure again, but snoozes again.... On this snooze time, the system gets to very low values and does not ring again... This is a true story.

As for having the intercept on -60. I have seen a couple of sensors that did deserve this. No bad calibration, simply how sensor behaved. Using the xDrip algorithm, getting to this numbers sometimes happen. Probably needs a fix, but currently this is a legal situation.

For this reasons, I believe that we should not have values like 9 in the system. I believe that they have been entered by the share as out-of-band values. That is instead of real values. In data paths not of the share, we just don't need them.

Thoughts.

[AdrianLxM]

Ok, so we basically have the following situation:

1. We cannot show "LOW" to the user as (s)he needs to know that something is wrong. -> we cannot map it to 39.

2. You want to alarm for "low"

3. We cannot use one of the predefined dexcom error codes or it would alarm for those with "low" on share input.

Does the Dexcom receiver have values below 40 (or 39) at all? If not we could map it to 38, alarm for low but have the GUI show "BAD READING" or similar for 38.