Enhanced Activity Mode Idea #593
Comments
|
This response addresses utilizing Loop during long aerobic activities rather than implementation of your idea. (As a reference, Saturday I rode 75 mi with nearly 8k ft of climbing.) I've had good results by changing insulin sensitivity when I ride, run, hike, etc. in addition to setting a workout target. For cycling, I make my ISF more sensitive to insulin by about 250 %, e.g. 1 u drops by 110 mg/dL instead of 45 mg/dL. For activities such as hiking, I modify ISF less. Changing ISF alone has yielded sufficiently good results for me to focus on cycling, running, hiking, etc., which is where I want my focus to be, rather than tinkering with insulin dosing or ingesting gu to correct. In this paradigm for cycling specifically, I bolus for some carbs but don't enter all of them and consider the context of what is happening next, e.g. bolusing before a descent > 25 min long but not before or mid-climb. One note about this approach is that when I have finished the activity, I have nearly no insulin on board, probably some carbs still coming on board, and am also going into a period of decreased insulin sensitivity due to standard post-workout physiology. This combination of effects can lead to very high glucose levels post-workout. To deal with this lack of IOB, I input the number of carbs I've eaten throughout the day (~150 g CHO but often more) and immediately bolus for a portion of that. Not bolusing for everything lets Loop modulate insulin delivery in response to glucose and consequently mitigates post-workout lows. |
|
I will try that. It sounds like you agree that an activity-mode that changes the target is not going to work. Maybe activity mode should do four things: Lower basals to W percent of normal. |
|
That sounds very similar to an idea based on a discussion I had with @tepidjuice in https://gitter.im/openaps/oref0, which is to proactively set the autosens ratio used for prospective dosing decisions (but not for retrospective IOB calculations) for the duration of the activity. That effectively sets 1/W == X == Y, and sets Z proportionally as well (as is already done in oref0 if enabled in preferences). |
|
Great Scott. 1/W == X == Y sounds good to me. It would just come down to which method to describe it to the user. Perhaps one of these two methods: "Reduce insulin during activity by factor of: (1.0 to 10.0)" 5 or "Percentage of normal insulin needs during activity (0-100%):" 20 Maybe have both a moderate and heavy activity mode. Ideally OpenAPS and Loop would do it the same way, and once this is in place, it is one step closer to a movement or HR sensor allowing an automatic mode. |
|
In OpenAPS we use the "% of basal" side of the equation for the autosens ratio, such that a 0.7 (the lowest it'll go automatically by default) represents 70% of normal basal, and 1.2 (the default maximum) represents 120%. The code for adjusting target based on autosens ratio is https://github.com/openaps/oref0/blob/master/lib/determine-basal/determine-basal.js#L105-L123, so if you wanted to do a ratio of 20% (0.2) for your activity, that would adjust a normal target of 100 to a new_target_bg of 260 (which OpenAPS would then proceed to cap at 200). So more likely if you were adjusting all four things, a bit higher ratio would work better, to get the high temp target to work in tandem with the lower baseline basal to set temp basals near 20%. A ratio of 0.4, for example, would set a target of 160 on a 40% basal. |
|
I've written some, terrible, code which seems to behave as I outlined in openaps/oref0#588. However I've only one rig so I haven't been able to properly test it. For me at least this method seems to be very effective at controlling bgls during exercise. As it both raises the target and reduces the control action to reach that target. Currently I manually set autosens.json and the auto_sens_max variable in preferences.json. For example, yesterday, I had roughly three hours of intense activity. I sey autosens.json to 0.4, to drop my IOB more quickly, and the auto_sens_max to 0.7. I stayed between 4.9 mmol/L -- 6.6 mmol/L the entire time. |
|
Today I tried this concept. I did the following:
The run and food had no big swings with my glucose.
|
|
I also wanted to weigh in and say that I have also tried Loop's exercise mode target and it has been very hit and miss. Yesterday, before working out my blood sugar was 80. I had my exercise target range set to 150-170 and ate 20g before 90 minutes of cardio. I proceeded to skyrocket to 300 and then 4 hours later I was 48. (See the screenshot below.) However, on Saturday I went on a 5 hour bike ride using exercise mode and things went really well. (I only needed to stop and eat some raisins one time and Loop even corrected to keep me in range when I ate too many.) I'm sure something must have been up with my sensitivity but I have no idea how I would go about implementing those changes without completing guessing.
|
|
@rsilvers129, I post a new issue with the same idea, i close it now and put here. Hi, exercise time is something difficult to manage with loop, i Have two options; 1 is open loop and put a temp basal for the exercise time and another is to put a workout mode for the time. But in fact the exercise time affect the time you’re doing exercise and depending of the exercise several hours after it. If I open the loop I have not control and if I put the workout mode I have the same sensitivity and the same basal, if I eat something to increase the bg and the Workout mode target is 120-150, the bg begin to rise, but when the bg is in 120 loop put my basal, and probably I need less basal, if I reach loop correct with my current sensitivity and probably is to much…also for the coming hour after exercise. How do you think is the best way to manage it? Could be possible to have a Exercise/illness Mode? could be some screen like that: |
|
It seems to me that implementing a temporary sensitivity scale factor, that would apply to ISF, carb ratios, and basal rates might work better than just a simple target change. |
|
Agree |
|
Those kind of changes worked much better in my test. |
|
@jessiepusateri I've found big differences between settings I need for long sustained exercise (distance running) and for more intense, shorter bursts (ultimate frisbee, which has more sprinting interspersed with slower jogging or breaks between points). The latter produces some adrenaline, which keeps BG up more. So that could be part of the difference between your two cases. An activity mode like what's described here would be great, but may work best for sustained workouts (or perhaps could work for both, but with a milder scaling for high-intensity workouts). |
|
You will just end up finding a scaling factor that works for the kind of workout you do. |
|
@rsilvers129 I'm glad that modifying ISF and other values worked well for you! |
|
One thing that I've found in all my trials is that timing is critical for getting this approach to work, and the mismatch in the times for these events means that workout mode isn't a one-button event. I have tried varying the timing to enact the changes and the magnitude of the changes (e.g. implementing both changes at the same time in between the two times here, moving temp target start time earlier/later, moving the change in ISF earlier/later), and this combination was by far the most reliable and successful for me: The window for changing ISF is very small in my experience. Setting it more than 10 min before I leave results in a high that can persist. Setting it much after I leave (>10 min) means that bg will drop (or may be low depending on starting bg, carbs eaten before, etc.). Changing ISF at the start of a workout without having set a temp target in advance is insufficient for mitigating lows in my experience. Because of the rigidity for modifying ISF, I wouldn't want its to be implemented automatically based on the timing of a temp target because leaving more than 10 min late is a common enough occurrence (e.g. riding buddies hit traffic, there is only one restroom at the start and so a long line ensues, etc.) that I wouldn't want to risk the extreme highs that are difficult to get to drop that result in implementing ISF too soon. As much as I would like to have a single action to do for working out, based on my experience, temporary changes to ISF and carb ratios would need to be separate from enacting temp targets. |
|
Setting basal to 15-20% of my normal has worked over and over. I have never tested changing carb ratio until today. I ate 100 grams of carb in pancakes before a 1.5 hours bike ride. Instead of telling Loop it was 100 grams of carb, I told it it was 20 grams. It worked. Had it told it 100, I would have needed lots and lots of extra carb to not go low. So, I am really hoping this feature can go in because now when I run or bike, I do the following:
Then I have to change everything back. |
|
@jessiepusateri brought this up at the Seattle meetup last night, and it sounds like she might be interested in helping code it up. It seems like everyone is converging on letting the user configure a temporary sensitivity scale factor, which would function as described above and adjust basals (primarily for IOB calculation), ISF, and CR accordingly while active. Not sure if we’ve discussed whether such a scale factor, if configured, should apply automatically when Workout mode is active, or if it should be a separate toggle. FWIW, the sensitivityRatio I’ve implemented in oref0 0.6.0-dev since this issue was opened is working well. The main difference would be in the UX for setting the scale factor and activating it. In OpenAPS that is done by setting a high temp target, but in Loop could be configured more directly. |
|
Oh great. OpenAPS already has this. Loop could also just activate it when activity mode is on, and for people who don't want this behavior, they could leave the ratio field on the settings page at the default. |
|
For implementation, I think it's imperative that enacting a scaling ratio have its own enact button separate from the temp target button and that it be visible on the main page of Loop. That way when looking down at Loop, it's easy to see what Loop's status is, e.g. whether a scaling ratio, temp target, or both are enacted. Having separate buttons would also enable distinct timing to enact or deactivate the settings. I would find this beneficial as the most successful strategy I have found is implementing the changes at different times, e.g. enacting the temp target 1 h in advance of a workout and the scaling factor when a workout commences. If the scaling button is in the settings page, enacting a temp target and a scaling ratio at separate times would require going into the settings page twice per workout (e.g. once to change it for the workout and then again to change it back to 100 % at the end in preparation for the next workout). Having the implementation of the scaling factor on Loop's home screen and separate from temp targets would mean that it's one less thing to forget or have to keep track of. Additionally, a distinct button means that the scaling ratio could be used in conjunction with either temp target or on its own. For example, using the scaling ratio with a lower temp target would be useful while flying, taking a medication that temporarily decreases sensitivity, or any number of other events that decrease sensitivity for a period of time. Having a separate button lets people combine temp targets and scaling ratios in combinations and timings that work for them in whatever combination that might be. |
|
@eszcloud I think that's a good point. Since we're considering a single scaling factor that affects ISF, carb ratios, and basal rates, perhaps we could add a status in the HUD and then have a button at the bottom that leads to a small action menu that is similar to the bolus menu where you can enter the factor and the duration that you want the factor to be active. I made a mock-up below. (Not sure if we decided upon percentage or decimal for the factor so I just made it decimal for now.) Also, if we add automatic sensitivity detection (autosens), the "calculated" scaling factor could display in that same HUD section when a user-entered sensitivity isn't active.
|
|
1.0 would be neutral, so I would default it to that when the user first opens the screen. It might also be useful to label it, either on this screen or a confirmation screen. I usually describe it based on the % of normal basal that would be considered neutral. |
|
Definitely, @scottleibrand. Some explanation like this would make sense. |
|
The challenge is that basals and ISF/CR are adjusted in opposite directions. You have to explain whether the ratio being used is multiplied by basals or by ISF. That’s why I prefer the “percent of basal” framing: ISF is an intuitively “backwards” (or at least confusing) metric. |
|
The wheel and everything looks good. Scott put a lot of thought into how to scale it, and it would be good to keep it consistent with OpenAps’s terminology. Plus it is a good way of doing it. |
|
@scottleibrand Oh right, I forgot that they were inverses. 😛 You're right, the metrics are a little counterintuitive because you'd think if you were "decreasing" your sensitivity factor from 100, you'd be less sensitive but maybe that's unavoidably confusing? Maybe a visual diagram like this that updates whenever the user inputs a different factor would help?
|
|
I like that. Then people can really see what it is doing. Need a way to trigger temp target at same time. Maybe two begin buttons. One will begin with existing target. The other will begin and also trigger activity target. Or one begin button and a checkbox that will toggle on activity target. |
|
Needs a cancel button also. |
|
@scottleibrand can you point me in the right direction to use this function? I would like to add it to the docs as well or is this dev branch only? |
|
@GlennCoco you should probably ask in the Gitter channel for OpenAPS or Fb Group, as it’s outside the scope of this Loop issue discussion on suggestions for Loop app in particular. |
|
Thanks @Kdisimone, I just realised I was asking in the wrong forum, Cheers. |
|
Once a way to change sensitivity is internally implemented, then it could be auto-adjusted based on heart rate. Check out how this app does prediction based on HR: |
|
Deleted. |
|
What’s the status of this idea/feature in Loop? Has it been implemented by anyone? Absolutely essential! :) |
|
If anyone has implemented it or has an interest in it, I’d love to try it or help with developing it if needed. |
|
After several tests, best solution for my 9 years old son and 1,5 hours of exercise 0-eat 15-30 Ch gr without inform to loop. |
|
I would like profiles with the timing option(Use profile x for 1,2,4,8hrs, indefinite). For me with aerobic, if I do not go to a temp basal/bolus/correction where basal is 1/10 of normal I often find myself dropping 1-2mmol/L in 5min. I would need around 100g CHO just to cover it. Currently I disable loop and use the pump's basal profile and manually adjust other things if I need to eat. This covers it most times but it depends on other factors like glycogen levels. Doing it based on current body movements or HR would not work. I need to plan this at 5hrs and at 2hrs prior or else be in the danger zone. |
|
It would be very cool if Loop could take activity tracker data into consideration for ISF. So if Loop saw an increase in activity activity It could automatically adjust the ISF for a certain amount of time after the time of the increased heart rate. |
|
Yes, an automated adjustment of ISP (and Carb Ratio and Basal) would be ideal. However, since these adjustments should really be made in advance, I’m not quite sure how that would work. Anyhow, I see that months ago (above) there was a detailed discussion about making a manual % adjustment of all three settings, but I’m not sure if anybody implemented that idea (maybe in their own fork). After a couple months using Loop, it’s more and more clear to me that I need this feature both for best glucose control and so that the “actual carbs absorbed” calculation in Loop is accurate. If anybody has implemented this feature somehow, or there’s other progress on it, please let me know. |
|
For me, using activity data would be about 2-2.5hrs too late. |
|
Edit: Just realized that someone else had already posted about using activity data. Great idea. But yeah, perhaps dynamic changes based on activity are too late to be useful? |
|
Hello all, I am new to Loop and GitHub over the last few months. I was wondering if there are any active efforts to incorporate something like the Apple/Samsung Health Active Energy/Calorie Burn data within the Loop basal adjustment calculations and found this string. For those of us who wear smartwatches to assist in computing the calorie burn off exercising, steps, heart rate, etc. it seems like this would be another valuable element to continue improving this close loop delivery process. A number of apps now have auto detect exercising so it doesn't need to be manually entered too. Here are a couple images of the Apple Health Active Data and a Power BI report I started pulling together to review this type of data for myself. It would be a nice enhancement to have it part of the close loop apps as a proactive process instead of a reactive reviewing of reports which will probably still be needed for parameter adjustment feedback. Any thoughts on this for this group? |
|
@shainey this has been discussed quite a bit. The biggest challenge we've seen (and why this really hasn't been pursued much further) is that by the time activity data is available and we know you are exercising, reducing insulin delivery or raising bg targets is often far too late due to the existing IOB. Most people have to make adjustments 1-2hrs ahead of activity time for any meaningful effect. We have discussed the possibility of a "carbs predicted" alert that takes activity into account along with all the other factors to recognize an impending low (or rather, then necessity of carbs to offset the trajectory). But that concept hasn't gained a lot of momentum thus far. |
|
@diggabyte What you mention is correct. That being said, it would also be helpful to have these different major glucose impacting elements within the app screen & Nightscout reports to share with parents, Endos, and others to determine better methods to address different exercise types in the future. With a combination of this information, individuals could understand when & how they would need to reduce the basal upfront before exercising depending on the amount of insulin onboard for the user. Lots of math their depending on numerous factors which systems do much better than the typical human guestimates. |
|
@shainey I agree that activity data would be very valuable within Nightscout. It appears as though there has been some work done to allow sending activity data via xdrip. See: nightscout/cgm-remote-monitor#3337 If/when that support is added to NS officially, it might be a lot easier for us to send HealthKit activity data directly from Loop. Might be worth opening a feature request under LoopKit specific to this to disambiguate from the discussion in this current thread. I think it's great idea. |
|
Thanks for the feedback on this @diggabyte! I'll put some additional thought into it and then enter the Loop feature request. Thanks for you & the team's support on Loop! It's a life changer for many individuals across the globe including me! All the best, Steve |
|
Exercise is complicated. One thing I think has not been discussed is the variation of insulin duration of action with mild exercise. My experience is that going for a walk after a bolus and a meal will lower my BG very fast, but does not change the total amount of insulin I need. Loop reacts to this by doing a temp basal of 0 for a long time which results in my BG rising afterwards. I often enter "fake carbs" for the amount that fits with the glucose change below the 0 line in the "carbohydrates" screen once I'm back to sitting at my desk. Maybe we should have variable absorption time for insulin, the same way we have for carbs. The suggestion to use exercise data (for example, from the Apple Watch) would make a lot of sense with this. Another thing we need is a way to manually enter glucose changes that we already know will happen, like before doing anaerobic intense exercise. This is another thing I'm trying to do with fake carbs, but the math is cumbersome. Finally, prolonged effect on insulin sensitivity could be incorporated. I believe that at some point, prolonged effect of exercise and fat/protein could completely replace any "trend-based" approximations (glucose momentum and retrospective correction) in Loop. I already run Loop with retrospective correction turned off because it does not work well with my exercise patterns. |
|
Is there still activity in this issue? If not, I think it should be closed because there is no support to implement it in Loop. |
|
While there's been a lot of thought put into this, the consensus seems to be that it will not move forward. I agree it should be closed. |
|
Unless I'm misunderstanding, it seems that much of what was originally proposed has been implemented in the Override functionality available via Katie's Jojo branch though there's no automatic activation of the override triggered by activity data. |
|
Overrides are the current step towards seeing how an activity mode might play about. There are still additional possibilities in a potential exercise mode, like increased insulin absorption speed, and delayed carb absorption, and using activity data in health. But for now, going to close this out, as most of the discussion is pre-overrides, and is lacking relevant context. Also, we don't need "idea" tickets for this, as there are many obvious possibilities. Future work in this direction should be actual work towards making something happen and realizing some of those possibilities. |
* added tidepool security plugin * refactor to provide security provider to pump manager * response to comments * response to PR comments * response to PR comment * fixed unit tests * all active plugins * corrected typo * corrected file name
* added tidepool security plugin * refactor to provide security provider to pump manager * response to comments * response to PR comments * response to PR comment * fixed unit tests * all active plugins * corrected typo * corrected file name
Yesterday I mountain biked for 4:20:00 in 92 degree weather, I once did a Marathon, and I have done 100+ mile road bike rides-so I get to use activity modes a lot. With a plain pump, I can do great simply by turning basal to 15-20% my normal rate. If I don't do this, I must eat about 30 grams of carb an hour, and that also works, but sometimes I just don't feel like eating/drinking or carrying so much food.
With OpenAPS and Loop, I set an activity-mode target to about 140. Problem is, those modes have never really worked for me unless I eat / drink non-stop. Yesterday for my 4:20 of riding, I had to eat 14 cookies to keep from going low during the ride. That amounts to one Oreo cookie every 20 minutes, or about 30 grams of carb per hour - the same as if I had a pump and did nothing to the settings. So while the activity mode gave me some extra margin of safety, it never really addressed the root problem.
My idea is for Loop to have a new configuration setting where you tell it what percentage of normal basal you want for when activity mode is active. It should accept a value from 0-100%, and I will set mine to 20%. It then reduces basal to this whenever activity mode is on.
The text was updated successfully, but these errors were encountered: