Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
"Floating carbs" (or unannounced meals) #297
While OpenAPS was originally designed as a hybrid closed loop with the intention for people to still do their usual meal boluses and carb entry, several people have taken it upon themselves to try "unannounced meals" (and no meal boluses) with openaps.
We have outlined a testing approach to unannounced meal testing, starting with a small amount of known carbs and working up from there, but below have also described an idea of incorporating known "floating carbs" (new term made up as of here) into the closed loop as a result of observing all of this testing and the results reported from community members.
1. Unannounced meal testing approach:
To test how OpenAPS would deal with unannounced meals, we want to start with a very small snack, and work our way up to see how large of a meal it can deal with effectively, without allowing post-meal blood sugar to exceed safe ranges. While we will not be announcing the size or exact timing of the meals, we will be setting an Eating Soon temp target (and in later phases, entering carbs) well in advance of the expected meal time. This will simulate a system that learns/knows when mealtime “should” be and schedules Eating Soon mode to prepare for an unannounced meal at something close to the normal meal time.
Because you will not be bolusing for carbs normally, you can expect a post-meal BG spike that will get proportionally larger as you increase the size of the unannounced meal. We hope that Eating Soon and Advanced Meal Assist will be able to somewhat blunt that spike and eventually catch up to deliver all of the meal insulin and gradually bring BG back into range. We will start with a small and safe snack, observe OpenAPS’ behavior, and then decide whether to continue with progressively larger unannounced meals. Before starting, you should decide on the BG range (lowest and highest BG) you are comfortable with: ideally something like the range you would normally expect to see after a large meal without OpenAPS assistance. You will then progressively increase the size of the unannounced test meals until you see BG excursions outside the acceptable range, at which point you should stop that Phase of the test and decide whether to proceed with the next Phase of the testing.
Phase 0 (announced meals with carb estimates but no meal boluses):
Phase 1 (conservative, assuming no COB):
Phase 2 (more aggressive, assuming “typical meal” carbs)
Phase 3 (most aggressive, assuming “large meal” carbs)
2. Creating "Floating carbs" in DIY closed loop
Because many people are effectively doing unannounced meals - or unannounced carbs for corrections - and the loop is safely limiting post-carb spikes despite the lack of meal bolus, we theorize that it may be possible to do the following to further improve the outcomes in the time periods when there is carb ingestion :
Then... set the pre-configured "floating carb" amount. If BG rises and it's during the time period, begin decaying the floating carbs and allow AMA to begin based on that amount. The usual safety caps for AMA apply (read more about AMA here: #68), so if the BGs flatten or start to drop, it will back off high temping and do low temping as needed, even if there are potentially undecayed floating carbs; and after a time period those floating carbs will vanish.
One possible way to implement this might be to avoid guesstimating floating carb amounts (and trying to decay them), and instead just activate floating carb mode. That could be scheduled directly, as @danamlewis described above, but we may want to activate it for DIA hours after any "eating soon" style low temp target or bolus, and then either rely on some form of meal announcement (ES mode or bolus), or schedule recurring eating soon modes (or perhaps a higher and longer temp target) if we want to completely avoid announcements of any sort.
In floating carb mode, we could extrapolate the current deviations to continue into the future as we do with AMA today, but without AMA's ability to use COB=0 as a target for when to decay those deviations down to zero, continuing to extrapolate the current deviation indefinitely would likely result in slightly too much insulin delivery at the tail end of a meal. Instead, once deviations have started coming down from their peak level of meal carb absorption, we could project that the average rate of reduction of meal deviations over a 15-60 minute period would continue until the deviations drop to zero.
So in this scheme:
Some testing of this scheme will be required to determine whether it would work well using temp basals, as described above, and/or using supermicroboluses (SMBs) as described in #262, but it could likely be implemented to work in both modes. Depending on testing results, some additional limitations on projected deviations may be warranted, or we may find that properly configuring the current limitations on maximum safe basal rate, maximum IOB, etc. are sufficient.
In order to skip carb entry, we'll need autotune to exclude periods with unannounced carb absorption from being used to tune basal or ISF. A simple algorithm that probably would work for that would be to simply exclude BG data from time periods where netIOB is high (maybe greater than 1 hour worth of basal), as well as however long after that it takes for deviations to drop back to zero (as we do when attributing BG data to CSF). Trying that approach out in the autotune-uam branch (commit 42c6141)