@Kywalh No problem. Just get a new phone and run the start new sensor routine. Make sure you change the transmitter serial code on the old phone. Enter it on the new phone, and start the sensor.
Be sure to get a phone on the list I referenced.
Good luck!
EDIT: make sure you stop the sensor on the old phone.
@docslotnick
I’ll do so… I’m just a be uncertain about the obsolescence of the list of compatible phones…
A lot of the list are old phones with old Android version…
I’ll ask a question on AndroidAPS Facebook page explaining the complete setup I want for my daughter and try to identify the phone that works 100% sure…
Do you have AndroidAPS, xdrip with G6 ?
@Kywalh No. Although I use xDrip+ and a Dexcom G6, I am on MDI. A pump is a whole different set of problems.
Good luck!
@docslotnick
I’m still trying to find the right phone…
Well, something weird…
In order to test the G6 but not loosing any CGM capabilities, I installed xdrip on another phone and paired it with the miaomiao…
… and since that, I also have connectivity issue with the miaomiao…
On my other phone, I looked at the event log and believe what I saw…
Look at the screenshot…
There seems to be some conflict… And I can’t remember if I pressed Forget device in my daughter’s phone when I changed to G6…
I’m thus wondering if I should simply uninstall xdrip and start from scratch on my daughter’s phone…
What is strange is that I don’t see the G6 in the Bluetooth parameters of the other phone (not in the parameters of xdrip I mean) whereas I see de Dexcom device in my daughter’s one…
@Kywalh Yes, it looks like from the log that your phone is also looking for a Dexcom transmitter.
Starting from scratch at this point is probably your best bet.
You don’t need to replace the sensor, just start the one she has in.
Get an appropriate phone and run the data source wizard on a fresh install of the latest xDrip+. It should work.
Just food for thought. When I started my G6, it wouldn’t connect . It started to receive a signal at exactly the same time the Dexcom receiver I decided to try got a reading. XDrip+ has been operating flawlessly since.
So… I’ve been seeing the dropped-reading/end-of-all-life scenario for some time; I’m using G6+xDrip(latest beta)+Blackview BV9500/Android 8.1 (chocolate cookie). I’ve sent a couple of event logs to Jamorham via the “upload logs” feature, the last one with the recommended debug options switched on.
The problem seems to be that, even if you uncheck the option xDrip goes into “aggressive” mode when it drops a single reading, and in aggressive mode it only manages to pick up each potential bluetooth device every second; this is by watching the event log. So if you are in an environment with more than a trivial number of BT devices (an airport lounge, an airplane, a piste) xDrip never finds the G6.
The fix would seem to be to actually disable “aggressive” mode, i.e. make this work:
-> Right swipe/Settings/Less common settings/Aggressive service restarts
I have it unchecked, yet the log still says “Agressively restarting collector service due to lack of reception”; the lack of reception is because it’s scanning and, very slowly, finding every BT device in my home (like [LG] webOS TV.)
Amusingly I now have a log in which it actually manages to find the G6, but so what? It just goes on looking - I just tried to send this to Jamorham but I guess he’s blocked me…
In my experience it takes two missed readings before it does an agressive restart (which I always leave enabled). If I see it is has missed a reading before that, I manually restart collector from the system status page. Doing it after the first missed reading prevents an agressive restart. (I don’t think there is anything wrong with agressive restart, it seems to do the same as a manual restart to me).
With my phone (an old Motorola which is on the “approved list”) I get realtime capture in the high-90’s when I am not at work. At work I range from the 80’s to the 90’s - there is a lot more bluetooth noise at work and some days are worse than others. Occasionally (weeks apart) my phone will fail to get any readings even after multiple collector restarts, and restarting the phone recovers it - so maybe try that if you haven’t. That said, do you really find it “never” finds the G6? What is your realtime capture rate? I think you said somewhere else you keep your sensors running for 20-40 days - maybe you should try a new sensor and see if capture rate improves when the sensors are new. Or maybe you should try a different phone?
xDrip+ is free and public domain. Jamorham is not customer service, so it does not in the least surprise me that he isn’t responding to your one-off bug reports. He is looking for issues that occur to many people and that represent fixable problems.
I forgot to say before that I now have a protocol which seems to work:
On the flight out from SFO to TPE (a 14 hour flight) I wasn’t able to get the G6 to give me readings for more than a couple of readings at a time and I did everything; forced stop of xDrip, turning BT on and off, complete phone restarts (at least three times in that flight.) I also (initially) had the “continuously reset bluetooth” option switched on because for the preceding month or so this seemed to offer a partial fix to the problem. Here’s the log from the two days the flight covered. xDrip is giving me days in PST as I am now in Oregon:
Flight depart 1:35PM Feb 2 (SFO: -8),
Flight arrival 7:50PM Feb 3 (TPE: +8) = 3:50AM Feb3 PST:
Capture Rate Feb 2: 58% 122 of 288 readings lost, realtime 128 readings, so 160 of 288 missed and only 38 back filled.
Capture Rate Feb 3: 91% 25 of 288 readings lost, realtime 209 readings, so 79 of 288 missed and only 54 back filled.
Gross result: 92 back filled, 147 lost for ever.
On the flight back from TPE to SFO (a little over 10 hours) I was using the protocol above, which I had come up with in Taipei, and, while I had to turn bluetooth off several times I got 100% of the data. Here’s the log:
Flight board, 11:35am Feb 16 = 19:35pm Feb 15 PST
Flight arrival, 6:45am Feb 16 (well, before that - it was early)
Capture rate Feb 15: 100%, 78% real time (63 of 288 readings back filled)
Capture rate Feb 16: 100%, 95% real time (13 of 288 readings back filled)
Gross result (48 hours): 76 of 576 back filled
So I think you can see that while the protocol doesn’t stop readings being dropped in a noisy environment it does provide a recovery which allows back filled readings to fill in the dropped readings.
My home is, unlike San Francisco and Taipei, pretty much noise free. There are only three or four bluetooth devices within range and they are all mine - my closest neighbor is 1/4 mile away and only recently got a wireless phone. Nevertheless I’d had problems before with this environment primarily because my smartphone isn’t glued to my butt, so I periodically leave it out of range for more than 5 minutes. With the protocol I’ve been getting 100% capture rate in and out of the house and a real time capture rate that is typically about 95%.
The one problem I still have is overnight. Sometimes I don’t wake up for the alarm! I still have to turn blue tooth off manually but sometimes I just ignore it. Even so since Feb 15 my lowest real-time capture has been 89%; the low numbers correspond to driving to Grants Pass which is 26 miles away, during the drive my phone connects to a BT receiver in the car and that seems to result in dropped readings every now and then. Other days (no driving) have real time capture of 95%.
On flights I now don’t use “airplane” mode, instead I simply turn the SIM cards off (my phone has two). Typically flights these days have on board WiFi and everyone uses bluetooth all the time, so it is actually quicker just to turn the SIM off. xDrip does respect the “airplane” mode; it won’t turn BT on if airplane is set.
In my experience it takes two missed readings before it does an agressive restart (which I always leave enabled).
It goes into “scanning” mode after the first reading but it only issues the aggressive reading after that. Curiously it still emits the aggressive warning even if scanning finds the G6, but I think that is a separate bug since finding the G6 doesn’t seem to help. Yes, it’s the scanning that is the problem but the default log settings don’t show that happening; I just got the aggressive warning which made me very suspicious because I had turned it off!
Occasionally (weeks apart) my phone will fail to get any readings even after multiple collector restarts, and restarting the phone recovers it - so maybe try that if you haven’t.
The scanning continues across the collector restarts and, apparently, across xDrip bluetooth on/off operations. The only way to stop it seems to be turning BT off by hand but maybe the xDrip code to turn BT off is also broken. However:
That said, do you really find it “never” finds the G6?
I think that the scanning does, sometimes, find the G6 and recover but given that it only finds one BT source per second while scanning and given that the G6 is not transmitting continuously it would seem that the chance of it finding the G6 is minimal.
maybe you should try a new sensor and see if capture rate improves when the sensors are new.
I could discern no difference. More important I changed the transmitter and that didn’t help. Indeed the new transmitter seems worse. Previously I didn’t have dropped signals overnight when I slept on my front (where the sensor/transmitter is), now I consistently get a dropped signal if I sleep that way. I think the box spring is effectively a faraday cage and the new sensor doesn’t have enough power to get the signal through my body.
Jamorham is not customer service
Yes, I know, I intend to fork it but it is easier with modern code to debug it as a black box first; until I worked out the above I had thought that maybe it was a bluetooth stack bug since I’ve seen a lot of broken bluetooth stuff on Android, Gentoo and Windows.
