Skip to content
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

Open
itsmojo opened this issue Nov 27, 2021 · 5 comments
Open

Delivery Limit Improvements #16

itsmojo opened this issue Nov 27, 2021 · 5 comments

Comments

@itsmojo
Copy link

itsmojo commented Nov 27, 2021

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


IMG_6491

IMG_6492

Note that one screen is used for setting all of the delivery limits to match previous behavior.

@bjornoleh
Copy link

Does the minimum basal setting mean Loop will not be allowed to zero temp if the setting is >0? Interesting concept!

@marionbarker
Copy link
Collaborator

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

  • In other words, you can enter a min basal > scheduled basal rate and the min basal rate will be used for the next temp basal setting
  • I tested this scenario with dropping BG, so I knew I should get a TB enacted and it was set to min basal value I had deliberately set > schedule
    • I then restored a reasonable min basal setting of 0.1

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:

git clone --branch=issue_16/min_basal --recurse-submodules https://github.com/loopnlearn/LoopWorkspace
cd LoopWorkspace
xed .

@Jon-b-m
Copy link

Jon-b-m commented 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
Copy link
Collaborator

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:

  1. Loop sets a TB
  2. Next cycle, Loop calculates needed TB
  • If the same TB and less than 20 min since it was set - no action is taken
  • If the same TB and 20 min since it was set - TB is initiated again (cancel TB, set TB)

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

|    GMT   | TotUnits | Action
| 10:13:20 |    21.45 | Set Temp Basal Rate of 0.15 u/hr
| 10:33:27 |    21.50 | Cnx TB
| 10:33:29 |    21.50 | Set Temp Basal Rate of 0.15 u/hr
| 10:53:19 |    21.50 | Cnx TB
| 10:53:21 |    21.50 | Set Temp Basal Rate of 0.15 u/hr
| 11:13:25 |    21.55 | Cnx TB
| 11:13:26 |    21.55 | Set Temp Basal Rate of 0.15 u/hr
| 11:33:23 |    21.55 | Cnx TB
| 11:33:25 |    21.55 | Set Temp Basal Rate of 0.15 u/hr
| 11:53:22 |    21.55 | Cnx TB
| 11:53:24 |    21.55 | Set Temp Basal Rate of 0.15 u/hr
| 12:13:25 |    21.60 | Cnx TB
| 12:13:27 |    21.60 | Set Temp Basal Rate of 0.15 u/hr

@bjornoleh
Copy link

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.

Jon-b-m pushed a commit to Jon-b-m/LoopWorkspace that referenced this issue Jun 23, 2022
* Update NightscoutService and build order

* Bump Loop submodule

* Bump xcode version

* Bump NightscoutService
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants