nightscout
Proposed change: max carbs absorption limit in preferences
AndroidAPS 3.3-dev: Lates dev builds Flavor: fullrelease
Observation:
I have been struggling with AAPS's carbs absorption for a long time. For me, carbs decay much faster than AAPS expects. In generally, this suggests IC/ISF profile settings may not be optimal.
No matter what I try:
- Either I have correct IC/ISF values, but carbs absorption in AAPS takes too long.
- Or carbs absorption in AAPS is ok, but IC or ISF values are not correct.
In both cases I end up with too much insulin and/or hypo's far too often. In general, I solve this by either underestimating carbs intake or using latest option to enter negative carbs.
Tried with higher carbs absorption settings in preferences. Maximum value for min_5m_carbsimpact is currently limited to 12 mg/dL/5 min. A value of approximately 16 mg/dL/5 min proves to works much better for me.
Proposed change: Proposing to change the max value in setting min_5m_carbsimpact from current max 12 to 24 mg/dl/5min.
Before doing a PR for this change, I would appreciate feedback on this proposal.
My idea on this topic is a bit different, to fix this kind of issue.
You currently have 2 parameters in absorption settings to limit COB with low dev bars:
min_5m_carbimpact which will define (with CSF or ISF/IC) a minimum slope for COB curve Max duration (between 4 hours and 10 hours)
Currently min slope is only limited by min_5m_carbimpact and profile, and if you still have remaining COB after max duration, then COB is replaced by 0.
- so during the period of carbs absorption, slope was too low to arrive at max duration with 0 COB max...
So my idea was to calculate min slope for COB curve using both parameters:
- when slope calculated with min_5m_carbimpact leads to 0 COB before max duration, this parameter is used
- when min_5m_carbimpact leads to 0 COB after max duration, then minimum COB absorption is calculated with max duration.
I'm not sure my explanations are very clear. 🙄
Yes, this would be better but I doubt that would solve my problems. Problem is that (most often) AAPS thinks carbs are still absorbing while actually they are not. Minimum carbs_impact effectively solves that.
Changing the max limit as is from 12 to 24 would not change the way AAPS handles carbs absorption.
That said: I have max duration set to 4hrs, but in real live my carbs duration almost never reaches max duration, I would not want to set duration to less than 4 hours as in special cases that could result in going high. I mostly see this as a safety parameter for just in case.... but maybe your idea would work?
What you are proposing does makes sense. Why not do both then? It would give addition options to personalize/tune carbs absorption.
I do not like making the slope dependent on max duration. I do think they are not and should not be related. Yes, good idea. Changing slope could solve part of the problem. But maybe then make this an additional parameter for user to configure? This way carbs absorption would be determined by:
- min-absorption_impact (current with higher max values allowed as proposed)
- IC/ISF factored with a user set slope parameter (new)
- Max duration (current)
With my proposal, I don't consider slope depends on max duration, I just try to make max duration safety settings and min carb absorption consistant together.
Carb absorption should mainly be calculated with deviation, not with min_5m_carbimpact nor max duration...
I don't like IC/ISF additional parameter. The only justification is to override current limit of min_5m_carbimpact parameter.
Think we agree on that. Then let's create a special issue for changing the way carbs absorption is calculated. But change may not be trivial.
This proposal/issue is only about changing the maximum user settable value of min_5m_carbsimpact from 12 to 24 mg/dl/5min.
#3359 is already open on this topic
Yes. And it is about a possible solution for the underlying problem, so preferred. 👍 Agree that proposed change in here fixes a problem that also needs solving at algo level.
And as you document in the PR: >> Carb absorption speed is not modified when BG value is constant between 2 BG readings and DEV is above min_5m_carbimpact (so with high insulin activity after the meal if BG value doesn't increase...)
And that seems to be exactly my problem? I often hover at relatively stable BG (higher than target but relatively "flat") for over an hour while high on IOB and activity decreasing as expected: but carbs decay far too low.
For me min_5m_carbinpact =16..18 (experimentally over 4 weeks) solves 75% of my problems. As mentioned, I can get carbs decay a bit faster through profile but then I consequently end up with either the wrong IC or ISF.
Q: I'd say the value for min_5m_carbinpact depends on the person. Why limit it to a value of max 12?
My proposal would be to change the current max (1 line of code) and then continue with #3359 to improve the underlying logic. Would you agree with this?
Long ago, I've made the same experience, that min_5m_carbimpact is too low for me.
Actually it was a security issue, as without a rise in BG after meal carbs didn't get used up. A lot of COB was floating around combined with lower BG levels and with the slightest rise in BG the loop thought now it all will absorb and bolused too much and I got low.
The value I use in preferences for years is min_5m_carbimpact = 18(!) But don't judge this value on its own, it only makes sense in combination with my other settings. While tuning IC and ISF to my needs, I've always kept an eye on the calculated min hourly carb decay rate and don't let it go under 20 g/h.
MinHourlyCarbDecayRate [g/h] = min_5m_carbimpact * I:C / ISF
min_5m_carbimpact is a failsafe value which should not be used most of the time. I'm not convinced we should allow higher values to fix something elese that doesn't work @scottleibrand
min_5m_carbimpact is a failsafe value
I agree on your arguments, but I think for some the current limit is too soft?
In my case, I know carbs absorption is really fast for me (high spikes on meals, i can recover from a hypo within 10 mins by just eating food - no need for Dextro), so faster than the algo predicts.... In general, this should be fixed in profile through proper ISF/CI. But for me, whatever I tried in the past, I end up with eighter wrong ISF, CI or the need to constantly applying neg carbs to prevent lows. A value of 16 on min_5m_carbimpact for me solves the problem most of the time...
So I think current limit is wrong for many. 🤔Question is:
- what are the risks involved with setting it higher than current limit (apart from going high)
- @scottleibrand why the limit of 12 mg/dl/5min?
Btw: the current PR#4312 was ment as an intermediate fix for a more final solution as proposed by @Philoul in issue#3359