Juggluco to Xdrip configuration

I use the following:

Juggluco > Settings > Exchange Data > Patched Libre (which is crossed out)
XDrip+ > Settings > Hardware Data Source > Libre (patched App)

There is talk from the developer of Juggluco of removing the "Patched Libre" Intent broadcast (which is why it's crossed out in the UI), I've opened a Discussion Ticket on GitHub to ask why this is planned, hopefully it won't happen as the suggested alternative is not very useful for me (and at least one other commenter): https://github.com/j-kaltes/Juggluco/discussions/314

I don't use LibreLink at all so can't advise you on how to set this up, but my understanding is that it works. There might be something useful in the discussion posts on github (see link above), otherwise there seems to be a reasonable amount of documentation: https://www.juggluco.nl/Jugglucohelp/libreview.html

Let us know how you get on

Sizewell said:

Should I have OOP2 still running?
I made those changes and Juggluco is working but Xdrip is not although I can scan with xdrip.

Click to expand...

You don't need OOP2 running as the encryption is removed by Juggluco.

Can you check what the settings are on both Juggluco and XDrip+ as per my post above?

Sizewell said:

Xdrip is working fine. It was the logs which was throwing me.

Click to expand...

Great

Sizewell said:

I have now uninstalled OOP2. One other question, when starting a new sensor is it the same as before ie scanning with a reader to start sensor?

Click to expand...

Apparently one can start a sensor with Juggluco, however I always use a Reader so I can post log data to Abbott in case of a failure. As a last resort (while abroad without a reader) I've started with the Librelink app for similar reasons, though I far prefer the reader as it won't phone home without me transcribing information.

Sizewell said:

Thanks a lot guys for your help

Click to expand...

You're welcome

When Juggluco sees a new sensor it automatically resets the calibrations, etc., in XDrip+ (or probably XDrip+ hears that there's a new sensor s/n and resets itself).

I don't know how to start a sensor with Juggluco as I've never tried (though I imagine it will happen automatically if one scans an un-started sensor with Juggluco), but your sensor has already been started, so I don't think this step is needed (or did I misunderstand what you wanted to know?)

I don't really think it anything to do with the setup (i.e. Juggluco + XDrip+ vs Librelink), though I've not checked back-to-back setups (not that this is really viable anyway) but rather than the sensors are now not as good as they once were. I think the rot set in before the 2+ came out though. Certainly the early 2 sensors seemed to work quite reliably.

I went through a long period perhaps 2 ago (iirc) where they simply worked (in terms of comms, they never worked very well and nor do they still in terms of calibration, but XDrip+ helps there to make them usable). They worked reliably for such a long time that I stashed away my MiaoMiao2 thinking I'd not need it ever again but that I ought to put it somewhere safe "just in case". Unfortunately I have wanted quite often since then and I've no idea where my super-safe storage location is!

I also get drop-outs, sometimes only a few minutes, though more likely to be an hour or more (sometimes 8h+) before it comes back to life - with the 8h+ ones I'd usually have got on and changed the sensor thinking it was completely dead had some of these not happen while I was at work or asleep. They are definitely a case of the sensor not producing data as I can scan for BLE devices and see that there are no broadcasts in these cases.

I think the sensors work marginally better (as in fewer drop-outs) if I don't scan them (when they drop-out), so I wonder if there's some link to my mobile phone (chipset/power/etc) though I only scan the sensor once to pair it with Juggluco these days. But this may simply be an effect of different batches of sensors, it certainly doesn't stop the failures and any imagines effect is very marginal, so perhaps just a figment of my wishful imagination wanting to resolve the annoying habit of them not working.

The only other possibility, and I've not got around to investigating this, is that the sensors don't like something that Juggluco does. My assumption was that the sensors broadcast and the listener app is completely passive, I may be wrong. With that said there are no endless complaints about failures on the github page, so I'm still at a bit of a loss as to the true source of the failure mechanism.

I should probably try another phone, but I don't need to change now and the faff of carrying around two phones for an extended period of time (i.e. long enough to have some confidence in any change in behaviour) doesn't appeal much (until I'm part way through a batch of failures that is!)

You don't need to terminate the previous one, you can run both in parallel, I've done this in the past with a failed sensor that has come back to life/one about to reach end of life. In this case it happily reads both sensors, and as long as the first one continues producing data will send that to XDrip+. At some point/under some condition it will swap to the second sensor - this certainly happens once the first sensor reaches end of life and/or if it's offline for some extended period, but I've not really paid much attention from this point.

I've not really kept track of the life spans, it's all in my XDrip+ SQL data, which I will eventually have a proper look at, but certainly the libre1 and early libre2 devices used to last for ~12h extra, though I seem to recall it was a bit hit and miss quite how much longer they would last. iirc the later libre2 devices would always last exactly 12h longer, but I think the libre2+ devices only last as long as it they are supposed to (I've not had very many make it that far so hard to tell). I may be mis-remembering mind you, the data will tell, once I ask it!

Re Bluetooth noise, they seem to be more robust to noise these days (e.g. when riding my bike with lots of ANT+ devices broadcasting in the same frequency band), though this may be a combination of using the built-in broadcast of the libre2 and later devices (as opposed to a Miaomiao2) and updates to phone firmware.

> but I think the libre2+ devices only last as long as it they are supposed to

My libre2+ devices go on past the official end time and Juggluco reports the 'expected end' as 12 hours later than the official end time ( although I have never got one that lasted the extra 12 hours)