You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
Raise ISF to X times normal.
Raise carb ratio to Y times normal.
Change target to Z mg/dl.
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).
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.
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?
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.
Reacted by Eric Jensen, Michael Pangburn, Kelly Watson, Kate Farnsworth, kwaadje, Alyssa Foxx and Barry Walstead
@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).
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.
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!
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.
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.
Activity
eszcloud commentedon Sep 25, 2017
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.
rsilvers129 commentedon Sep 25, 2017
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.
Raise ISF to X times normal.
Raise carb ratio to Y times normal.
Change target to Z mg/dl.
scottleibrand commentedon Sep 25, 2017
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).
rsilvers129 commentedon Sep 25, 2017
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.
scottleibrand commentedon Sep 25, 2017
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.
tepidjuice commentedon Sep 26, 2017
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.
rsilvers129 commentedon Sep 27, 2017
Today I tried this concept. I did the following:
The run and food had no big swings with my glucose.
jessiepusateri commentedon Sep 27, 2017
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.
davidmlb commentedon Sep 28, 2017
@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:

ps2 commentedon Oct 6, 2017
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.
francesc0-cgm commentedon Oct 6, 2017
Agree
rsilvers129 commentedon Oct 6, 2017
Those kind of changes worked much better in my test.
elnjensen commentedon Oct 6, 2017
@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).
rsilvers129 commentedon Oct 6, 2017
You will just end up finding a scaling factor that works for the kind of workout you do.
eszcloud commentedon Oct 7, 2017
@rsilvers129 I'm glad that modifying ISF and other values worked well for you!
29 remaining items
kparisella commentedon Jun 15, 2018
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.
beached commentedon Jun 17, 2018
For me, using activity data would be about 2-2.5hrs too late.
diggabyte commentedon Jul 26, 2018
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?
shainey commentedon Sep 15, 2018
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?


diggabyte commentedon Sep 17, 2018
@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.
shainey commentedon Sep 18, 2018
@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.
diggabyte commentedon Sep 18, 2018
@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.
shainey commentedon Sep 19, 2018
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
alexk7 commentedon Oct 30, 2018
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.
PieterGit commentedon Aug 23, 2019
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.
diggabyte commentedon Aug 23, 2019
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.
rustymonkey commentedon Aug 25, 2019
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.
ps2 commentedon Oct 10, 2019
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.
[COASTAL-1291] added tidepool security plugin (#593)