Question for current xdrip+ users

Status
Not open for further replies.
C

Carlos

Well-Known Member
Relationship to Diabetes
Type 1
Hello there

I'm looking at getting xdrip+ working in my Galaxy A40, following the instructions in here https://xdrip.readthedocs.io/en/latest/install/libre2/#manually-changing-settings

The way I read it is that I need to uninstall LibreLink before I connect the sensor to xdrip. I would like to still be able to run LibreLink so that the data is uploaded to Libreview. Does anyone have any experience of running LibreLink an xdrip in parallel?
 
I don't run librelink at all, I use the handheld device to start the sensor (and to provide the diagnostic codes/readings if I need to ask for a replacement), you should be able to install librelink and just stop it/revoke permissions though to avoid it stealing the connection back from XDrip+, though that won't help with your wanting to upload data to libreview.

XDrip+ can upload to Tidepool (which MyDiabetes uses and my consultant is happy with), but if that's not suitable I'd suggest using JugGluco as the source for XDrip+ (JugGluco can emulate the hacked librelink, so link the sensor to JugGluco, and set the source in XDrip+ "Settings>Hardware Data Source" to "Libre (Patched App)") and iirc JugGluco has a setting to upload to libreview.

Then you get the best of both worlds, 1min readings, uploads (to both sites), plus the prediction graphs and alarms from XDrip+

https://www.juggluco.nl/Juggluco/mmol.html though I've never tried uploads to libreview - looks like it might need to be done manually via CSV export and manual upload, which is not ideal, but depends on how often you need to share the data I guess. Actually re-reading it, it looks like it does the upload automatically, let us know how you get on 🙂
 
Last edited:
SimonP said:
I don't run librelink at all, I use the handheld device to start the sensor (and to provide the diagnostic codes/readings if I need to ask for a replacement), you should be able to install librelink and just stop it/revoke permissions though to avoid it stealing the connection back from XDrip+, though that won't help with your wanting to upload data to libreview.

XDrip+ can upload to Tidepool (which MyDiabetes uses and my consultant is happy with), but if that's not suitable I'd suggest using JugGluco as the source for XDrip+ (JugGluco can emulate the hacked librelink, so link the sensor to JugGluco, and set the source in XDrip+ "Settings>Hardware Data Source" to "Libre (Patched App)") and iirc JugGluco has a setting to upload to libreview.

Then you get the best of both worlds, 1min readings, uploads (to both sites), plus the prediction graphs and alarms from XDrip+
Click to expand...
Thank you @SimonP. More cumbersome than I expected. I need to check with my diabetic nurse to see if they are happy to use an alternative site.

I suppose that the reader is an option so long as I scan at least every eight hours, the main reason I got a mobile with nfc was to avoid having to carry an extra device. Is xdrip OK for alarms?
 
I'd only use the reader to start the sensor, nothing else. It's not too bad running both apps and it does look like that will do what you need it to regarding uploads. I just ignore JugGluco and leave it running in the background and only interact with XDrip+ (unless it decides to not read in which case I scan with JugGluco to see what the problem is).

XDrip+ is good for alarms - it's actually part of the reason I asked for a libre on prescription before they became CGM via the normal app. It will do high and low alarms, with different levels during the day and night, and it will also alarm if it doesn't get a reading within a certain period, all of which are configurable and can be disabled if wanted. The other advantage of the alarms vs the librelink app (afaiu) is that you snooze the alarms on XDrip+ and they will then go off again if you're still high/low, while afaiu in the librelink app once you dismiss it, it's gone.
 
Thanks Simon. I'm thinking that blocking LibreLink from using Bluetooth should effectively turn the phone into an nfc only reader, like the Libre 1 reader was. Unfortunately I can't work out how to remove the Bluetooth permission from the LibreLink app.

Will keep trying.
 
Carlos said:
Unfortunately I can't work out how to remove the Bluetooth permission from the LibreLink app.
Click to expand...
I'm not sure it's necessary. At least with Juggluco it isn't: once Juggluco is using Bluetooth LibreLink can't. (Similarly, I start the sensor with the Reader, then I scan with LibreLink and right then LibreLink says it can't offer alarms. When I scan with Juggluco that becomes the only thing that uses Bluetooth with the sensor.)
 
@Bruce Stephens has more experience of using juggluco than I do so I'd follow his advice, as a general point to
revoke permissions you can do the following: in the main Android settings (i.e. swipe down from the top right to get the phone settings) select something like Apps/Applications (different for each manufacturer). Then select the app in question and within the settings for the app there's typically a field for permissions where you can revoke/add additional ones. You'll want to go to the same place and ensure that XDrip+ and Juggluco are not having battery management/restrictions applied to avoid them being killed during the night. In addition, to avoid them being killed, if you go to the task view (square button) and long click on the thumbnail for the apps you can lock them (little padlock symbol for me) to prevent them from being stopped.

Also, only the active app can access the NFC hardware, so you'd need to bring Libreview to the foreground to let it do an NFC scan - otherwise both XDrip+ and Juggluco can also do NFC scans themselves.
 
SimonP said:
@Bruce Stephens has more experience of using juggluco than I do so I'd follow his advice, as a general point to
revoke permissions you can do the following: in the main Android settings (i.e. swipe down from the top right to get the phone settings) select something like Apps/Applications (different for each manufacturer). Then select the app in question and within the settings for the app there's typically a field for permissions where you can revoke/add additional ones. You'll want to go to the same place and ensure that XDrip+ and Juggluco are not having battery management/restrictions applied to avoid them being killed during the night. In addition, to avoid them being killed, if you go to the task view (square button) and long click on the thumbnail for the apps you can lock them (little padlock symbol for me) to prevent them from being stopped.

Also, only the active app can access the NFC hardware, so you'd need to bring Libreview to the foreground to let it do an NFC scan - otherwise both XDrip+ and Juggluco can also do NFC scans themselves.
Click to expand...
The problem I'm having is that the Bluetooth settings for the app are not active links, they are greyed out
Screenshot_20230905-211101_Permission controller.jpg
All that happens when I click on it is I get an information pop up.

What Bruce says makes sense, so I will try that.
 
Hi @Carlos, interesting, I get a screen that looks different and can tap on any given permission and disable it.

There must be a way to do it, might be worth a search for either the Android version in question or the handset (as the manufacturers can also "skin" the settings app).

Hopefully you won't need it though by following @Bruce Stephens' suggestion.
 
I got it working last night, but with both LibreLink and XDrip unable to use the Bluetooth and having to scan in both. I fiddled a bit again this morning, and now both are reading the sensor through Bluetooth! No idea how that happened.

Regarding the permissions, it is quite strange because according to the Samsung help I should be able to click on those to change the values. I will need to spend some more time on that this evening, though as everything works better than expected, I should probably leave it well alone.

Unfortunately my garmin watch is not supported by the xDrip datafield, so I can't add the glucose readings to my ride data.
 
Glad you've got it working 🙂

Carlos said:
Unfortunately my garmin watch is not supported by the xDrip datafield, so I can't add the glucose readings to my ride data.
Click to expand...

Which watch do you have? You may be able to ping the author and ask for your particular model to be added, though if it's running a different version of ConnectIQ it might not be possible, though I don't think the watchface and datafield need any particularly exciting capabilities.

Amongst my many plans and todo lists, is one to write a watchface and some datafields so that they round correctly (only seen occasionally), don't display calibration offsets as massive delta BG values, and display IoB and CoB.

The ConnectIQ SDK looks fairly straight forward and I found a skeleton MonkeyC app that did most of what was needed.
 
SimonP said:
Glad you've got it working 🙂



Which watch do you have? You may be able to ping the author and ask for your particular model to be added, though if it's running a different version of ConnectIQ it might not be possible, though I don't think the watchface and datafield need any particularly exciting capabilities.

Amongst my many plans and todo lists, is one to write a watchface and some datafields so that they round correctly (only seen occasionally), don't display calibration offsets as massive delta BG values, and display IoB and CoB.

The ConnectIQ SDK looks fairly straight forward and I found a skeleton MonkeyC app that did most of what was needed.
Click to expand...
I have a forerunner 235, a bit old now, I suppose. There's a widget that supports my watch, but neither the datafield or the watch face do.

I never thought to check the sdk. Is it free? I always assumed it would cost money.

So far both xDrip and LibreLink are talking to the sensor via Bluetooth, both issuing alarms and all. It will be interesting to see what happens when I start a new sensor on Friday.
 
Yes, the SDK is free, they want people to develop apps as it encourages people to purchase the watches/etc.

@Bruce Stephens beat me to the link, that looks like the right one. There are some example apps on github. Unfortunately the watchface and datafield in question are not opensource (though they are free).

Going back to your Bluetooth connections, I'm quite surprised that both work at the same time, which isn't what I thought was supposed to happen, unless each re-pairs with the sensor each time it hears a broadcast, I've no idea, but it's interesting to hear that it works like this 🙂
 
I've just had a look and the "datafield" (https://apps.garmin.com/en-US/apps/5a3e2cda-12f0-4afd-88ed-000e67a68d84) and "watchface" I use (https://apps.garmin.com/en-US/apps/8fab3746-f56f-4b41-b3c7-5f4aaeaed6c9), which don't appear to support the Forerunner 235, there is a "widget" which should (https://apps.garmin.com/en-US/apps/73115e04-dc9f-4765-ad88-e7ae283ce995) as well as an "app" (https://apps.garmin.com/en-US/apps/fc892009-996a-4907-b277-0c5bfa6fdab2#0)

I'm not sure whether the lack of support for the datafield and watchface is a limitation of the capabilities of the 235 or an oversight, I'm equally not sure what a widget is vs an app, though I do recall that all these things are explained in the SDK docs so one can work out what one wants to develop.
 
SimonP said:
Yes, the SDK is free, they want people to develop apps as it encourages people to purchase the watches/etc.

@Bruce Stephens beat me to the link, that looks like the right one. There are some example apps on github. Unfortunately the watchface and datafield in question are not opensource (though they are free).

Going back to your Bluetooth connections, I'm quite surprised that both work at the same time, which isn't what I thought was supposed to happen, unless each re-pairs with the sensor each time it hears a broadcast, I've no idea, but it's interesting to hear that it works like this 🙂
Click to expand...
I always thought that the app polled the sensor, but I guess that it makes more sense for the sensor to broadcast, at least for alarms.

I've done a brief google search but didn't find anything. I may contact the developers of xDrip with my experience, as it shows that both apps can talk to se sensor, even though I don't know how I did it.
 
Carlos said:
I always thought that the app polled the sensor, but I guess that it makes more sense for the sensor to broadcast, at least for alarms.
Click to expand...
The sensor sends out a message once a minute. I don't think there's any communication from the app to the sensor except via NFC (specifically there must be some way to reset the Bluetooth connection and presumably to get 8 hours of readings (so the app can fill in gaps)).
 
Bruce Stephens said:
The sensor sends out a message once a minute. I don't think there's any communication from the app to the sensor except via NFC (specifically there must be some way to reset the Bluetooth connection and presumably to get 8 hours of readings (so the app can fill in gaps)).
Click to expand...
Looking at the OOPAlgorithm2 window, I can see that there's a glucose reading every minute, so it is catching every broadcast. I'm not sure how it works internally. Do the apps install a handler with the Bluetooth service to receive the value?
 
The code structure is hard to work out, which the original/main author recognised and said he wanted to get features in rather than make clean code. This does unfortunately make it very difficult to understand, debug and modify, c'est la vie.

I think this is the relevant portion:
xDrip/app/src/main/java/com/eveningoutpost/dexdrip/LibreReceiver.java

I think apps have to register with an centralised Android API BT handler and request a callback, I seem to recall that for the 5min readings this was timed internally so that the callback request was only made when the reading was imminent, to save battery power in the BT chipset I assume. I'm not sure, off hand, how it works for 1min readings.
 
Status
Not open for further replies.
Back
Top