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.

Sign up for GitHub

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

Jump to bottom

Auto-increase CHO and not decrease problem #3343

Open
lostboy86 opened this issue May 19, 2024 · 14 comments
Open

Auto-increase CHO and not decrease problem #3343

lostboy86 opened this issue May 19, 2024 · 14 comments

Comments

@lostboy86
Copy link

lostboy86 commented May 19, 2024 •
edited
Loading

Install yesterday the latest dev build eb3fa57-2024.05.18.

I see my cho inserted with calc or normally, not decrease with time, sometimes autoincrease, very dangerous.
Yesterday i eat 189 CHO at 18.25 p.m. and this morning at 7 oclock i have 70cho remains, and after 10 minutes, increased to 80cho, without doing nothing.

DynamicISF enable.

Same thing happens with 3bb0705-2024.04.02
I try everything :

stop app and reopen
reboot phone
clean stats
clean db
suspect for ns 15.0.3 dev (but with another previous build installed, all work normally and cho decrease with time)

See the attachments (pay attention to the graphs of the first photo from yesterday)

photo_1_2024-05-19_16-51-14
photo_3_2024-05-19_16-51-14
photo_4_2024-05-19_16-51-14

i also attach the full log and the defaults log

AndroidAPS_LOG_1716129971548.log.zip
AndroidAPS_LOG_1716129949467.log.zip
@lostboy86 lostboy86 changed the title Latest dev auto-increase CHO and not decrease Auto-increase CHO and not decrease problem May 20, 2024
@vanelsberg vanelsberg mentioned this issue May 20, 2024
Open
@robertrub
Copy link

robertrub commented May 21, 2024 •
edited
Loading

It doesn't increase in my case but the carb reduction is much slower than usual. 37g after 3 hours are still there...

I use "basic" OpenAPS SMB algorithm.

Screenshot_20240521_120142_AAPS.jpg

Screenshot_20240519_173817_AAPS.jpg

@lostboy86
Copy link
Author

lostboy86 commented May 21, 2024 via email

@Philoul
Copy link
Contributor

Philoul commented May 30, 2024

Sorry for having being slow to understand your screenshots...
16h36 49g (DynISF selected ISF 169 instead of 60 in profile)
16h26 48g (but here I don't see variable ISF value).
=> was DynISF enabled at 16h26?

In 16h26 screenshot I can see an issue in -BGI curve at about 15h10 that have been fixed in screenshot done at 16h36. (your secondary curves settings definitively doesn't help analysis with too many things not comparable together). Please don't mix DEV and -BGI (generally together alone on same subgraph) with COB.

For your safety, forget DynISF for now... When you see an ISF value 2.5 higher (or lower) than your profile, it's OFF so not working for you...

@lostboy86
Copy link
Author

lostboy86 commented May 30, 2024 via email

@robertrub
Copy link

robertrub commented May 30, 2024 •
edited
Loading

@lostboy86 The COB value (residual CHO) is calculated using ISF. When your ISF changes drastically (as it happens with DynISF), your COB will change too.

If you turn OFF DynISF, you can check if COB values get back to normal. This test will enable all to see where the problem originates.

Also, 500g carbs (CHO) per day will take a very long time to be used.

@lostboy86
Copy link
Author

lostboy86 commented May 30, 2024 via email

@lostboy86
Copy link
Author

https://www.facebook.com/groups/AndroidAPSUsers/permalink/3775078956046827/

Is this related?

@Philoul
Copy link
Contributor

Philoul commented May 30, 2024

To explain how calculation is done for COB decay, you start from Insulin activity in Units per 5min (how many units are absorbed between 2 BG values (see Insulin curves)

With ISF you calculate how many you BG value should decrease due to insulin only (mg/dl /5min or mmol/l / 5min)
=> this is -BGI curve (always shown in mg/dl in curve scale whatever unit selected by user).

Then the Real BG value is received, and often different that the one calculated with insulin only. The difference between BG received from CGM and BG expected with insulin only is called deviation (mg/dl / 5min) and will be used to calculate amount of Carbs consumed to "increase" BG value during 5 min... (DEV curve).

For example if BG should decrease by 10mg/dl during 5 min due to insulin, but in reality it increased by 5 mg/dl. then deviation bar will be 5 mg/dl greater than -BGI curve, and the 15 mg/dl value (+5 - (-10)) will be used to calculate COB decay.

The factor to convert Deviation (mg/dl / 5min) to Absorbed Carbs is IC/ISF... (IC/ISF is also called Carb Sensitivity Factor (CSF) and unit is g / mg/dl ), so Deviation * CSF will be in g / 5min, so number of Carbs absorbed during 5min. This iterative calculation is done again every 5 min...

If Deviation value is too small (so carbs absorption too small), then there is a safety parameter (min_5m_carbimpact) that will fix the minimum value to calculate COB absorption (and the minimum reduction slope of COB will be min_5m_carbimpact * IC /ISF).

having an ISF value 3 or 4 times higher can have a huge impact on COB absorption speed if IC remains unchanged.

We should also check the impact on COB value shown in overview when you have important variation of ISF during the period of meal absorption...

There is an additional safety parameter (max meal duration), that will directly replaced remaining COB of a meal to 0 if meal is too old...

@ArthurusDent
Copy link

I have seen problems with carb decay twice now. I'm on bb1a276, which is the regular 3.2.0.3.

I'm using OpenAPS SMB.

Nightscout 15.0.2.

This occurred on 27-05-24.

Other than re-adding the carbs as described below, I didn't try anything else to solve the problem, so no restarts, no database reset.

I didn't take a screenshot from AAPS at the time but it was still visible in NS:
Screenshot_20240530_213713

When I noticed that the 45 g of carbs did not decay correctly, I deleted the carb entry in AAPS and then re-added the carbs, once as 45 g, then deleted those again and re-added just 35 g. This is what you can see here. Keep in mind that in the list this seems to have happened at around 10:15, when in reality re-adding happened maybe three or more hours later.
Screenshot 2024-05-30 at 21-35-24 204 3 →

Logs:
AndroidAPS._2024-05-27_02-00-19_1.zip
AndroidAPS._2024-05-27_02-00-19_2.zip

@lostboy86
Copy link
Author

Screenshot_2024-06-01-15-05-58-99_3eaa31bb2c2a38a1c605d9dc918cf694
Screenshot_2024-06-01-15-07-59-50_572064f74bd5f9fa804b05334aa4f912
Screenshot_2024-06-01-15-08-35-17_3eaa31bb2c2a38a1c605d9dc918cf694
Screenshot_2024-06-01-15-12-34-73_3eaa31bb2c2a38a1c605d9dc918cf694
Screenshot_2024-06-01-15-01-43-39_3eaa31bb2c2a38a1c605d9dc918cf694

I screenshot the bug (pay attention with COB value and phone timestamp in the upper status bar.

Cob increase from 1 tò 2, then 0, then lockscreen 2, etc

@robertrub
Copy link

robertrub commented Jun 1, 2024 •
edited
Loading

@lostboy86 In this case, the differences are very small and can be related to your changing ISF (due to DynISF) and rounding up or down. 0.5g will be rounded to 1 but 0.4 will be rounded to 0.

I copied them in chronological order

Screenshot_20240601_215130_Samsung Notes.jpg

@lostboy86
Copy link
Author

lostboy86 commented Jun 1, 2024 via email

@robertrub
Copy link

@lostboy86 As I said, it depends on your ISF and that changes all the time with DynISF. You need COB and ISF

@lostboy86
Copy link
Author

lostboy86 commented Jun 1, 2024 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@ArthurusDent @lostboy86 @Philoul @robertrub