JohanDegraeve
commented
11 months ago this is reported already long time ago, with Dexcom G5 and Spike. xDrip4iOS works in the same way as Spike, except that it doesn't use the sound system to avoid that the app gets suspended
When this was reported for Spike, I did some tests where I would not explicitly disconnect, but let the Dexcom time out the connection, to see if that changed anything in the 'battery drain' (which I never experienced by the way, but I never used the Dexcom official app so I couldn't really compare). you could try to comment out this line https://github.com/JohanDegraeve/xdripswift/blob/master/xdrip/BluetoothTransmitter/CGM/Dexcom/G5/CGMG5Transmitter.swift#L1676 and 'see' if that helps. I tried that with Spike but couldn't notice any difference and I remember this was tested by other people also.
"the problem lies with xDrip4iOS attempting to reconnect to the transmitter without an apparent reason." => xDrip4iOS must try to reconnect after a disconnect, no matter the cause of the disconnect. Otherwise it would never be able to reconnect. You could set a timer eg of 4 minutes after which you try to reconnect. But as you probably now timers don't work for apps in the background except if you play some kind of a sound every 5 seconds which keep the app alive (I think you know what I mean).
"_However, as xDrip4iOS then blocks the connection because "last connection was less than x seconds ago": the transmitter doesn't get anything from us.__" That's not correct. In this case (ie reconnect less than 2.1 minutes after the last reading), the xDrip4iOS connects and doesn't disconnect. It let's the Dexcom do the timeout. You can see this here : https://github.com/JohanDegraeve/xdripswift/blob/master/xdrip/BluetoothTransmitter/CGM/Dexcom/G5/CGMG5Transmitter.swift#L691 You see this also in the logs at 2023-11-30 11:52:23.3290 Dexcom itself is disconnecting at 2023-11-30 11:52:38. That's 15 seconds later. It's the Dexcom that takes the initiative to disconnect. xDrip4iOS must try to reconnect.. this goes on for a while. With Dexcom G5 this was only for about 10 seconds if I remember well. For the newer Dexcom's it goes on longer. Do I understand correctly that this goes on for ever? in that case not only the battery of the Dexcom is draining but also xDrip4iOS battery. What is the battery decrease of your iPhone if you sleep with it uncharged? (I mean no other usage). It should only be about 20 to 30% even if you're running xDrip4iOS, Loop and maybe even the official Dexcom app in parallel and if you sleep a normal night say 8 hours.
"but another part of the code thinks its by error and tries to reconnect" that's not an error, it's by design. It's indeed another piece of code : https://github.com/JohanDegraeve/xdripswift/blob/master/xdrip/BluetoothTransmitter/Generic/BluetoothTransmitter.swift#L439
This code is generic for all types of bluetoothtransmitters (Libre 2, MiaoMiao, Dexcom, M5Stack, ..). It may look strange that xDrip4iOS explicitly disconnects, knowing that the other part of the code will immediately try to reconnect, and that's probably not necessary. But even if you remove that disconnect, Dexcom will timeout after 15 seconds, and it will immediately reconnect. That's the behaviour of Dexcom.
"'ll shamelessly plug my request for full implementation of Background Processing/Activity here which could potentially be good for overall stability (also compared to Loop, iAPS and the official Dexcom-app.)" I think you want to say that xDrip4iOS needs a way to avoid that it get's suspended by iOS (here an explanation of suspended state : https://developer.apple.com/documentation/watchkit/life_cycles/handling_common_state_transitions) The only way to achieve this is the sound system (ie playing a non -hearable sound of a few milliseconds every 2 to 5 seconds) No way that Loop and official Dexcom app are using such mechanism. (I don't know about iAPS, iAPS was originally freeaps, freeaps has the word 'free' which I interpret as 'I do what I want', however I actually don't believe iAPS is doing it differently than all the other apps)
anyway that all doesn't solve the battery drain problem if xDrip4iOS is used with Dexcom, if it exists. I actually also think that it's not correctly developed, the disconnect/reconnect loops should be avoided. I tried to understand how Loop does it but it's quite difficult code to reverse engineer.
joshbohmer
LiroyvH
dnzxy
bjornoleh
paulplant
Logging it on GitHub as well so it's tracked and more people could weigh in if they like: several reports have been submitted, notably from the Anubis community - but also from ONE and G6 users, that their transmitters' batteries are drained way faster than expected when using xDrip4iOS. Official transmitters seem to die in about 45-60 days and Anubii with a larger batteries in 90-110 days or earlier. (Note: Anubis with a proper battery typically easily last double that.)
I've spent quite some time looking in to possible causes (including some time spent with Joshua from the Anubis project, whom I'd like to thank for his insights on the Dexcom firmware), and it keeps coming back to a problem I've mentioned on several occasions over the years where the transmitter goes in to a connection loop with xDrip4iOS. (Eg: you see it connect, disconnect, reconnect, disconnect, reconnect, disconnect and so on and on.)
From what I can see, but do correct me if I'm wrong and/or if the log output is deceiving, the problem lies with xDrip4iOS attempting to reconnect to the transmitter without an apparent reason. When xDrip4iOS initiates a disconnect, it also immediately attempts to reconnect. The Dexcom transmitter will still be awake* and responds to our request to connect. However, as xDrip4iOS then blocks the connection because "last connection was less than x seconds ago": the transmitter doesn't get anything from us. The connection times out after 10 seconds, after which the Dexcom disconnects again. However, as soon as that happens: xDrip4iOS once again tries to connect to the transmitter as indicated in the logs ("Trying to reconnect..."). Once again, the Dexcom transmitter allows this connection but subsequently again xDrip4iOS will not actually send anything to the transmitter because the last connection was less than x ago. After a while of this going on and on, the Dexcom transmitter will give up and phones in again at the original timestamp +5 minutes to send its new readings.
The problem is that this cannot always be reproduced. It's unclear to me why xDrip4iOS sometimes tries to reconnect and sometimes doesn't. It might also be the order of the slots in which it's connecting that might make a difference, but either way: xDrip isn't supposed to try to reconnect, especially not when xDrip itself sent the command to disconnect in the first place. I noticed today that during warm-up a similar issue occurs, but that has different log-output that I haven't analyzed yet. Did also send it to Paul.
I think the underlying issue must still lie within the original FireFly implementation where this behavior was noted, but I think was essentially "dirty patched". (Ignoring the transmitter, which inadvertently keeps it awake for 10 seconds until it times out. And then we ask it to connect again. It's like prank calling someone and every time they pick up you don't say anything.)
Here's an excerpt from the logfiles what that looks like:
And a longer look of such a cycle (including when it phones in again to update the values and then it goes straight back in to a loop):
It looks as if we don't yet expect a disconnect or that we do ask for it to disconnect, but another part of the code thinks its by error and tries to reconnect - but is then frustrated by the 2.1 minute thing. Note: in one of the very first implementations, of which I still have the source code laying around here if anyone's interested :P, this problem is continuous.
Anyway, I don't know IF this is the cause of the reported battery drains. But it seems very likely, as such: logging it as issue here. As an extra note: this seems to occur sooner for me when xDrip4iOS is woken up from slumber. (Eg: it got suspended, but transmitter wakes it up. I'll shamelessly plug my request for full implementation of Background Processing/Activity here which could potentially be good for overall stability (also compared to Loop, iAPS and the official Dexcom-app.))
* = The transmitter is still awake, because the Dexcom keeps listening for a brief moment on all 2 (or 3 in case of Anubis) connection slots to see if the second device (reader/pump) wants a connection as well or not. Instead, xDrip4iOS asks to be connected again - and it honors that request.