-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Delivery Limit Improvements #16
Comments
Does the minimum basal setting mean Loop will not be allowed to zero temp if the setting is >0? Interesting concept! |
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
Discussion Details To build this branch, copy and paste into terminal and build as usual:
|
My suggestion for a guardrail: Your lowest programmed basal rate / 2. |
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
|
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 * Bump Loop submodule * Bump xcode version * Bump NightscoutService
Delivery Limit values should be displayed on the Settings page
Delivery Limits should be the closed loop delivery limits, not necessarily the pump's programmable delivery limits
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.
(Medtronic pump's max basal rate must be >= the highest scheduled basal rate).
Delivery Limits should include a minimum basal rate
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.
The text was updated successfully, but these errors were encountered: