I realized that I get serious problems, because the loop isn't executed at regular intervals (anymore). Yesterday it didn't run for 3 hours during exercises despite BGs coming in almost every minute. Result was a BG of 300mg/dl.
Looking through my log files I found that this happens quite often, with gaps from few minutes up to hours. In my case gaps are more frequent during day time, but at night can reach many hours too.
I asked on the discord channel, and heard from ga-zelle that he experienced the same especially at night and from theodoor that he and others had a similar issue on the dev branch.
He also mentioned that google most likely is the culprit. This would be my guess at well, that android kills the task executing the loop. However if this is true and is considered serious (and I think it is serious with potentially very bad results) wouldn't it be possible to run a watchdog which checks regularly whether the loop thread is still running and restart it if necessary? (Sorry I don't know enough about the internals of AAPS, so my wording may be completely wrong here).
I'm running this build version: AAPS 3.4.0.0+aisf3.2.0
on a Pixel 9Pro with grapheneos, Android 17
battery usage is unlimited for AAPS, energy saving is deactivated
BGs come from fsl3 via juggluco
I wrote a python script to analyze logfiles for those gaps, and the result for the last three days looks like this:
In 4318 minutes with 4089 BG values received: 1230 loop executions = 30%. Longest gap 267 minutes
A month ago it wasn't that bad:
In 4319 minutes with 3709 BG values received: 3046 loop executions = 82%. Longest gap 130 minutes
Maybe it's a good idea to first collect some more data from peoples logfiles to see how frequent or severe this is? Thus I attach the python script, which can be run by
% python3 grepForGaps.py logfiledir
it scans all zipped logfiles named like AndroidAPS._2026-06-03_03.log.zip and greps for "Firing EventNewBG" and "IOB data:"
grepForGaps.py
I realized that I get serious problems, because the loop isn't executed at regular intervals (anymore). Yesterday it didn't run for 3 hours during exercises despite BGs coming in almost every minute. Result was a BG of 300mg/dl.
Looking through my log files I found that this happens quite often, with gaps from few minutes up to hours. In my case gaps are more frequent during day time, but at night can reach many hours too.
I asked on the discord channel, and heard from ga-zelle that he experienced the same especially at night and from theodoor that he and others had a similar issue on the dev branch.
He also mentioned that google most likely is the culprit. This would be my guess at well, that android kills the task executing the loop. However if this is true and is considered serious (and I think it is serious with potentially very bad results) wouldn't it be possible to run a watchdog which checks regularly whether the loop thread is still running and restart it if necessary? (Sorry I don't know enough about the internals of AAPS, so my wording may be completely wrong here).
I'm running this build version: AAPS 3.4.0.0+aisf3.2.0
on a Pixel 9Pro with grapheneos, Android 17
battery usage is unlimited for AAPS, energy saving is deactivated
BGs come from fsl3 via juggluco
I wrote a python script to analyze logfiles for those gaps, and the result for the last three days looks like this:
In 4318 minutes with 4089 BG values received: 1230 loop executions = 30%. Longest gap 267 minutes
A month ago it wasn't that bad:
In 4319 minutes with 3709 BG values received: 3046 loop executions = 82%. Longest gap 130 minutes
Maybe it's a good idea to first collect some more data from peoples logfiles to see how frequent or severe this is? Thus I attach the python script, which can be run by
% python3 grepForGaps.py logfiledir
it scans all zipped logfiles named like AndroidAPS._2026-06-03_03.log.zip and greps for "Firing EventNewBG" and "IOB data:"
grepForGaps.py