Open danamlewis opened 6 years ago
alimhassam
commented
6 years ago How about another solution of using the carb_ratio at the time of the deviation for the calculation instead of the carb_ratio at the time the loop is being run?
Alternatively we can also use the carb_ratio at the carb entry time, but this seems like a sligthly bigger refactoring.
alimhassam
commented
6 years ago here is a sample commit just to show that first option, it would be a relatively small code change, and it seems like we already do a time lookup for isf.
https://github.com/openaps/oref0/commit/e75ae4e28d84c6431d43af3fa56a69050abceab6
scottleibrand
commented
6 years ago @marafie's issue reported at https://gitter.im/nightscout/intend-to-bolus?at=5b283f1b6ceffe4eba17a42c was at least partly due to carbs reappearing at midnight when CR changed from 28 to 13. If anyone else has a big change in CRs like that, you might want to make sure that the meal CR stays in place for the full duration of any carb absorption, multiplied by the difference between the two CRs. or, you can try as @marafie is trying, and bring the meal and post-meal CRs closer together while reducing meal time basal to partially compensate for the extra mealtime bolus insulin.
We might want to resume work on fixing this for 0.7.x
Foxy7
commented
4 years ago Hello, I've found this same/similar issue last night following a late dinner last carb entry was at 7:01pm.
CR changes from 17 evening dinner to 7 for breakfast at midnight. Posted here: https://gitter.im/nightscout/intend-to-bolus?at=5ea76c0c538b0e70705a4138.
Note, I've changed the breakfast CR time to 7am when most likely COB = zero. (Clearly i have another issue with the change from Breakfast to Lunch).
Having been through the NS reports i see that this issue has only happened for us in the past couple of days due to two reasons, lockdown means our day has shifted an hour later so we're eating dinner around 6:30pm and I've extended the DIA to 6hr this week, previously 5hr.
It's still unclear to me why such a large amount of carbs is calculated in the final hour, something to do with CFS?
Cheers,
Foxy7
commented
4 years ago here is a sample commit just to show that first option, it would be a relatively small code change, and it seems like we already do a time lookup for isf.
The change proposed looks reasonable, admittedly i'm not a proficient in JS.
What's the best way to test this? Installing on a second rig and running side by side in realtime over lunch makes sense to me, sending the data to papertrail and reviewing from there? (or a parallel NS site?)
I also think this is directly linked to issue https://github.com/openaps/oref0/issues/326 and will help generate useful data for analysing the potential variances in CR and subsequently ISF.
Situation: Someone reported what felt like unexpected behavior, where COB increased over time.
Details: Turns out that the lunch carb ratio was 35; later carb ratio was 9. After the carb ratio switched, COB was re-calculated using the new COB (as designed, since state is not kept). User was surprised by that, and getting more insulin led to later lower BG than desired.
Potential options for resolving:
In the meantime: I added a note to the docs page around prepping and pump settings to explicitly warn people around carb ratios being far off (and also added a DIA note, too).