ps2
commented
5 years ago Loop calculates the amount delivered from a dose using math that approximates the counters inside the pump. This, combined with tracking negative IOB, ends up basically doing what you're proposing. The negative IOB ends up acting like a "counter", triggering a higher rate eventually.
You're welcome to propose an update to the algorithm. I think showing actual delivery in example scenarios of current Loop dosing algo vs proposed Loop dosing algo would be necessary to evaluate this kind of change.
greglongo518
scottleibrand
Describe the bug Loop is built upon potentially frequently changing basal rates to manage bg toward target. The issue is that every time a temp basal is changed the "time until the next pulse" essentially starts over and is always reset to the maximum interval for that basal rate. This can result in pulses being delayed sometimes drastically especially for users with low basal rates. Eventually loop should make up for this, but it can potentially take a long time.
Attach an Issue Report Tap the Loop settings icon on the bottom of the screen, then tap Issue Report and attach it to this ticket.
To Reproduce Steps to reproduce the behavior: I was able to reproduce this behavior in a test session using omnipod (not hooked up to a person). I ran in open loop, and loaded up fake carbs, but limited the basal rate suggestions via the delivery limits settings for max basal rate. I started low and increased the setting to control the basal rate loop would suggest, and listened for clicks(pulses). I would then modify the limit setting and accept the increased temp basal shortly before the next scheduled pulse and observed that each time the pulse would be delayed with the new temp basal even though the rate enacted should have been increasing. This was because the new temp basal always put the first pulse at the end of the interval.
Expected behavior I expect that an app built upon managing blood sugar primarily by changing basal rates could handle changing of basal rates cleaner and without the potential for missed pulses. I believe this is one of the reasons why so many children that use loop have to drastically increase their basal rates (often 2x-3x) as opposed to without loop to try and make up for some of these missed pulses in an imprecise way.
Screenshots If applicable, add screenshots to help explain your problem.
Pump
Additional context I understand the change needed to fix this is really an algorithm enhancement and goes fairly deep into the core of loops algorithm, and also that any change would have to be done in a separate branch because it would change existing behavior for people that tuned to the current system and are running with higher basals to try and offset this problem, but without it there is a lot of uncertainty in dosing especially when dealing with users with low rates that are changed frequently. It seems like openomni has the ability to pass a delayUntilNextPulse parameter when setting a temp basal but currently with loop this is always set to the same value as delaybetweenpulses (at least for omnipod), causing the pulse to always come at the end of the rate. With acceptable rates as low as 1 pulse an hour and possible rate changes every 5 minutes this can cause problems. My suggestion would be to maintain the current phase position when changing temp basals or reverting back to the default basal rate. For example if you are .75 of the way to the next pulse on the previous basal rate you are changing, then maintain that phase position and set the delay until next pulse parameter the remainder of the phase ( .25 of the new rate interval from when you apply the temp basal). This would be a much smoother transitions between rates, and eliminate a lot of the randomness that currently exists.