AndroidAPS
AndroidAPS copied to clipboard
nightscout
UAM SMBs with Libre 2
This is a feature/enhancement request regarding the usage of SMBs with the Libre 2 (and potentially 3).
We started objective 9 and it seems that many of the SMB options (Enable SMB Always, Enable SMB After Carbs, and, most importantly for us, Enable UAM) are unavailable to users of the Libre 2 CGM. The listed reason in the docs is a need for data smoothing as the sensors themselves do not smooth output, but we enabled a smoothing algorithm through xDrip and still cannot use these options.
We asked about the SMB options in AAPS in the WANW Discord and were informed that the L1 had a bug that might report a flat high BG during an error event instead of reporting the error, and this was the actual reason that these SMB options were disabled for the Libre 2 and 3. A discussion ensued with various people agreeing that a flat high BG is not an issue, us included- we have only ever seen a flat low BG, and even that only once in the last year.
With both of these problems (BG noise and high BG instead of error events) not being an issue for the Libre 2 and 3, and given that the Libre sensors are approved by various agencies for use in loops, we're requesting that these limitations on SMBs be lifted, potentially with enforcement of smoothing algorithm usage. At the very least, we would like AAPS to have a way for the user to acknowledge the risks and then manually enable the SMB features through the AAPS menus.
I agree. I would add that with BOTH xdrip smoothing and aps smoothing the leveling of the blood sugar data is almost perfect (i use FSL2)
I agree. I would add that with BOTH xdrip smoothing and aps smoothing the leveling of the blood sugar data is almost perfect (i use FSL2)
Every smoothing makes the data "nicer" but add to data inaccuracy and delays. And you doubled it
It can be, but in my experience smooth data is always real respect "real" bg blood (after 15 mins between fsl2 and finger). It depends between person and person? It could be
I agree. I would add that with BOTH xdrip smoothing and aps smoothing the leveling of the blood sugar data is almost perfect (i use FSL2)
Every smoothing makes the data "nicer" but add to data inaccuracy and delays. And you doubled it
Sorry, I don't entirely understand how the AAPS and xDrip smoothing work, but doesn't the Dexcom do smoothing all the time? So if accuracy is a concern preventing this feature for our CGM, the Freestyle 2 should have the leg up for always reporting exactly what it's reading?
At the moment, we've just been setting a temp target all the time to get this to work somewhat like we're wanting. It's not perfect, we'd really love to use autosens to adjust the target on the fly and to not have to remember to reset the target after activity or hypo, but it's been amazing for helping us out when we inevitably forget to indicate carbs for a meal or snack.
I just wanted to follow up on this a month later.
We've continued setting a temp target to get something close to UAMs, and we have been much more lax in putting in carbs (I'd say about 50% of the time we put them in before we start to eat, 30% we put them in within 20 minutes of eating, and the rest we forget for more than 20 minutes or don't remember at all). I ran a CGP report before we started doing this, and ran one just now for the duration we've been doing this, and the numbers are a bit worse now but still surprisingly close to "We're completely on top of T1D every day because we're focusing". We're happy to share the reports if it would provide any useful information on the effectiveness of the Libre Freestyle 2 as a UAM compatible CGM.
In light of the now well-documented good performance of the freestyle Libre 3 I would love to be able to use features like autosens, UAM etc. I had absolutely zero issues with wrong or jumpy data. FL3 seems to now have a similar error correction as the dexcom sensors. Suspicious values are not sent to the phone. In such cases the sensor takes a few minutes time out.
Here are two studies. One comparing dexcom G7 and Freestyle Libre 3.
https://pubmed.ncbi.nlm.nih.gov/38189290/
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC10064376/
Agreed with the comments regarding SMB-always for the Libre above. AAPS is renowned for its openness of operation and fine customisable options by the user.
User acceptance of the risks involved is an obligatory feature of building your own app, yet disabling a particular feature flies in the face of this ethos.
I don't even want to use SMB-always because I quite like the 'relaxed' operation of AAPS overnight when SMBs are off.
But to tell me I can't enable a feature stinks a bit, in my opinion.
Agree with smb always for fsl2. Already using it with a workaround with temp tarheta. Would love to use it normally
The Libre 1 bug that was reported a very long time ago, wasn’t probably even a Libre issue, but caused by the the Bluetooth interface placed on top of it. The issue is long gone with Libre 2.
I'm in the same boat. AAPS denies "SMB always" and "after carbs". Using Libre 3 with Juggluco and xdrip+ my personal libre data seems to be pretty stable so i would vote for a removal of these constraints for current Libre sensors, too.
The constraints even seem to make little sense as you can easily overrule them by setting temp targets... (not tested, only read here and on discord)
I'm in the same boat. AAPS denies "SMB always" and "after carbs". Using Libre 3 with Juggluco and xdrip+ my personal libre data seems to be pretty stable so i would vote for a removal of these constraints for current Libre sensors, too.
The constraints even seem to make little sense as you can easily overrule them by setting temp targets... (not tested, only read here and on discord)
I fully agree with this and have a similar setup.
Could we add a allow arbitrary BG source in an advanced setting menu, similar to the one in the OpenAPS SMB with a warning message on top? This would keep this disabled by default but would allow for those certain their BG source is smooth enough to enable it on their own risk?
The restriction is not there because the BG’s aren’t smooth. It is there because the MiaoMiao (or other brand Bluetooth) interface for the Libre1 was giving out flat BG values when signal was lost. This was ages ago. If it was for un-smooth BG data, the G7 seems to be the worst in that sense. Nevertheless there seems to be a perception (especially under the non Libre community) that the Libre2 and 3 are not valid for looping. Additionally AAPS has a very solid check on flat BG’s for 45 minutes, so a second reason to drop the restriction. @MilosKozak, please remove this restriction! I don’t see what more discussion would be required.
+1. I'm running with all SMB features enabled on Libre 2 and it's been pretty smooth.
Speaking of smooth, does anyone have any experiences with the smoothing algorithms in AAPS and XDrip w.r.t. Libre 2? I'm currently using Exponential Smoothing in AAPS and Smooth Libre data ON in XDrip, plus Show unsmoothed OFF together with Send Display Glucose (use noise smoothing for broadcasted values). Basically I have every smoothing option enabled, which is probably a bad idea. I would like it to be able to react faster to changes, but at the same time I observed that it would aggressively micro-bolus or halt basal based on a single spurious data point when I didn't smooth.
+1!
Strangely enough I always had Libre 2 and I always was able to have SMB's. But now it's off... And yes I"m sure it's not only during temporary target etc.
Uhm I have to admit that I have no clue what you are asking... :')
Op ma 24 jun. 2024 11:51 schreef Milos Kozak @.***>:
What indentifier is used for L2, L3 comming from xdrip?
— Reply to this email directly, view it on GitHub https://github.com/nightscout/AndroidAPS/issues/3181#issuecomment-2186084491, or unsubscribe https://github.com/notifications/unsubscribe-auth/AV7TFZLJR2HIOIPPV7NWKWDZI7TZTAVCNFSM6AAAAABCFISGQSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOBWGA4DINBZGE . You are receiving this because you commented.Message ID: @.***>
During my testing jointly with @koelewij we found these settings in various Libre usage modes.
Libre 3 --> Juggluco --> APS says CGM=UNKNOWN, Libre=true Libre 2 --> Juggluco --> APS says CGM=UNKNOWN, Libre=true Libre 2 --> Juggluco --> xDrip --> APS says CGM=LIBRE_1_OTHER, Libre=true
@Milos Hope that helps. See also my PM from today
I remember having issues enabling SMB on Libre 2 because it was identified as UNKNOWN in AAPS coming from xdrip direct (oop2).
Is there any logcat/grep command you would like the output of?
Hmmm without proper indentification we cannot enable it. Does it exist on sender side? If yes we can adapt AAPS at least for L2,L3
What more do you need compared to my list above? I can easily add it to the DEBUG statement.
What more do you need compared to my list above? I can easily add it to the DEBUG statement.
If I understand it correctly, Milos wants to distinguish Libre 1 from Libre 2 and 3, because the Libre 1 is not valid for SMB’s.
@MilosKozak correct me if I am wrong.
+1. I'm running with all SMB features enabled on Libre 2 and it's been pretty smooth.
Speaking of smooth, does anyone have any experiences with the smoothing algorithms in AAPS and XDrip w.r.t. Libre 2? I'm currently using
Exponential Smoothingin AAPS andSmooth Libre dataON in XDrip, plusShow unsmoothedOFF together withSend Display Glucose (use noise smoothing for broadcasted values). Basically I have every smoothing option enabled, which is probably a bad idea. I would like it to be able to react faster to changes, but at the same time I observed that it would aggressively micro-bolus or halt basal based on a single spurious data point when I didn't smooth.
How did you manage to enable smb with libre 2?
@MilosKozak
When using: Libre 2 => Juggluco =>xDrip => AAPS. I get the following in my Logfile:
D/BGSOURCE: [XdripSourcePlugin$XdripSourceWorker.doWorkAndLog():102]: Received xDrip data: Bundle[{com.eveningoutpost.dexdrip.Extras.NoiseBlockLevel=100000, com.eveningoutpost.dexdrip.Extras.BgSlope=2.6433260972281423E-5, com.eveningoutpost.dexdrip.Extras.VersionInfo=2124041914 645e8b4-2024.04.19, com.eveningoutpost.dexdrip.Extras.Raw=152.0, com.eveningoutpost.dexdrip.Extras.Display.Units=mmol, com.eveningoutpost.dexdrip.Extras.Time=1724672559574, com.eveningoutpost.dexdrip.Extras.CalibrationInfo=1724422706254, com.eveningoutpost.dexdrip.Extras.NsNoiseLevel=null, com.eveningoutpost.dexdrip.Extras.SensorStartedAt=1723702035000, com.eveningoutpost.dexdrip.Extras.Noise=-9999.0, com.eveningoutpost.dexdrip.Extras.SensorBattery=-1, com.eveningoutpost.dexdrip.Extras.BgSlopeName=FortyFiveUp, com.eveningoutpost.dexdrip.Extras.BgEstimate=152.0, com.eveningoutpost.dexdrip.Extras.SourceDesc=Other App, com.eveningoutpost.dexdrip.Extras.SourceInfo=Libre2 Native, com.eveningoutpost.dexdrip.Extras.Collector.NanoStatus=}]
Where this identifies the Libre 2: com.eveningoutpost.dexdrip.Extras.SourceInfo=Libre2 Native
When using Libre 2 => Juggluco => AAPS. I am not able to get this information. and do I get only:
I/XDRIP: [DataSyncSelectorXdripImpl.processChangedGlucoseValues():156]: Loading GlucoseValue data Start: 8710 GV(id=8711, version=0, dateCreated=1724672559692, isValid=true, referenceId=null, ids=IDs(nightscoutSystemId=null, nightscoutId=null, pumpType=null, pumpSerial=null, temporaryId=null, pumpId=null, startId=null, endId=null), timestamp=1724672559574, utcOffset=7200000, raw=152.0, value=152.0, trendArrow=FORTY_FIVE_UP, noise=null, sourceSensor=LIBRE_1_OTHER) forID: 8711
Where the Libre 2 is identified as: sourceSensor=LIBRE_1_OTHER
This last one (without xDrip) is therefore not able to identify the Libre 2.
Can this be used to identify the Libre 2?
I'm so glad to see all the support for this change request <3
We're happy to contribute our log data as well, of course. In our case, we just use Libre 2 -> xDrip -> AAPS
14:25:01.068 [DefaultDispatcher-worker-5] D/BGSOURCE: [XdripSourcePlugin$XdripSourceWorker.doWorkAndLog():102]:
Received xDrip data: Bundle[{com.eveningoutpost.dexdrip.Extras.NoiseBlockLevel=200,
com.eveningoutpost.dexdrip.Extras.BgSlope=3.2913900527609827E-6,
com.eveningoutpost.dexdrip.Extras.VersionInfo=2123071614 23ccbd1-2023.07.16,
com.eveningoutpost.dexdrip.Extras.Raw=0.0, com.eveningoutpost.dexdrip.Extras.Time=1726514700806,
com.eveningoutpost.dexdrip.Extras.CalibrationInfo=-1, com.eveningoutpost.dexdrip.Extras.NsNoiseLevel=null,
com.eveningoutpost.dexdrip.Extras.Noise=-9999.0, com.eveningoutpost.dexdrip.Extras.SensorBattery=0,
com.eveningoutpost.dexdrip.Extras.CalibrationPluginInfo=OOP , com.eveningoutpost.dexdrip.Extras.NoiseWarning=0,
com.eveningoutpost.dexdrip.Extras.BgSlopeName=Flat, com.eveningoutpost.dexdrip.Extras.BgEstimate=169.0,
com.eveningoutpost.dexdrip.Extras.SourceDesc=LimiTTer}]
The SourceDesc at the very end seems to be the identifier in our case, as the D/DATABASE line that follows this entry in the log says sourceSensor=LIBRE_1_LIMITTER
I will try to follow this thread more closely, so please let me know if there is any info or troubleshooting we can do to assist.
Is there anything that I could help with to move this issue forward? @MilosKozak It would be greatly appreciated if we could use L2/L3/L3plus with SMB/UMB.
I am currently running L3 + Omnipod if i can help out with anything to move the issue forward let med know. Waiting for this functionality.
+1 for removing this limitation. I have been using L3 + Omnipod Dash with temp target as a workaround for two months and can confirm that it is working well for me.
+1 for removing this limitation. I have been using L3 + Omnipod Dash with temp target as a workaround for two months and can confirm that it is working well for me.
As I can see in latest dev it is still limited. Can you please confirm from SMB tab with screenshot that is has been removed? Thanks
CezaryKlose if you toggle a temp target with SMBs on temp target it overrides the security measures
tor. 7. nov. 2024, 11:25 skrev CezaryKlose @.***>:
+1 for removing this limitation. I have been using L3 + Omnipod Dash with temp target as a workaround for two months and can confirm that it is working well for me.
As I can see in latest dev it is still limited. Can you please confirm from SMB tab with screenshot that is has been removed? Thanks
— Reply to this email directly, view it on GitHub https://github.com/nightscout/AndroidAPS/issues/3181#issuecomment-2461858387, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADRC53JV3Z6MQR3OR62MTATZ7M5YRAVCNFSM6AAAAABCFISGQSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRRHA2TQMZYG4 . You are receiving this because you are subscribed to this thread.Message ID: @.***>