In the past xDrip+ would always keep on going after 10 days, for up to 30 days until the sensor actually died, now it seems like Dexcom has made the sensor die after 10 days so that xDrip says “sensor stopped”. I tried to re-start the sensor from scratch and it failed with the last sensor – am trying again right now with the next one. Has anyone else been having this experience? Is there a way to get around this so that xDrip+ keeps on going like it used to?
The sensor isn’t the issue, the transmitter software is. I am not sure, but it might helps someone troubleshoot if you can post the transmitter firmware number.
Ah, interesting. I only have the transmitter code, 8GJGRH, threw away the box. Is there a way to find the firmware version using xDrip?
Would it work if I re-started/re-entered the transmitter code when re-starting the sensor in Drip?
It is on xDrip status page, and on G6 receiver.
Mine is 1.6.5.25, and can restart. (Trans 81xx)
Some have reported 1.6.5.27 as being harder to restart.
8Gxx transmitters have been reported as harder to restart sensors.
That I am unsure of. At this point, it might be worth trying to restart. I am not an Xdrip+ user, but have followed the threads that have talk about it in the event my son wants to start using it. Any other ideas @docslotnick?
Thanks for the help Chris. Mine is 2.18.2.88.
If anyone has an idea on how to get it going again I would greatly appreciate help. I’ll wait for a few hours before I re-start with a new sensor in case someone knows what I can try.
Check this post.
2 Likes
8Gxxxxx sensors have a hard switch off routine built in. Get around it by snapping out the transmitter (use of two guitar picks seems to work) from the sensor, leave them disconnected for about a half hour, then snap the transmitter back in and start your session.
PIA to be sure. JamOrHam is working on it, but the 8Hxxx transmitters seem to be able to be normally reset, so Dexcom may have relented.
3 Likes
Or two test strips.
2 Likes
Were you using same transmitter for all these ?
We know there are changes in transmitter, but could also be something dexcom is changing in the sensors.
No, I would use the transmitter for as long as it would last, which would span a few sensors.
I tried removing the transmitter, waiting 30 min, then putting it back in and re-starting the sensor, which worked perfectly. Thank you both for the advice/link.
1 Like
I received one 8G transmitter, which I haven’t used yet but will at the next sensor because my 81 transmitter is at 97 days and is flaking out (i.e. dropping bluetooth regularly). I just received my next transmitter, which is an 8H.
The logical interpretation is that 8G transmitters have a serious bug and this is fixed in 8H, otherwise the early rev doesn’t make any sense.
1 Like
Agreed
1 Like
I had no problems starting my new 8G transmitter however one bug showed up immediately, though I think it has to be a bug in xDrip+.
With the 81 transmitter I would get dropouts and have to turn off bluetooth before xDrip+ would re-sync to the transmitter. xDrip+ then requests what jamorham calls “backsies” from the transmitter; readings from the transmitter’s 3 hour rotating buffer of past blood glucose measures. These “backsies” appear on the display with a faint halo around the yellow dot.
With the 8G transmitter the same thing happens however all the readings, even the ones from the regular successful 5 minute communication, appear with the halo.
I’ve examined the event log and those readings are apparently read fine; I see log messages similar to the following (I’ve reversed the order from the event log, which lists latest first, so the following is in the order the messages were posted):
17:12 Status: Got G6 glucose 17:12
17:12 Checking 3 for backfill requirement
17:12 Got usable glucose data from G5!![sic]
There was no backsie request in the 17:12 communication, nevertheless the 17:10 blood glucose reading, along with all the others, has the backsie halo. I think this can only be an xDrip+ bug.
There are also some protocol changes:
17:22 Received indication bytes: [* * *]
17:22 Got unknown packet rx: D0002715
17:22 Received indication bytes: D0002715
In addition I always see:
17:22 Speaking slowly
This seems to be coming from the Ob1G5CollectionService thread, though I’m assuming here that the event log is completely reversed form what most people would think of as the normal order (i.e. the new lines always appear at the top, not the bottom). I’m pretty sure I haven’t seen that on a regular basis before, though I’m also pretty sure I have seen it before.
Dropouts seem to be occurring more often, though that’s just a feeling; I can’t prove or disprove it.
1 Like
I wonder if any changes in the 8Gxxxx will cause comm problems with the X2.
We were planning to use an 8Gxxxx for our next transmitter (currently on the 81xxxx) but I am wondering if it might be better to just skip over that one and go right to the 8Hxxxx.
We have come to rely on solid communication between the G6 and the X2.
1 Like
If you have the option then I suggest trying the 8G and if it doesn’t work reliably immediately swapping to the 8H. If I had a hoard I would, at this point, just swap to the 8H on the next sensor, but I don’t; I’ve only got one transmitter (the 8H) as backup. Since you are using a different setup and since I suspect the problems are in xDrip+ I would certainly want to try it to see what happens.
I keep coming back to this other fud thread:
It seems to me that Sayer was reacting to a situation where products not under Dexcom’s control reacted to quite reasonable changes in the G6 communications protocol by doing bad things. Of course I’m just guessing, but I have experience of working for one manufacturer and implementing a piece of perfectly correct software which produced a perfectly valid GIF that terminated another manufacturer’s buggy GIF implementation. After they refused to fix the bug I had no real choice but to produce sub-optimal GIFs for their benefit. It was annoying.
2 Likes
@docslotnick: That’s interesting and new to me! Do you have a link/reference with more background information what has changed on 8H transmitters compared to the 8G’s? I’m reading JamOrHam’s gitter forum and must have missed this piece of information. Where have you seen/read/heard this? Thanks for feedback.
@emp00 There was a mention of this on the Gitter boards about a week and a half ago. Haven’t read anything else about it.
I haven’t been on FUD much lately but when I was finding my sensor restart trick not working I knew where to come for a work-around, thanks 
For what it’s worth, my current transmitter is an 8H and it’s been catching me on my typical restart trick (new sensor no code, 15 minutes, stop sensor, start sensor w/ old code)
3 Likes