Closed ktomy closed 7 years ago
Value before callibration: 136, callibrated on 191, new value: 166, delta (wrong): 24
This requires the logic to get the info from dexcom to see if calibration indeed happened, there are times that bg levels drops because of pressure or other reasons or spike very fast without calibration.
I would like to understand if we've ever seen a bad dosing decision as a result of this. Generally when I see a calibration that's way off, the loop overreacts slightly, but in the right direction. I don't recall any cases where the loop had to dramatically reverse course: it usually just cancels the temp after 15-30m (after the calibration jump drops out of avgDelta) and fine-tunes it from there.
Totally agree!
In my case loop switched basal from 0.3u/h to 1.2u/h for 15 minutes, which means 0.3u were made. Having ISF of 160, the change would be of about 50mg/dl. In my particular case it is not critical as the bg was 160, but it potentially can have a bad effect.
The response is always proportional to the size of the calibration jump. In fact, the amount of insulin delivered over 30m is equal to the amount of extra insulin required if the BG rises (over the next 30m+) the same amount it has risen in the past 15m. Since large calibration jumps can only occur when the CGM's reported SGV is way off the meter BG, and because of the way the Dexcom calibration algorithm works, the amount of extra insulin delivered over 30m would be approximately the same as the amount that would be required if you did a bolus wizard based on the meter BG. The amount delivered over 15m (at which point the avgDelta is normalized and anything excessive will be canceled) should be approximately the same as the amount required from the newly calibrated CGM's SGV.
If you can outline a scenario (contrived or actual) where the algorithm delivers too much insulin as a result of the calibration jump, I'd like to explore that with you. But as best I can tell, the actual effect of a calibration jump is that OpenAPS quickly high-temps enough insulin over 15m to cover the jump, and then cancels the high-temp after 15m (if you're still in range), but doesn't need to reverse course and low-temp unless BG is actually dropping at that point.
Yes, in fact you are basically right, so the worst thing that can happpen, you'll have 15 minutes of maxSafeBasal and the only thing we should be sure is that amount of insulin enjected during this period will not bring you lower than target_bg, starting from the burrent bg value.
I believe that the current algorithm meets that requirement. However, it would be useful to observe actual behavior around calibration events, as well as run through some test scenarios, and make sure that 15m of high temp does not bring eventualBG below min_bg.
I have been noticing this with HAPP too, but the impact is higher due to it being a Open Loop system and Temp Basal is suggested every 15mins (in my setup). If, it is not too difficult to get a calibration event from the CGM and we see a high deviation in BG, snooze the loop until we have 2 more readings since calibration. I agree the risks are very low, even with a High Temp of 15mins. But I still see value in having this.
How are you pulling data from the CGM? Do you have calibration events accessible? We are mostly using Nightscout for BG data from Share, so we can't get calibration records except when we have the CGM plugged in. We aren't retrieving calibration records currently, so this probably won't be a development priority for me in the near future, but if someone wants to work on it, I'd be happy to help as needed.
Agree this should not be a priority, as OpenAPS works on a 5min cycle you could argue this is a HAPP enhancement.
I am getting CGM from xDrip, xDrip does capture this info so if its not already in the Broadcast it would be simple to add.
After callibration delta should be calculated in a different way or we should stop the loop for a time to understand the trend after callibration.