Libre one minute testing

[jamorham]

Over time we have been progressing to be able to support 1 minute readings. This work isn't complete but it is at the stage where users can test it out.

This currently only works with patched app data source but may be extended to other data sources as required.

To test this feature out: (use Feb 15th nightly onwards)

1 - Make sure to be using engineering mode https://github.com/NightscoutFoundation/xDrip/wiki/Engineering-Mode
2 - Make sure you are using the patched app data source
3 - Go in to xDrip main settings and search for one minute
4 - Enable the one minute checkbox - be sure to read the associated warning
5 - Now you need to either force stop and re-open the xDrip app or reboot your phone to effect the change. The same is needed if you want to disable the feature again later.

Please observe how the app performs. Does everything work as you would expect?

Things to check:

• Do alarms work correctly?
• Does predicted low feature work correctly?
• Do trend arrows and deltas show correctly?
• Do you get missed readings?
• If you broadcast or upload the data from xDrip elsewhere what happens to these receivers?
• Try with and without the graph smoothing preference switch enabled.

It is expected that this change will in its current form cause some problems. Please itemize anything you notice, with screenshots (if appropriate) The idea of user testing is to identify the best way to resolve these issues.

For example there will likely be a smoothing emitter which can receive data at any interval and then emit to services that can only accept 5 minute readings at that rate. This is work in progress still.

[PhilTU]

I have noticed an apparent "duplication" of data points on the chart which I think arises from backfilling missed data overlapping recorded data points. In reality it is backfilled data points with different values to the actual data points in close proximity, the times are different so it is not truly duplicating, but on first glance at some zooms it looks like there are two lines.

The backfilling looks to generate data points from the sensor history, as the latter is a 15 minute value so presumably some interpolation is used. Apologies if my interpretation is flawed.

[PhilTU]

Just to add that in general this feature is working well, I share data to a MiBand via Watchdrip+ and that has worked too. Noisy data, alarms and trend arrows have so far behaved as expected. I am hazy about the backfilling feature (regardless of the time base).

[JimZam]

Hello. I think it's a good option long time awaited, but IMHO it's not so important to get readings every minute as to make them reliable and smooth, and follow the trend as fast as possible. While trying 1 minute readings, xDrip got a wrong too high value and it made xDrip to be far behind the real levels for 15 minutes because, as far as I know, it uses a weighted average from the last 5 to 20 minutes. Maybe it could be improved, I don't know...
On the other hand, it makes my phone and watch battery last less, and I realized AndroidAPS doesn't get every readings, sometimes it skips one or two and receives one after 2-3 minutes and then every minute till that happens again, just to make you know.
As always, thank you so much.

[SimonPhilpott]

Hello. I think it's a good option long time awaited, but IMHO it's not so important to get readings every minute as to make them reliable and smooth, and follow the trend as fast as possible. While trying 1 minute readings, xDrip got a wrong too high value and it made xDrip to be far behind the real levels for 15 minutes because, as far as I know, it uses a weighted average from the last 5 to 20 minutes. Maybe it could be improved, I don't know... On the other hand, it makes my phone and watch battery last less, and I realized AndroidAPS doesn't get every readings, sometimes it skips one or two and receives one after 2-3 minutes and then every minute till that happens again, just to make you know. As always, thank you so much.

I think the toll on battery is fair, but when values are changing rapidly, especially during events like double arrow drops and raises then 1 minute is extremely useful. I wonder if this is something that can be toggled from situational triggers like +-change in the last 5mins == true then switch to 1 min until == false

Either way, @jamorham a great piece of work.

[enpa23]

I think the toll on battery is fair, but when values are changing rapidly, especially during events like double arrow drops and raises then 1 minute is extremely useful. I wonder if this is something that can be toggled from situational triggers like +-change in the last 5mins == true then switch to 1 min until == false

There's already something like this in "speak readings" settings, you can set a new speak when bg values change by an x delta or every x minutes, where x is a value set by the user.

[cO5Mo2]

Fantastic addition! Thank you! Running it since today and so far no problems with xdrip, nightscout or AAPS. Two questions tho:

-What is the recommended way of getting the sensor data? Juggluco and the patched app?

-Is it possible to use the exact values that the Freestyle app delivers and disable any kind smoothing? In the screenshot you can see the difference between the raw data and the smoothed curve although I disable every possible smoothing setting.

Thanks in advance!

[JimZam]

@cO5Mo2 You can use xDrip+OOP2 or Juggluco/Librelink patched to xDrip. xDrip uses weighted average values so you will never get Librelink patched app or Juggluco values unless you modify the code and compile it by yourself.

[SimonPhilpott]

Would this setting merge with the Wear app, so watches can also collect per minute?.

Battery drain might be someting to test,

[walternautic]

I tested the combination juggluco/xdrip. It worked fine.
Missing data is not retransmitted to xdrip when the sensor is connected again.
@jamorham please take a look at the statistics. The GVI and PGS value seem to be much to low.

[blaqone]

Using xdrip to AAPS with one minute values works perfectly.
Sadly Juggluco sometimes sends the values in a shorter timeframe. And this is the result:

There is often only one second difference - therefor can we get rid or decrease the value of the sanity check (60s)?

I think it depends on the sensor itself - with one fl3 I had no problems at all - with another one it get it all the time.

[blaqone]

Nobody interested in this? @jamorham

[aljinovic]

@jamorham will it be possible to use the 1 minute testing with direct Libre2 connection?

Additionally, which connection would you recommend for Libre2, patched app or direct?

[aljinovic]

I've managed to setup Juggluco + xDrip to get the 1 minute readings working.

It works well, just a couple of observations:

• the trend is still calculated based on the 5min reading interval, so a glance at a graph actually gives better information
• I'm not sure if the calibrations take into account the 1min or 5min intervals. Ideally it should calibrate using the closest reading back in time when the calibration was actually done?

[blaqone]

With one minute raw data + calibration sent to AAPS

Smoothing happening in AAPS

[Npavkov]

I would LOVE to test this functionality with "Nightscout Follower" option!!!!! Is that possible??

[blaqone]

Of course it is. Here is a screenshot

[aljinovic]

@jamorham would it be possible to enable 1 minute readings for libre 2 direct Bluetooth connection?

[hermanhobnob]

@jamorham Is there much work to get this working with a direct Bluetooth connection via OOP? The patched app is working great but I bet I'm going to get told off (in the nicest possible way) for not not uploading my data to the libre cloud before long.

[PieterDeBruijn]

Can I get this one enabled when in xDrip+ Companion mode gathering from our CamAPS. We've switched from Dexcom G6 to Libre 3 and would like to get our 1 minute measurements to Nightscout (and it's followers).

[andrenicGH]

I'm using Libre 3 with xDrip+ using Web Follower interface (LibreLinkUp). Is there any update planned to have that interface support 1min update rates? Other services using LibreLinkUp support this (like G-Watch Wear App), so it is supported on the cloud side it seems.

[aljinovic]

@jamorham would it be possible to enable 1 minute readings for libre 2 direct Bluetooth connection?

@jamorham any update on this one please?

[zombeek]

Hi, thanks for your effor to make xDrip+ great app.
Daughter's setup is FSL2->Diabox->xDrip+->NS/AAPS. Her xDrip+ seems OK, but we use it only as master BG source for our follower xDrips, where all monitoring and alamrs take place. The followers still getting / displaying BGs in 4-5 min intervals. It would be great if the follower can see what master sees - both 1 minute inteval and raw data which hints whether a rapid change is going to happen soon. See following screenshots from 1-minute master and 5-minute follower.

Side note - I'm still using old Pebble Time (and planning keep using them like forever :) ) and it would be great if I am able to see current values (BG, diff, value age), it easier to spot signal outage, but it is of course no deal breaker.

[PythonFZ]

I'm using Libre 3 with xDrip+ using Web Follower interface (LibreLinkUp). Is there any update planned to have that interface support 1min update rates? Other services using LibreLinkUp support this (like G-Watch Wear App), so it is supported on the cloud side it seems.

I second this. I'm using the following to avoid the smoothing in xDrip (#2980)

flowchart LR

Libre3 --> Juggluco -->|webserver| xDrip <--> AAPS
xDrip<-->nightscout<-->AAPS

Loading

[ga-zelle]

I use the same setup as blaqone and see the same problem as he reported above on April 8. Is there some progress in reducing the synchroniasation check to e.g. 58sec?

As further analysis I compared the libre3 raw and smoothed data as listed in the BgReadfings table and also the BG values and times as used by the AapS loop:

I get an expected delay due to the smoothing of about 5-10 minutes, BUT there is a further delay of 5-10 minutes for passing those smoothed values to AAPS.

[jrdeutsch]

I'm using Libre 3 with xDrip+ using Web Follower interface (LibreLinkUp). Is there any update planned to have that interface support 1min update rates? Other services using LibreLinkUp support this (like G-Watch Wear App), so it is supported on the cloud side it seems.

I second this. I'm using the following to avoid the smoothing in xDrip (#2980)

I third this request.

[hpcolus]

I'm using Libre 3 with xDrip+ using Web Follower interface (LibreLinkUp). Is there any update planned to have that interface support 1min update rates? Other services using LibreLinkUp support this (like G-Watch Wear App), so it is supported on the cloud side it seems.

I second this. I'm using the following to avoid the smoothing in xDrip (#2980)

flowchart LR

Libre3 --> Juggluco -->|webserver| xDrip <--> AAPS
xDrip<-->nightscout<-->AAPS

Loading

What is your setting in xDrip? Nightscout follower? url-> 127.0.0.1:17580 did not work for me

[aljinovic]

@jamorham would it be possible to enable 1 minute readings for libre 2 direct Bluetooth connection?

@jamorham any update on this one please?

Hi @jamorham , any news maybe? I'd be happy to test this out if it's possible.

[Jackenmen]

The feature works as expected in my testing with Libre2 + Juggluco (been using it for a few weeks without any issues), the battery drain is a bit much though it's mostly not due to anything that xDrip+ itself is doing - the majority of my battery life usage is from AAPS since it invokes the determine_basal logic whenever it receives new data and acts on it (i.e. communicates with pump) when necessary. I'll have to do some comparisons by going back to 5-minute readings but since the one-minute readings happen 5 times more often than 5-minute readings, I expect that battery usage of AAPS being at least 5 times higher is quite likely.
I will see...

If xDrip+ allowed to set how often it broadcasts data, that would help but on the other side, so would AAPS giving an option to limit how often the whole determine_basal logic runs so I'm not sure if it's necessarily xDrip's job. Doing it on xDrip's side means that AAPS's graph wouldn't show as much (assuming xDrip wouldn't broadcast historical data as well which... it could considering that the broadcast bundle includes the time as well) but it may at least be easier than getting AAPS to change.

[hansj10]

The libre3 time variance with juggulco is annoying. (refusing to broadcast a reading which is too close to previous sample/1minute check)
Why is this error needed anyway?
I would propose to switch this off.
The rate limitation, or value interpretation should be done on the receiving side, not on the sending side.
just my 2cents.

[blaqone]

It HAS to be on the receiving side aka XDRIP+ because Juggluco sends a value once it is sent from the FL3 sensor. The hardware clock of the sensor sometimes sends values to Juggluco between 57 - 64s depending on the reading of the sensor.
Juggluco just forwards it ….

I just commented this out in xdrip! Don’t know why it is still in there …

[hansj10]

Hi Blaqone,
Stupid me, I didn't recognized the juggluco connection to xdrip as receiving side as its just connects the sensor to xdrip.
So yes, this incoming values are to be accepted any time, removing the error message.
With this error message one will get an two minute update instead of one minute update that is used in xdrip and connected devices, as the error message just states that that value is not accepted.
hansj

[aljinovic]

@jamorham would it be possible to enable 1 minute readings for libre 2 direct Bluetooth connection?

@jamorham any update on this one please?

Hi @jamorham , any news maybe? I'd be happy to test this out if it's possible.

Hi @jamorham, would it be possible to enable 1 minute readings for libre2 direct Bluetooth connection?

[aljinovic]

Hi @jamorham, would it be possible to enable 1 minute readings for libre2 direct Bluetooth connection?

Hi @jamorham, a kind reminder for libre2 direct Bluetooth 1min option.

[Teute0815]

@PhilTU

I have noticed an apparent "duplication" of data points on the chart which I think arises from backfilling missed data overlapping recorded data points. In reality it is backfilled data points....

How do you backfill missed readings from Libre? I can't get that to work. Checking the according box in "Settings/Less common settings/Other misc. options doesn't do anything. Am I missing something? Is that only a OOP2 thing? Or is that incorporated only by using the "1 minute feature"?

Sorry for asking here. I couldn't find a related discussion to ask or a way to contact you directly.

[PhilTU]

How do you backfill missed readings from Libre?

NFC scan with patched app in this case, from memory. Note how some of the readings in the glucose data table are "native" and not on the 1 minuite time schedule. It is a while ago. I was using the actual patched app, not an emulation.

Does juggluco not collect 3 values and backfill ? Some discussion here maheini/FreeStyle-Libre-3-patch#12

I also found "Skipped values, e.g. because you were too far away from your phone, will not be backfilled."

[Teute0815]

Does juggluco not collect 3 values and backfill ? Some discussion here maheini/FreeStyle-Libre-3-patch#12

I also found "Skipped values, e.g. because you were too far away from your phone, will not be backfilled."

juggluco can backfill in juggluco. But dev says, that sending those through "Libre2 patched" broadcast/source "does weird things in xDrip", so he disabled it in the brodcast.

Do I understand right, that you're using Libre2 Sensor and source "patched app"? I never got that to backfill as well.

Now, I'm on Libre3 and have to use juggluco via emulated "patched app" or "local Webserver". The local webserver seems to backfill but got other issues.

[PhilTU]

I don't use patched app normally. I can see from what I wrote at the time about backfill but it may have been NFC scan I don't recall.

[Teute0815]

I don't use patched app normally. I can see from what I wrote at the time about backfill butbit may have been NFC scan I don't recall.

Thanks for your reply. I will test the NFC scan option.
I'm wondering if that is a former L2 feature and applicable to L3 as well? And is the warning (highly experimential/own risk) still valid, or is that a regular setting now (it's not "hidden behind developer mode wall")?

BTW: To anyone reading here and having a clue: The developer of juggluco once asked me, if he could just send (historic) libre data through the dexcom source.
Is that possible/Could that be a solution (for juggluco users)?
Is dexcom on 1 minute intervals?

[PhilTU]

Is dexcom on 1 minute intervals?

xDrip was built on 5 minute intervals because that's what Dexcom does.

[Teute0815]

I did the 1 minute testing for some days now, here's my feedback:
Setup:
Libre 3 sensor - juggluco - Libre patched broadcast <> Libre patched source - xDrip - Nightscout

It seems to work quite well.

Things to check:

* Do alarms work correctly?

* Do trend arrows and deltas show correctly?

* Try with and without the `graph smoothing` preference switch enabled.

All those things worked well and as expected. I didn't come across any inconsistencies or problems. And haven't noticed anything strange.

* Does predicted low feature work correctly?

It does, as well as falling/rising fast. But those alerts are really annoying now, as they feel much more frequent within the same sequence now. I guess, it's got to do with new values coming in every minute. Beforehand you obviously couldn't be warned more often than every 5 minutes - now it seems much more frequent (It's a bit hard to really tell, as one can't/don't want to force those alarms for an extended time period). If I'm right, I think there should be a 5 minute interval (at least) on those alarms. Not an alarm with every new value.

* If you broadcast or upload the data from xDrip elsewhere what happens to these receivers?

The 1 minute intervals found their way into my nightscout without problems. They don't, if I broadcast from juggluco with local webserver - those values will be received/polled every 5 minutes only by xDrip (could we change that, please?) They do get backfilled into xDrip by the minute (roughly 15 minutes back max, though) but then don't get send to nightscout.

* Do you get missed readings?

Not out of the ordinary. Other than the odd value missing inbetween. Probably because of the issue described further up by others.

Other findings, questions, wishes.

• I don't know, if that is intended, but the feature only works when engineering mode is actually turned on. It stops working, when you turn the engineering mode of even though, the feature itself is activated. I didn't want to accidentaly mess some other things up, so I thought I'll quickly activate mode and feature and then turn mode off again. I feel a bit uneasy about it, but I guess, the feature won't be hidden in engineering mode forever. Until then, I'll have to leave the mode turned on.
• Backfill missed data: This is unfortunately still not working (nicely/easily) - especially not for Libre 3. I couldn't find any setting that would do it properly. Using source Nighscout Follower works to some extent, but only pulls up to roughly 15 minutes back. Is there a way to extent that timeframe? And is there a way to implement it properly in this feature/Libre patched source? Jaap from juggluco can send the data from juggluco, but he turned it off, because it did "weird things in xDrip".

[PhilTU]

I think this is "unfinished business" hence still an engineering mode function. Thanks for the feedback.

I have observed that xDrip+ with Libre 2 picks up 45 minutes of backfill data via direct / OOP2 connection when the phone is switched on after being off for some hours.