NFC Fails on libre2 direct for ~ hour - smoothed data problem?

[nigelkeirross]

I am running Libre2 direct (no bridge). I had been receiving reading happily for some time, but then BT became disconnected. After a missed reading, I attempted an NFC scan, but this failed to generate a reading, despite making the usual NFC vibrations & sounds.
I looked in the log file, as seen below & I noticed that it appeared to be getting a correct/reasonable raw reading, but the SMOOTHED readings were 0, or in one case -1, and this seems to be the cause of the reading being rejected.

Reading Data
18:07 Removing point glucoseData = {sensorTime = 14809 glucoseLevel=113 glucoseLevelRaw=1486 glucoseLevelRawSmoothed = 0 flags=2080 source=FRAM glucoseLevelSmoothed-1}
and
LibreTrendPoint
18:07 LibreTrendPoint.isError returning true {sensorTime=14809 rawSensorValue=1486 flage=2080 source=FRAM glucoseLevel 0}

Can anyone shed any light on why this might be happening, and what can be done to fix this? It did eventually recover, but I missed about an hour of readings.

[PhilTU]

I've seen this often, values from scanning are deleted.

I think the root cause is zero values being assigned when an error is flagged on data read from FRAM. The zero then leads to an out of bounds smoothed value which is rejected. The one minute values at 14806 and 14809 are flagged in your screenshot.

Sometimes OOP2 shows a negative value. It appears to happen most if you NFC scan around the time of a Bluetooth transmission, if yo usee OOP2 collect a value and wait 20s then scan it may occur less (though often we scan because there is no BLE value).

[nigelkeirross]

Thanks. is FRAM the sensor memory? Thre NFC failed again this morning for about 45 minutes - and same pattern - it seemingly gets good readings, but according to the logs, the smoothed value is 0, or GlucoseLevelSmoother -1. This to me points to a bug in the smoothing process. In this case 3 consecutive glucose readings at 2743,2744 & 2745 all Glucoselevel 101, GlucoseLevelRaw 1075. So it looks like xDrip is getting good readings from the NFC, BUT somehow the smoothed values become 0, and so no reading accepted? Is there a way to turn smoothing off?

[PhilTU]

Thanks. is FRAM the sensor memory

Yes, the Flash RAM that NFC reads.

If you scroll down the values you might see the erroneous ones in the 15 x 1 minute values (rather than the 15 minute averages which are more stable)

[PhilTU]

Were there any flags setting an error condition?

…

On Fri, 14 Jun 2024, 09:44 nigelkeirross, ***@***.***> wrote: Thanks. is FRAM the sensor memory? Thre NFC failed again this morning for about 45 minutes - and same pattern - it seemingly gets good readings, but according to the logs, the smoothed value is 0, or GlucoseLevelSmoother -1. This to me points to a bug in the smoothing process. In this case 3 consecutive glucose readings at 2743,2744 & 2745 all Glucoselevel 101, GlucoseLevelRaw 1075. So it looks like xDrip is getting good readings from the NFC, BUT somehow the smoothed values become 0, and so no reading accepted? Is there a way to turn smoothing off? — Reply to this email directly, view it on GitHub <#3527 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ASFVQBYCVEF4KCTWK24NS6TZHKUNJAVCNFSM6AAAAABJA2K2CKVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TONZSGI3DO> . You are receiving this because you commented.Message ID: ***@***.*** com>

[nigelkeirross]

I don't really understand the question. Where would the flags be set, and what would they look like?

…

On Fri, 14 Jun 2024, 19:18 PhilTU, ***@***.***> wrote: Were there any flags setting an error condition? On Fri, 14 Jun 2024, 09:44 nigelkeirross, ***@***.***> wrote: > Thanks. is FRAM the sensor memory? Thre NFC failed again this morning for > about 45 minutes - and same pattern - it seemingly gets good readings, but > according to the logs, the smoothed value is 0, or GlucoseLevelSmoother -1. > This to me points to a bug in the smoothing process. In this case 3 > consecutive glucose readings at 2743,2744 & 2745 all Glucoselevel 101, > GlucoseLevelRaw 1075. So it looks like xDrip is getting good readings from > the NFC, BUT somehow the smoothed values become 0, and so no reading > accepted? Is there a way to turn smoothing off? > > — > Reply to this email directly, view it on GitHub > < #3527 (reply in thread)>, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/ASFVQBYCVEF4KCTWK24NS6TZHKUNJAVCNFSM6AAAAABJA2K2CKVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TONZSGI3DO> > . > You are receiving this because you commented.Message ID: > ***@***.*** > com> > — Reply to this email directly, view it on GitHub <#3527 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFAI7QHLIIMSVKMPWK73P6TZHMXZFAVCNFSM6AAAAABJA2K2CKVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TONZXGU3DQ> . You are receiving this because you authored the thread.Message ID: ***@***.*** com>

[PhilTU]

they're in your originl image - bad data values flagged by sensor perhaps

[nigelkeirross]

Thanks for the explanation. Yes, in the LibreTrendPoint section, both timestamp 2743&2745 had flags 2080. In ReadingData section 2743&2745 have flags2080, but 2744 has flags=0.
Where do I find how to decode the flags? 2080 seems common. Where are they documented?

[PhilTU]

I don't know if they are, it's a sensor error code I suspect and we're using software that is effectively reverse engineered https://github.com/captainbeeheart/openfreestyle/blob/master/docs/reverse.md . You might get a "try again in 10 minutes" alert from Librelink in this scenario.

I don't fully understand it, but my feeling is the flagged values are set to zero by LibreTrendPoint for safety. Why the smoothed value is -1 I don't know, it must be a response to the 0 value being below the 40 mg/dl sensor minimum ?

One day I might dig into the code and try to understand how this works. You raise a good point though, the negative values and missing data that occur with NFC scans are a pain, but do we need to NFC scan much these days ?

[nigelkeirross]

== but do we need to NFC scan much these days ? Thanks. I only NFC when I get a missed reading. It also seems to (re) initiate a connection. I sometimes have periods where I lose connections for up to 2hours at a time so end up NFCing every 5 minutes for hours at a time.

…

On Sat, 15 Jun 2024, 08:07 PhilTU, ***@***.***> wrote: I don't know if they are, it's a sensor error code I suspect and we're using software that is effectively reverse engineered https://github.com/captainbeeheart/openfreestyle/blob/master/docs/reverse.md . You might get a "try again in 10 minutes" alert from Librelink in this scenario. I don't fully understand it, but my feeling is the flagged values are set to zero by LibreTrendPoint for safety. Why the smoothed value is -1 I don't know, it must be a response to the 0 value being below the 40 mg/dl sensor minimum ? One day I might dig into the code and try to understand how this works. You raise a good point though, the negative values and missing data that occur with NFC scans are a pain, but do we need to NFC scan much these days ? — Reply to this email directly, view it on GitHub <#3527 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFAI7QEKA5DHZHIDFVD5A7TZHPR4BAVCNFSM6AAAAABJA2K2CKVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TOOBQGMZTK> . You are receiving this because you authored the thread.Message ID: ***@***.*** com>

[PhilTU]

It does initiate a connection but every 5 mins might be too much, the sensor broadcasts every 2 minutes when it has lost connection and you may find it takes several minutes to reconnect.

It's a shame there isn't more visibility of connection activity, the BT status page shows a countdown.

[gui-dos]

[PhilTU]

RF(32)

Thanks, the RF code came up earlier on xDrip from a sensor that was running very low glucose readings.

[nigelkeirross]

Thanks. From memory (I am travelling), my flags were 2080, so not sure how that relates. What does RF mean? Note I never knowingly NFC when BT is connected.

…

On Sat, 15 Jun 2024, 12:26 PhilTU, ***@***.***> wrote: RF(32) Thanks, the RF code came up earlier on xDrip from a sensor that was running very low glucose readings. — Reply to this email directly, view it on GitHub <#3527 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFAI7QDQ6ZWWL3GDYKNI5N3ZHQQFTAVCNFSM6AAAAABJA2K2CKVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TOOBRGMZDM> . You are receiving this because you authored the thread.Message ID: ***@***.*** com>

[nigelkeirross]

Thanks. So RF in this context implies NFC (being short for RFID), rather than RF in its more generic sense, since BT is also a RF transmission.?

[nigelkeirross]

Guido, In general I only NFC when connection is lost and I have missed a (5 minute) reading. Is it easy to see from the logs which readings come from NFC Vs BT. (I can look in oop2 to find recent BT readings). Also where do I find the decompiled code you refer to?

…

On Sat, 15 Jun 2024, 09:54 Guido Soranzio, ***@***.***> wrote: Whenever you scan a Libre 2 via NFC you typically receive a zeroed raw glucose value via Bluetooth as a signal to reinterpret the temperature field as an error code. One can easily find the definitions of such DataQuality constants in the decompiled code, and in fact you can verify that the 0x0020 (32) flag that you receive along the dummy 0 glucose raw value corresponds to RF, since the measurement is corrupted by the power usage of the NFC antenna. — Reply to this email directly, view it on GitHub <#3527 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFAI7QG7WZ4ZDCAGYLV4SM3ZHP6LZAVCNFSM6AAAAABJA2K2CKVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TOOBQG4YDI> . You are receiving this because you authored the thread.Message ID: ***@***.*** com>

[PhilTU]

Is it easy to see from the logs which readings come from NFC Vs BT.

Source = BLE vs Source = FRAM. In the yellow box is a standard 1 minute value received by BLE

The yellow circles are around flagged errors where BLE was the source :-

[nigelkeirross]

Thank-you that is very helpful. So FRAM is NFC, and BLE is a normal reading from a BT connection.
The reading at 17325 is interesting - the raw value 761 is similar to the one 10 mins later at 17345 789, so plausible,and yet the smoothed values for this are set to 0. & -1. Again this seems to me to point to the smoothing function often returning 0 where perhaps it shouldn't.

[PhilTU]

It's one of those things that could take a whole day of debate in a meeting - what value to assing to values flagged as error state and how to handle them in the smoothing algorithm. Rather than setting as zero I would personally treat a flagged value as not received.

[PhilTU]

Every minute the Libre 2 sends 10 measurements (4 bytes each): seven “trend” values and three “historical” values.

thanks for that. Interesting it sends every other one-minute trend value. I suppose a minute later the gap is filled so it's an interesting way of covering missed transmissions.

[gui-dos]

[nigelkeirross]

Thanks. So 2080 = 2148 (Thermistor) || RF (32). How do I know to interpret this as an error? Isn't "Thermistor out of range" also an error?

[nigelkeirross]

@gui-dos Thanks for the explanation of the jadx tool & looking into the Abbot APK. I have never done that but will try.