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

floating carbs #1357

Open
wants to merge 1 commit into
base: dev
Choose a base branch
from
Open

floating carbs #1357

wants to merge 1 commit into from

Conversation

scottleibrand
Copy link
Contributor

If floating_carbs: true, then dose slightly more aggressively by using all entered carbs for calculating COBpredBGs. This avoids backing off too quickly as COB decays. Even with this option, oref0 still switches gradually from using COBpredBGs to UAMpredBGs proportionally to how many carbs are left as COB.

In our testing with floating_carbs: true and a higher BG target during the day (120 instead of 100), we've so far found that oref0 with SMB and UAM is better able to keep BG in range and avoid high BGs after COB decays.

Conflicts:
	lib/determine-basal/determine-basal.js
@sulkaharo
Copy link
Collaborator

Does this indicate the COB model is not accurate? Or that the COB model as such is fine, but the model that's currently being used not accounting for proteins / fats and not decaying carbs as fast as now accounts for the total meal absorption better?

@scottleibrand
Copy link
Contributor Author

No, I don't think it means the COB model is inaccurate, just that we are using it more conservatively than may be ideal. With the default min_5m_carbimpact value of 8 mg/dL/5m, COB pretty reliably decays to zero by the time carb absoroption stops, but sometimes there is residual carb absorption after it decays to zero. With lower values like 2 mg/dL/5m, COB doesn't always decay completely when there are "disappearing carbs" (situations where carbs are digested but don't have their full predicted effect on BG). Floating carbs aims to preserve proper (conservative) COB decay (so users can see how much COB they almost-certainly have left), but allow slightly more insulin dosing as COB decays, if and only if high rates of carb absorption (high deviations) are observed.

@tim2000s
Copy link
Contributor

I'm finding that floating carbs isn't running Autotune correctly overnight.
Every time it looks like it has run, but there's no change to the basal profile.

@scottleibrand
Copy link
Contributor Author

I'm not seeing that. Can you take a look at the latest autotune.2020-02-*.log file and see if you can tell why? Feel free to post a suitably redacted autotune log file / snippet if you'd like us to take a look at it.

@tim2000s
Copy link
Contributor

My mistake. User error on what I was diffing.

@scottleibrand
Copy link
Contributor Author

We ended up not using this, and didn't merge it to 0.7.1. Is anyone else still using it who wants to try to get it working and tested for 0.7.2? Or should we close it out?

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

Successfully merging this pull request may close these issues.

3 participants