Go back to using a 90m minPredBG lookahead for all insulin types #695
Conversation
|
@jaylagorio any opinion on this? If I don't hear any objections, I'll probably go ahead and merge it. |
|
No severe lows for two days (rapid-acting NR) with this PR. A 0.5.3 rig and 0.6.0 rig of a few weeks ago didn't have these problems (severe low, lots of rescue carbs needed). I think upgrading oref0 should never be able to cause severe hypo's (even if the settings are sub-optimal). This should be treated as a regression and we first need to go back to a safe/secure version. Perhaps the lookahead can be made configurable (with a safe default). |
|
"in some situations" - can I get a little more detail on those situations? I had a rather severe hypo last night but I think it was because of how I did the (unusually big, ~100g) no bolus meal and temp targets. Without oref0 had I bolused for the meal I think I still think I would have gone hypo BUT the result would have been harder to rescue. |
|
I'll let @PieterGit explain his situations, but generally I think it's any time the total impact of carbs ends up being way less than predicted by the CR. Sounds like you don't object, so I'm going to merge this. |
|
Nope, no objection! I'll pull it down now and try it today. |
|
@jaylagorio @scottleibrand Here is some more info on the situation. Multiple ISF and CR profile which worked ok with 0.5.3 and 0.6.0-dev before the extra lookahead.
Possible cause (according to Scott): Workaround for this was:
Then I tested this PR and it worked well. Back in 80%-90% normal range, no hypo's since. |
|
Interesting @PieterGit I’ve been seeing similar. Been too preoccupied with other stuff to investigate thoroughly but the repeated over correcting on food and rescue carbs is almost the same. |
|
@tim2000s : do you still see this with a dev rig after Oct 7, 2017 ( ff47d46 ) ? Can you confirm that this has been solved for you now? We did quite some changes to ISF/CR schedules, so it would be good if others (who didn't change other settings) could confirm if this was the case and now has been solved. |
|
Just run the update and will confirm tomorrow on progress. |
|
@tim2000s : do you know the version your rig was running when this happened. Scott assumes that it was caused by decreasing the 90m minPredBG lookahead, but maybe it was/is some other 0.6.0-dev commit. |
|
I'm also working on some other improvements that will help prevent UAM overcorrection if that's what you're seeing. |
|
I've just checked back vs the commits and I was running the 2nd October commit on the two rigs that I was struggling with. Interestingly, my other two were on the 29th September commit. |
|
Something I hadn’t expected. This morning is the first time since Thursday (when I first started running the 2nd October commit) that I haven’t had a noticeable rise between 5 and 7 after showering. I get the impression that the look ahead change affected more than just those SMB actions. |
|
I think you might be hyper-pattern-matching. I don't think there's any mechanism by which a shorter lookahead could result in any change in insulin dosing that would prevent a shower rise. |
|
😂. I can, however, confirm that my day has been significantly better with the changes. Very much reduced the hypo rollercoaster. |
Per @PieterGit the current 0.6.0-dev code seems a bit too aggressive in some situations for some users on rapid-acting insulin. In order to make it somewhat less aggressive, this reverts some changes that attempted to tie the minPredBG lookahead (where we ignore the first X minutes of predBGs when setting minPredBG) to the insulinPeakTime, and therefore makes eSMB less aggressive for non-Fiasp users.
Would like to hear input from others using SMBs with rapid-acting insulin and discuss if this is a change we want to make, or if it would make eSMB less effective and perhaps we should focus elsewhere.