I forgot to say before that I now have a protocol which seems to work:
- Uncheck every “recovery” option, including all the ones I’ve seen suggested here or on tudiabetes.
- Check the “turn bluetooth on” option; I don’t think this is necessary, but it does mean step (5) isn’t required.
- Set an alarm to fire if a reading has not been obtained for seven minutes. I originally used six minutes but I got spurious “missed signal” alarms; a reading should come in every five minutes, but it looks like the alarm feature can fire at 6 minutes even though the next reading does get read.
- When the alarm fires turn bluetooth off on the phone.
- If the xDrip “turn bluetooth on” option is not set (2), or if in “airplane” mode, turn bluetooth back on; a delay might be required for xDrip to notice that it is off, I haven’t tested this extensively.
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.