Repository navigation
Delivery Limit Improvements #16
Description
Delivery Limit values should be displayed on the Settings page
- Having a Delivery Limits value of "Enabled" is (basically) useless
- Loop dev and presumably Tidepool Loop already do this
- Showing actual values consistent with all other configuration settings
Delivery Limits should be the closed loop delivery limits, not necessarily the pump's programmable delivery limits
- Some pump types have no hardware settable delivery limits (e.g, Omnipod), just design enforced delivery limits
- Pumps with settable delivery limits (e.g., Medtronic) just need compatible delivery limits. E.g., A user should be able to
selectively decrease the Loop max basal limit w/o the pump enforced delivery limit changing. Only when the Loop delivery limit
is increased to a value greater than the current pump maximum does this pump enforced limit need to be updated to match. - Allows for temporarily setting max basal rates lower than even the scheduled basal rates if needed/desired
(Medtronic pump's max basal rate must be >= the highest scheduled basal rate). - Provides better consistency across different pump types
Delivery Limits should include a minimum basal rate
- Gives advanced users/athletes more control
- Relatively obvious behavior
- Many users have requested to have over the years
- Consistent behavior with Delivery Limits being a closed loop delivery limit
Additional Details & Background
When doing mountain hiking, I find that having a starting max basal rate of slightly less than my max scheduled basal rate gives my good results. Over the course of the hike, I adjust up my max basal to eventually be my normal max works best (typically in 2-4 steps over the course of many hours). I have been doing this since I started with Loop on a Medtronic pump in 2016. I was no longer able to use this technique with the PumpManager rewrite for the Omnipod. At this time, I had to modify the Medtronic PumpManager code not to always force the Medtronic delivery limit to match a lowered Loop max basal rate. With the Omnipod, has never been a problem because there is no way to program a delivery limit on a Omnipod.
When doing mountain hiking, I find that having a minimal basal rate of 0.1 U/hr throughout the hike has been helpful (it prevents me from potentially getting absolutely no insulin for an extended period). This is not possible without having a minimum basal rate. I have talked with a number of marathoners who also require a very small, but non-zero, min basal rate during races or bad things can result.
Example Screenshots
Note that one screen is used for setting all of the delivery limits to match previous behavior.
Activity
bjornoleh commentedon Dec 2, 2021
Does the minimum basal setting mean Loop will not be allowed to zero temp if the setting is >0? Interesting concept!
update submodule Loop: implement min basal rate per feature request i…
update submodule LoopKit: implement min basal rate per feature reques…
update submodule rileylink_ios: implement min basal rate per feature …
marionbarker commentedon Dec 11, 2021
I have created a new branch (based off freeaps_dev branch) called issue_16/min_basal.
This should only be tested by well-educated users.
WARNING
There are no guard rails on min basal setting
Discussion
Before moving forward with this - let's talk about what guard rails are appropriate.
This should be tested under real-life conditions by someone with a Medtronic pump as well as Omnipod.
Details
I added the @itsmojo modifications (sent via PM) that he has been using for his own closed-loop system.
I tested this personally for more than a week on my own phone using an Omnipod.
To build this branch, copy and paste into terminal and build as usual:
Jon-b-m commentedon Dec 11, 2021
My suggestion for a guardrail: Your lowest programmed basal rate / 2.
I have scheduled basal rates from 0.8 to 1.5 (U/h). This would mean I cannot set a minimum basal rate higher than 0.4 U/h.
marionbarker commentedon Dec 19, 2021
The reality of the way Loop sets Temp Basal and the way Pods work make the setting of a "true" min basal a little problematic. No testing has been performed with Medtronic which might behave more as the user would expect.
Current process:
For Pods, in which the basal pulse is provided at the end of the cycle, there will be no pulses given for min basal of 0.10 U/hr (proven by experiment).
WIth TB of 0.15 U/hr, perhaps 0.05 U might be given once every 20 minutes, but it did not work out that way by experiment.
Examining the data, below, the 0.05 pulse is only delivered if the Cancel TB command is issued more than 20 minutes after the Set TB command and is not delivered if the timing is less than 20 min.
Summary of data below: In 2 full hours of supposedly min basal rate of 0.15 U/hr, the actual rate was half that. A total of 0.15 U was delivered in 2 hours.
Data from 2021-12-16 running with branch issue_16/min_basal
bjornoleh commentedon Dec 19, 2021
You are now operating in the range of basal rates that kids with low TDD is using. It doesn’t work very well with temp basal modulation, but AB/MB works much better.
Just a thought: could the minimum basal concept be modified to deliver the minimum rate as MB? It would probably need a significant rewrite, but would actually work with the lower rates. I don’t know how low you are hoping to get though.
Update NightscoutService and build order (loopnlearn#16)