Dexcom connection loops and potential cause for battery drains #494
Comments
|
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). "the problem lies with xDrip4iOS attempting to reconnect to the transmitter without an apparent reason." "_However, as xDrip4iOS then blocks the connection because "last connection was less than x seconds ago": the transmitter doesn't get anything from us.__" "but another part of the code thinks its by error and tries to reconnect" This code is generic for all types of bluetoothtransmitters (Libre 2, MiaoMiao, Dexcom, M5Stack, ..). "'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.)" 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. |
|
"will timeout after 15 seconds, and it will immediately reconnect. That's the behaviour of Dexcom." I think the problem is G6 needs to stay awake for a period of time (15 seconds) after the last disconnect in case a 2nd device needs to connect. Because xDrip4iOS immediately initiates a reconnect this timer constantly gets reset which prevents the nrf52 from entering sleep mode. It seems to have a 2 minute hard limit also, whereby it forcibly enters sleep if it's hasn't been able As a test... if we introduce a 20s delay in the disconnect -> reconnect loop that should give G6 enough time to sleep correctly. I can confirm the Dexcom battery drain issue is a thing. With Anubis we're seeing a very regular 60 day battery problem exclusively with xDrip4iOS. |
with which app do you not see this problem? Do you use the official Dexcom app with Anubis? |
did you test that with xDrip4iOS while running in the background and if so, it does reconnect successfully 4minutes and 4 seconds later? (meaning when Dex has a new reading). If that works that could be the solution |
Indeed, that's why Dexcom is different than other devices like Libre and MM or Bubble, those devices stay connected |
All of them. I do the Anubis transmitters and support 1000's of users (iOS & Android) through that work |
what is all of them? is there another open source ios app that you use for that (other than Loop) |
What I mean is across ALL Anubis users, which include all Official & Open Source apps. Since we warranty Anubis exactly like Dexcom out to 100 days, when a battery dies early we hear about it. In almost every case that happens, it's been activated around 60 days and xDrip4iOS/Shuggah was used. Every other app lasts to 200+ days. |
|
I plan to switch to Dexcom (the real Dexcom) (Libre 3 is awful) in the coming 2 weeks, I'll try out the 20 second delay. |
|
Hi Johan, First of all - thanks for taking the time to look in to this elaborately, much appreciated. :) And congratulations on moving to a proper CGM. (Sorry, couldn't resist. :P) Why not use the Anubis? Has some nice extra convenience features! :) Just to note: I can confirm that the Dexcom battery drain/connection loops only occur with xDrip4iOS. It does not occur on the official Dexcom app (iOS) nor can I get it to that state on Android with xDrip+. It's something specifically with the instant reconnection. But what's the mindf- for me is that it doesn't always happen. (However, looking at my logs: it does happen far more often than I initially thought.) Amanda Vanosdol has mentioned that she(/her clients) has also seen the problem with xDrip4iOS + rebatteried Dexcom G5's - which seems to make sense when I read your explanation that the foundation is the same for all those transmitters. :)
If I understand correctly, it could work like that when using the Background Modes as described in the link you provided: https://developer.apple.com/library/archive/documentation/NetworkingInternetWeb/Conceptual/CoreBluetooth_concepts/CoreBluetoothBackgroundProcessingForIOSApps/PerformingTasksWhileYourAppIsInTheBackground.html. Currently, xDrip4iOS doesn't implement this as far as I can see. I think refactoring it to leverage these modes may also solve the issue where xDrip4iOS won't always restore itself until the user manually opens it up again when the app had become unloaded because of memory constraints. (Whilst that's another story than the battery drain, may be worth mentioning why it might be a bonus: Currently, if the app is unloaded due to memory constraints whilst it seemingly hasn't started asking iOS to connect again: we never connect anymore (as described in the introduction of that article). So this could perhaps solve two problems at once? Now this is anecdotal as N=1, but I'm one of the people that frequently get's hit with this issue as I use the phone camera a lot which slurps resources that my 13 Mini simply doesn't have. But: iAPS, the official Dexcom app and Loop all are restored within +/- 5 minutes; even if the app clearly got killed. The only app that won't always wake back up unless it's manually opened again for me is xDrip4iOS - even in master mode. I think it's related to this, as the only difference I was able to find is all those app employ background refresh modes whereas xDrip4iOS doesn't do that.)
Ah I thought we did by sending 0x09 + CRC16 (disconnectTx) as defined in https://github.com/JohanDegraeve/xdripswift/blob/master/xdrip/BluetoothTransmitter/CGM/Dexcom/Generic/DexcomTransmitterOpCode.swift#L22 However, running a quick search on the codebase: we don't use that. I've asked @joshbohmer about that, but it seems it's not really relevant to the problem at hand.
Yes, what seems to happen is when we attempt to reconnect: we do so instantly after disconnect. But doing that will be in the window @joshbohmer described wherein the Dexcom is still listening for other devices. (Further info: Dexcom has two device slots, only one can connect at the same time. So when "we" disconnect, it stays active for a bit to wait for another device to connect. Instead, we connect again. The slot isn't chosen until after the connection has been established, so the Dexcom can't "stop listening on that slot" either; it's just open for connection.) This goes on for about 2 minutes (see logs, though if you want I have far more extensive logs of these occurrences) I think and then the Dexcom gives up and stops phoning in. Probably the hard-limit guardrail within the Dexcom that Joshua described above.
I think we're causing that behavior as also mentioned by Joshua. We ask iOS to immediately reconnect to the Dexcom. But as the Dexcom can still be listening at that moment: it actually does reconnect. This then triggers xDrip4iOS to be woken up again, if it even got suspended at all, and then we start ignoring the transmitter. The transmitter gives up after 10 seconds, but what happens next is xDrip4iOS will then once again tell iOS to connect to it again. As the Dexcom is still awake, it once more obliges and connects to us and is once more frustrated by not hearing anything from us for 10 seconds. It disconnects again, but we ask....... and so on and on. :P Until finally after 2 minutes or so, the Dexcom is sick of the annoying kids prank calling him and stops listening entirely. As I'm sure Dexcom isn't the only BLE-device listening in this way, I can't escape the notion that - especially after reading that doc you linked - iOS has provisions for exactly that situation and we should somehow even in the background/suspended state be able to tell when iOS should reconnect (not instantly after Dexcom disconnects, but after x time has passed after that.).
No, sorry. I should've been specific. I meant the Background Refresh modes that are employed by Loop, iAPS, Dexcom official, etc. They implement background modes described in the Developers docs you linked and I repeated above. Specifically, the UIBackgroundModes used by those apps are: Which helps with controlling BLE connections in the background (even if suspended) and waking up even after having been killed entirely to free up resources required elsewhere. It's my theory, but as you know I'm not a coder and am just theorizing based on what I see xDrip does and what documentation says (plus some help from @joshbohmer), that this would At least, I hope so. But I'm going farrrrrrr beyond what is my comfort zone in terms of coding (and that zone is very very small :P) and handling BLE-devices, so maybe it's all BS. But I like to think it sounds logical and feasible based on the developer documentation and observing the behavior of xDrip4iOS and other apps communicating with BLE devices. :P Greetings! :) Enjoy the cold weather... :/ It's snowing here. |
|
well I won't reply it all. If I go to my iOS settings (background refresh, in Dutch "ververs op achtergrond") i have about 20 apps where I can enable background refresh, but I've disabled them all, and all apps keep working. Libre 2 and 3 also don't use that setting by the way (you will not find it in the list) There's also a lot of misunderstanding about apps behaviour in the background. Apps don't get 'unloaded' because of memory constraints. Apps that go to the background (because you lock your phone or press the home button or open another app), and that have nothing else to do (like playing music or tracking your location with gps or ongoing communication with a BLE device), they will be pushed by iOS to 'suspend' mode within seconds. Also this issue was about 'battery drain' for the transmitter. Now you talk about xDrip4iOS not being able to wake up unless you bring the app to the foreground? PS please don't reply anymore. As as long as I don't have a Dexcom transmitter and sensor I can't do anything but keep on debating. I have an appointment next week at hospital and should get the Dexcom (I don't know actually if it's G6 or G7 here in Belgium) It's cold indeed :) but it's better than all the rain we had last months |
|
@JohanDegraeve I can organise to send you a couple Anubis & a G6 Sensor Simulator to help development. Sorry, I thought you already had one. "Also, this issue was about 'battery drain' for the transmitter. Now you talk about xDrip4iOS not being able to wake up unless you bring the app to the foreground?" What's happening is Dexcom transmitters can't enter sleep mode fast enough because of the disconnect -> reconnect loop. The transmitter stays awake for x seconds after the last disconnect to give other devices an opportunity to download data. With how xDrip4iOS handles the BLE connection, the transmitter is kept awake each 5 minute cycle for up to 2 minutes (it's hard cut off) instead of the normal ~15 seconds. This longer than normal time with the nRF52 radio active is killing batteries early The background handling conversation is an attempted to remove the reconnect loop requirement and let the transmitter sleep the radio sooner |
|
I thought you had an Anubis + sensor simulator? If you don't, we should get them to you as they make playing around with it farrrrrr easier and ensure no sensors are wasted. (The simulator can also be used with Dexcom ONE transmitters.) Last input then: according to both Apple and Dexcom, background refresh is critical (and the behaviour of apps with it implemented or enabled rather than disabled is, on my end, definitely far more reliable). (And with "unloaded" I was referring to this statement by Apple: "At some point, the system may need to terminate your app to free up memory for the current foreground app—causing any active or pending connections to be lost, for instance." and then goes on to state how this is solved with background modes). If you don't want to implement it: ok, it's your call. :) I think it'd be a waste not to leverage these features, but if all problems can be sorted without it: all good, that's what matters in the end. :D Thanks in advance for fixing it! :) P.S. the primary concern is indeed the rapid battery drain on Dexcom transmitters - that's a critical problem. The manual intervention after termination was solely mentioned as a bonus issue that might be solved. |
Yes that's probably all correct. I've seen in the Loop code (but can't find it back anymore) that they wait 2 seconds before attempting to reconnect, the comment added is very interesting https://github.com/LoopKit/G7SensorKit/blob/main/G7SensorKit/G7CGMManager/G7BluetoothManager.swift#L218 I had already seen this before but didn't want to implement it because I think it's very risky as iOS in the beginning it takes more seconds before it suspends the app (in the beginning I mean right after it's launched), but after a while the suspension goes faster and faster. The follower mode for xDrip4iOS works with the sound every 5 seconds and sometimes that's even too short. I was aware about all the communication ongoing with Dexcom, and indeed with G5 it was much shorter (I think 15 seconds as you say), and G6 or G7 it's much longer. I wans't sure actually if it would drain the battery or not. |
sure also Apple says background processing is critical? "At some point, the system may need to terminate your app to free up memory for the current foreground app—causing any active or pending connections to be lost, for instance." and then goes on to state how this is solved with background modes). There's another interesting feature that makes sure the app gets relaunched when necessary, it's this https://developer.apple.com/documentation/corebluetooth/cbcentralmanagerdelegate/1518819-centralmanager "definitely far more reliable" "I think it'd be a waste not to leverage these features" "I thought you had an Anubis ", sorry I may have one but can't find it back. Actually I don't believe that all that communication has a significant impact on the battery. I think some transmitters just don't last long enough (especially Anubis?) and then developers start looking at the xDrip4iOS logs and see all that communication ongoing so you think this is the cause. It happened before with Spike also (Spike used the same mechanisms as xDrip4iOS just not the restorestate - I know background refresh was enabled in Spike but that doesn't make any difference) |
Just continue reading the link you gave. :) It opens with the terminator quote and then goes on to explain the options to prevent it from happening. Probably the parts from "Core Bluetooth Background Execution Modes" and "The bluetooth-central Background Execution Mode" bits are most relevant and explains why it prevents the quoted scenario from occurring. This should allow for better connection management even if the app gets suspended or even terminated. (By iOS anyway. User invoked termination is probably different.)
If a handful of users randomly start flipping switches of features they shouldn’t be disabling (without checking), that’s their fault tbh. It can be noted in the docs. And it’s not like we don't have to ask them about other bad choices all day anyway; such as enabling Bluetooth on LibreLink which is located in the exact same settings as where Background Refresh would be. ;)
No it’s not like that at all and I’m sad to hear that you think I’d say something like this if I hadn’t properly looked in to it and hadn’t tried eliminating other potential culprits. Heck, I even tried pinning it down to older/cheaper iPhone's but then got logs sent to me from people on the 15 Pro. Background to this problem: It’s been several months of observing this behaviour between various groups of people, including the Anubis team and the Designs & Replacement team (whom are the first groups of people to detect large amounts of complaints), to establish the culprit. Subsequently, we (me and @joshbohmer) started looking in to what could be causing this problem so that a substantiated problem report could be submitted. The connection loops are a very fine candidate, because the dexcom is supposed to be awake for +/- 10-20 seconds and then go to sleep; but instead it is kept awake and keeps broadcasting for nearly 2 minutes because of xDrip4iOS. Sometimes for days on end. Adding background refresh leveraging Apple's described framework was just a suggestion for a potential route to solve the problem btw, no idea if there are more roads that'll lead to Rome or if it's the road at all; I'm just going by what the docs say. :) If you have another idea of what could cause the problem: ok, this was simply the best theory we could come up with. It makes sense and it’s months of looking in to it - not just some random users’ j’accuse. ;) Maybe it isn’t xDrip4iOS, maybe it is but it’s another problem than what we found. But it cannot be denied that it’s extremely suspicious that every time these issues occur: they’re fixed when people switch away from xDrip4iOS. And lest not forget… There were ONE users complaining about this phenomenon as well, but we dismissed it because one or two experienced it with ONE and naturally complaints ceased completely when they were all forced to let the Dexcom app take the lead as xDrip4iOS doesn’t support the new auth mechanism. Yet.
In an ideal world, absolutely. But just like 100% secure, 100% reliable is an utopia for any app. However, let me put it this way: xDrip4iOS became so unreliable for me as a source for loop data, and the battery drain so high, that I was forced to abandon it and switch to the official G6 app - which has been 99.9% reliable and all battery drainage stopped. And I really really hate the official app and I really like xDrip4iOS - so it’s absolutely not a decision I took lightly, believe me. But, let's focus on the battery drain - stability is another (potentially bonus) matter. Anyway, since I can’t possibly add any more information or arguments to this - I’ll leave it at this and hope the problem will be addressed. :) Thanks either way for your consideration. :) |
|
"Actually I don't believe that all that communication has a significant impact on the battery" One note in relation to this. The problem isn't the increased communication exactly... It's that the nRF52 can't enter low power mode while this extra comms are taking place and those extra CPU cycles (~120s vs ~15s) are what drains the battery prematurely. During the development of Anubis I triggered a similar issue where the battery was draining faster than expected. It took me weeks of research and a power profiler to workout the cause of that battery drain problem. That fix was to resolve the low power mode also. I'm not taking a guess at the problem here... I have explicit experience fixing this in Dexcom hardware. |
|
Intereseting : I google for "At some point, the system may need to terminate your app to free up memory for the current foreground app—causing any active or pending connections to be lost, for instance" the first google result brings me to an issue in stackoverflow https://stackoverflow.com/questions/32563512/push-notification-app-running-in-background-when-ble-is-connected the last answer is intereseting |
I wonder if there's an explicit command to put the Dex in a sleep mode. |
Liroy , the way it's implemented in xDrip4iOS is exactly as it's described in that Apple documentation. |
A sleep command would prevent other devices from retrieving data. As such there is no sleep command, only 0x09 disconnect I'm not sure about the 2 second thread delay but it's worth a try. |
Huh? How's that possible without adding the background modes about which that Apple doc says they're mandatory for proper functioning and processing whilst suspended? oO (Honestly a genuine question and curiosity, not trying to be a pain :)) (From "Core Bluetooth Background Execution Modes" quote: "If your app needs to run in background to perform certain Bluetooth-related tasks, it must declare that it supports a Core Bluetooth background execution mode in its Information property list (Info.plist) file. When your app declares this, the system wakes it up from a suspended state to allow it to handle Bluetooth-related events. This support is important for apps that interact with Bluetooth low energy devices that deliver data at regular intervals, such as a heart rate monitor.") I'll be happy to declare those and then give it a try if the rest of the requires foundation is already implemented if that helps? :) (Note: that'd just be to see about stability/re-launch after termination, I assume this won't fix connection loops.) |
|
"If your app needs to run in background to perform certain Bluetooth-related tasks, it must declare that it supports a Core Bluetooth background execution mode" In the issue you started with "I'll shamelessly plug my request for full implementation of Background Processing/Activity" Please stop this discussion. |
|
Yes let's focus on fixing the reconnection loops as that's currently a more prudent problem and the primary subject for this issue. I'll try working on fixing the relaunch/stability issues on my own. |
Just want to comment there to chime in and second this comment by @joshbohmer and @LiroyvH Had 2 Anubis as well as a stock G6 TX die prematurely while using xDrip4iOS. I was one of the people providing logs to Liroy from an old iPhone as well as an iPhone 15 Pro. My last TX that died early after not even 60 days (57 days IIRC) was an Anubis, so I turned to the Anubis FB group and learned battery drainage and prematurely drained batteries are a known issue associated with xDiOS. When using the stock G6 app with either Anubis or stock G6 TX this does not happen. |
|
@dnzxy can you build the app in xcode? I could make a change and then you could test to see if it improves. Needs to be tested for longer period. |
|
@JohanDegraeve I can build with Xcode or via fastlane, patch-based, branch-based, however you’d like. I will be out of country next week until the week after and will be switching to a fresh Anubis (re-battery’d) this week, so I could read battery voltage before and then after or during. How long does this test need to run for? Would you like to connect on Discord or somewhere else? |
|
Here's the branch to test https://github.com/JohanDegraeve/xdripswift/commits/issue494/ First thing would be to see if that solves the connect loops. It would also be useful to start with a shorter value for delayInSeconds, if you set this to 1.0 295b64b#diff-92e251c9866fabfbf175d735eb29d37cf187f760453fc7765a7948d38f0ce689R292 If it does solve the loops : install it and use it for a longer period (days, weeks, months). I expect that UI will not respond every 5 minutes for about 1-2 seconds. If that's experienced as an issue we could find another way to introduce this delay. If 1 seconds doesn't solve it try with 2 seconds. Longer waiting period is probably not a good idea because there's a change that iOS will crash the app. And then off course to see if that solves the battery drain issue. Only people who experienced the drain will be able to test that. |
|
|
I briefely tested setting |
|
this looks very good actually. The 2 seconds give the Dex time to go to sleep. |
|
Looks like |
|
interesting |
This was a very short test with 1 second, so someone might want to test this again to confirm if 1 second is too little. I am now starting to use the patch with 2 seconds for longer term testing on our looping phones. |
|
That was a short test, someone else might want to confirm if 1 sec is too little. We are starting to use 2 seconds for longer term testing now. For other testers, the logs can be sent to oneself by email from the “Send Issue Report” feature. To see relevant logs in Xcode, toggle on OSLog first. Timestamps can be displayed by a setting in the bottom of the debug window.
|
|
Nice job on this one 👏 |
|
I can confirm that the patch kills updating of BG values running in follower mode from Nightscout with the "Background Keep-alive" mode set to "Disabled". No BG updates happen until set to “Normal”, even with the screen on, while "Normal" mode does work. |
the goal is to test in master mode, why did you test in follower mode? |
|
I am doing the main testing in master mode on phones connected to Dexcom transmitters. The follower mode testing was just incidental when building to my phone that has only been used in follower mode. So just an FYI that there is a minor regression here for this specific case. Master mode works as expected. |
|
ok clear |
Yes, as Johan says, this regression was already fixed several weeks ago in the staging branch. The aim will be to finish everything and hopefully merge into develop (and release) latest tomorrow I guess. |
|
Thanks, @paulplant that’s great, I thought the regression was introduced here, I had not previously tested recent dev. |
|
@bjornoleh , @LiroyvH , @dnzxy probably still waaaaay too early to confirm anything, but please feedback here when you know anything so we can keep this issue open or close it. Cheers. |
|
Looking at what I see in-app (connection state and last connected mismatching last reading from time to time) and what the logs tell me: it's unfortunately still very frequently going in to connection loops with 5.1.4. |
@LiroyvH , please try to reboot your phone if you didn’t already try that. I saw some issues where reconnects happened very frequently after building various other builds. A reboot fixed this, it seems. |
|
@bjornoleh Yep makes no difference. It’ll simply start doing it again at some point. Besides, the issue has been present for a very long time, phone's been rebooted for various reasons copious amounts of time in the meantime :P Thing is, it shouldn't happen at all; also not after a fresh build. Connect, exchange data, disconnect - sleep until 5 minutes later; that's the flow. But xDrip for some reason often, but not always (especially not when the app is foregrounded (which is odd and one of the reasons why I’m still looking in to the BLE management aspect as other apps do not have these issues)),ends up in a connection loop. This btw doesn’t only drain the transmitter battery, but also causes red loops (failure to wake up or go in a connection loop then (I wonder sometimes if when the app is relaunching/waking up that it fails to work properly on the first connection for some reason and then goes in to a loop because the next attempt we tell ourselves to ignore it)); which has been forcing me to use the official Dexcom app due to reliability issues for months on end now, which really sucks. :( |
|
Ok, yes I am seeing the same now, very frequent reconnects (and reboot made no difference in this case...), I suppose this is what @LiroyvH calls a "connection loop"? It's strange, because sometimes it works well, with only reconnects every five minutes. @JohanDegraeve: Should we try with a longer Edit: adding some more context in the logs, although probably not too useful: |
it's worth trying, but there's a risk that withiin that longer period (like 3 seconds) the app gets suspended and if that happens the app will not reconnect anymore, unless you bring it back to the foreground. Don't try it while you sleep :) |
|
@JohanDegraeve @paulplant Was looking in to this again and noticed something I'm not sure of will make a difference. DisconnectTx (0x09) is defined in the Dexcom opcodes, but as far as I can tell isn't actually called anywhere in the flow - can't find a mention of it anywhere other than the DexcomOpCodes file. xDrip+ does seem to call it at the end of every connection. (https://github.com/NightscoutFoundation/xDrip/blob/master/app/src/main/java/com/eveningoutpost/dexdrip/services/G5CollectionService.java#L989-L998) I'm not sure if it will make any difference, but on the other hand one could suppose the command isn't there for nothing and above all else: likely can’t hurt. Could we do the same and send the disconnect command to the transmitter at the end of the Dexcom flow (but before any iOS disconnect)? Just to be sure. |
Possibly. Go ahead and give it a try. _ = writeDataToPeripheral(data: Data(for: .disconnectTx), characteristicToWriteTo: writeControlCharacteristic, type: .withResponse) |
|
@JohanDegraeve Thanks! Like so? LiroyvH/xdripswift@master...LiroyvH-DisconnectTx -edit- Adding that in as linked above makes the build fail with a couple of errors on the modified file:
|
|
ok, this should avoid the error if let writeControlCharacteristic = writeControlCharacteristic { |
|
@JohanDegraeve Yep, that made it built OK! Built and fingers crossed. :) |
|
@JohanDegraeve Too bad, no difference. :( Very first thing it did was go in to a loop heh! Figured I'd watch it a bit longer, but after 2 no problem readings it fell in to another loop until foregrounded. (Though that's not the universal solution either.) Oh well, it would've been really nice if it was this simple. :D |
|
|
Just wondering if any progress has been made on this bug? |
|
@swright87 No progress as far as I'm aware. |
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.
The text was updated successfully, but these errors were encountered: