Libre 1 - Sensor age has not advanced 5427

[JohhnyP]

Greetings.

I'm facing occasionally this error and cannot get readings from Bubble to xDrip.

I couldn't find any workaround it either fix itself after a while or I'm forced to change sensor.

Manual readings through reader or phone scans work fine so I'm pretty sure this is an xDrip issue and not a sensor issue.

Anyone has any idea?

I can provide whatever kind of info you need.

I'm on latest xDrip and the master phone is Samsung Galaxy A40 with Android 11.

Codeblock where the error is raised

else if (thisSensorAge == sensorAge) {
                // This is only a problem if we don't have a recent reading. It could happen that we have a recent
                // reading, and then BT disconnects and connects after a few seconds, and we have a new reading (where 
                // sensor did not advance). This does not mean that a sensor is not advancing. Only if this is happening
                // for a few minutes, this is a problem.
                if (BgReading.getTimeSinceLastReading() > 11 * 60 * 1000) {
                    Log.wtf(TAG, "Sensor age has not advanced: " + sensorAge);
                    JoH.static_toast_long(gs(R.string.sensor_clock_has_not_advanced));
                    Pref.setBoolean("nfc_age_problem", true);
                }
                return; // do not try to insert again

[nigelkeirross]

I am having similar problems with my current Libre2 sensor, reading direct (OOP2) with no bridge. Previous experience has been good, but now I am only getting about 60% of the readings, (sometimes will go over an hour with no readings) often messages "Sensor age has not advanced" or "sensor age has gone backwards". In system status the BT to the sensor is always connected. This also happens when I try NFC read from xDrip+ - only about 50% "work" even tho always "Scanned OK!" message. Are there any settings to override, or is it really a poorly sensor?

[Navid200]

@psonnera

[tzachi-dar]

you seem to have errors on your readings. See the message Librepoint.iserror returning true. This is why xDrip is ignoring this readings.
You might see some more values under "show libre trend" but the values can not be trusted.

[nigelkeirross]

Was that Ooops or Ooops2? I already had both of those Libre2 settings turned on, yet still no Raw data. My xDrip is from 2022-08-03.

[psonnera]

Ooops was: sorry forgot to tell you to enable raw data from Libre 2 in less common settings

[psonnera]

Strange...

[nigelkeirross]

It has been mostly good for the last 12 hours until 57 minutes ago ~ 1800 UK time, and no readings since then. I've tried NFC about 12 times and still nothing. I only has 5 "Sensor age has gone backwards at 1800, 1802, 1804, 1808 & 1813 - none since then (about 3 mins ago). So mostly raw=0 values I assume. But I have seen recently 2 non-zero LibreOOPAlgorithm message:
1854 Creating BG time=7631 raw=2085
1852 Creating BG time = 7629 raw = 2131
1848 Creating BG time = 7625 raw = 2090
but almost all the other such messages are raw = 0.
So why is it not using one of the non-zero values?

[nigelkeirross]

@psonnera The NFC readings, all of which are failing, seem to have a pattern of -16 values for the last 3...

[PhilTU]

"Was that Ooops or Ooops2? I already had both of those Libre2 settings turned on" - can you check this, I don't think settings related to Out of Process should be enabled for this configuration.

[psonnera]

Agree. If OOP1 was enabled by error we'd see the message: ignoring measurement due to external algorithm enabled. So, no, not the issue. The issue is sensor reading an error code (-16) instead of BG.

[filipedanunes]

I'm having the same exact problems for the last months using libre 2 direct. Do you have a y clue how to solve this problem?

[Navid200]

@PhilTU

[PhilTU]

I think this arises from scanning close to a BLE transmission, leading to odd values from the sensor.

The problem is compounded by the rogue values being processed (rather than rejected) which leads to odd values in the smoothed valur which are then rejected, losng otherwise good data.

But we should try to document exactly if it's repeatable. Does it happen without NFC scanning?

[nigelkeirross]

@PhilTU @Navid200 @psonnera I have also been seeing many "sensor age has gone backwards" messages, which correspond to the raw=0 every-minute readings. I have modified xDrip to send the 1-minute readings to my looper app, as well as each time the libre2 connection changes state - mostly on/off (0/19,8). These are then stored to a mysql database in the cloud.

I have many concerns about the BLE connection dropping between sensor & phone with Libre2 direct. So for the last 4 sensors I have been running in tandem - my main looping phone connected by the more reliable Bubble (mini) bridge, and a backup phone connected direct to the same sensor. In general there seem to be no problems running the 2 paths at the same time. However, I have been seeing a high level of raw=0 values on the direct phone. 9.7% (7865/81083) of the 1-minute readings are 0. Following @PhilTU's comment about this being caused by an NFC scan coinciding with the BLE reading (in this case the NFC would be from the Bubble device & since I have started this logging exercise I no longer NFC scan the direct connection - apart from at startup), as I want to be able to measure how quickly connection is re-established by itself. As I am storing all the CGM 5-minute readings from the Bridge phone, and all the 1-minute readings on the direct on the other phone, I should be able to see if indeed the raw=0 readings happen if they happen around the time of the Bubble (NFC) readings.

The other observation I have relates to the frequent disconnections of the direct link. 42% (4344/10234) of the re-connections immediately disconnect again (after 2-3 seconds) with no reading being transmitted. I would like to know if anyone else has seen this & knows if anything can be done about this.

Finally I have observed that many of the successful re-connections happen immediately before a 1-minute reading is transmitted. So it looks like when the sensor has a reading to send, it makes an attempt to connect. I am yet to do a detailed analysis of this & see how this might help ensure that connections are more rapidly re-established. I have lots of data to analyse. If anyone is interested I'd be very happy to send the datasets.

[PhilTU]

I did notice that it stays connected direct to L2 in favourable conditions, with over 2 hours lapsed since "last connected" in one instance. I assume this is expected behaviour with the Libre streaming values every minute and xDrip only reconnecting in the absence of received data.

I haven't looked closely at how it works though.

[nigelkeirross]

@PhilTU The attempt to re-connect is triggered in the BT callback - when the connection changes state to disconnected.