[3.0.0.2-dev-k] "Error CGM data unchanged for the past ~45m..."

[chrisbev]

[3.0.0.2-dev-k] Got "Error CGM data unchanged for the past ~45m..." but data had changed over the 4.7 to 5.1mmol range, see attached. NB using Tim2000 dISF latest. Error cleared after about 30min.

Reporting bugs

• Note the precise time the problem occurred and describe the circumstances and steps that caused the problem
• Note the Build version (found in the About dialog in the app, when pressing the three dots in the upper-right corner).
• Obtain the app's log files, which can be found on the phone in /storage/emulated/0/Android/data/info.nightscout.androidaps/ See https://androidaps.readthedocs.io/en/latest/EN/Usage/Accessing-logfiles.html
• Open an issue at https://github.com/nightscout/AndroidAPS/issues/new

[MilosKozak]

what CGM?

[chrisbev]

FSL2 with patched LibreLink. (NB Continuos yellow triangle).

[MilosKozak]

then it's by OAPS design. it's protection from state when FSL report constant (wrong) value for a longer time This restriction is not while using Dexcom

[chrisbev]

But it was reporting correct values AND they were changing? Please see the xDrip tab values for the 45mins?

[chrisbev]

AndroidAPS._2022-05-1700-00-05.1.zip

[chrisbev]

Log attached

[MilosKozak]

OAPS is checking delta and avg delta for that period which was close to zero in this case

[chrisbev]

OK thanks for answer and time....

[justmara]

AAPS check is wrong here. Because it checks long_delta. But the long delta would be zero for any period between two points of identical value. Thats how math works :) It you have two points of same value on graph - that means that sum of all changes between these points is zero. And this is exactly what average delta counts - it summarizes all the deltas and divides by count of elelements. It only shows the total change for period of time - difference between first and last point. But shows nothing about deviations. Bg could go +100..-100 for that period and total long_delta would still be 0. So this protection triggers when current BG is identical with 45min ago value, no matter what happened in between. It must be checking for every BG point's variation and trigger only if all the points for last 45 (btw, why 45?) minutes and range of +-1 from current bg. This behaviour could be considered suspicious.

If this check is really crusial - it must be moved out of determine-basal, because it simply does not have all the required data. And it can be applied, for example, on LoopPlugin level. Before (instead of?) even triggering loop.

[ga-zelle]

Hi @justmara I agree that the check on long_avgdelta is not sufficient to detect changes in bg. However, it is one necessary requirement if bg was really flat.