xDrip does not process stop/start order correctly when replacing G6 sensors

[adanvdo]

I had to replace a sensor today. I stopped the G6 sensor in the app. When I do this, I always wait for the logs to show that the sensor is actually stopped, due to issues I have run into where the new sensor is put into a bad state. See issue #1632

After the logs read "sensor stopped successfully", I started the new sensor. However, a few moments later, xDrip tried to mark the new sensor as stopped. I was then told to start a new sensor again. When I did this using the same calibration code for the new sensor, I received a notification that the start failed.

Throughout this whole process, the main screen showed statuses that were inconsistent with the logs. This is also mentioned in issue #1632

This is really frustrating. Sometimes my son's mother has to replace his sensor and we constantly run into issues. She doesn't know how to read the logs to make sure a new sensor is ready to be started.

xDrip should not try to start a new sensor until the old session is properly stopped and the app and sensor are in the proper corresponding state.

[Navid200]

Please open a discussion instead of an issue. It can then be converted to an issue if needed.

There are different problems experienced by G6 users.
Some are experienced even by those who use the official Dexcom app.

The majority, if not all, the issues resulting in sensor start fail is due to connectivity issues.

There may be improvements we can make to xDrip. But, please note that every proposal will have to be tested and proven and even then it may still not be merged because it is not something that can benefit everyone. Or, it may be something that would introduce complexity that is not worth the improvement it makes.

Regardless of how we can improve xDrip, I am doing what I can to help users by telling them what to do and what not to do using xDrip as is:
https://navid200.github.io/xDrip/

With respect to this, I suggest

• never stopping or starting a sensor unless there is proper connectivity
• after removing the transmitter from the body, never attach it to the new sensor right away; wait at least 10 minutes

[jonprogers]

@adanvdo I don't know if this is significant but I always let one full 5 minute cycle run after the stop sensor is confirmed by the transmitter (so at least 10 mins after the stop is sent to the tx and around 15 mins after I input the stop) and I don't see the issue you are seeing. Not claiming this is a fix but a workaround that works for me.

I have an LG G5 with android 8 and am currently running the xDrip nightly from 2021-11-06, maybe ought to think about upgrading soon!! Also run a t:Slim pump that connects to the G6 but always do starts from xDrip.

[adanvdo]

I have been using xDrip for years because I cannot use the official Dexcom app. The problem we are experiencing is not related to connectivity. It is a bug with how the app processes the queue.

In the case I have attached, the new sensor did not actually fail. A bug with the way the app processes the task queue caused it to become out of sync with the state of the sensor. The app thought it stopped the new sensor, which was incorrect.

While waiting 5-10 minutes does seem like a workaround for this issue, workarounds are not solutions to software problems. Giving people complicated instructions for how to use software to navigate around bugs is a poor solution. I understand that there may be a lot of issues created here, and you guys are doing this voluntarily (which I appreciate) but when a user reports a bug it should be treated as such and not ignored.

@jonprogers thank you for the tips. I will attempt waiting longer next time. However, the developers should fix this issue and the issue in #1632

[jonprogers]

no worries, I'm not saying a fix shouldn't be considered but I'll live with workarounds on a volunteer developed and supported app that is so much better for me than the official app and remain grateful to all those who know far more than me and make all the magic happen!!

[Navid200]

Many of the open issues are misunderstandings.

If you believe that fixing an existing open issue will fix what you are describing here, it is better to post in that existing issue rather than to attempt to open a new one.
These discussions are not ignored.
Neither are the issues that are still open.

If there is an existing open issue and you would like to remind the developers, the best course of action is to open a discussion rather than opening a new issue. Cluttering the issues platform is not going to encourage the developers to solve an existing issue.

You can insert a new sensor, remove the transmitter from the old one and right away snap it into the new sensor and start the sensor and you will have an issue. And this is not limited to xDrip.
You can experience this even if you use the Dexcom app.
It is unfair to ask us to fix this in xDrip when the official app has the exact same result.

[adanvdo]

Navid, the official dexcom app does not tell you to start a sensor when it is not ready to be started. xDrip does. this is a separate issue from the one I referenced. This issue is related to stopping and starting.

The official dexcom app will not display a false indicator that a sensor is stopped when it is not. It will also not instruct you to start a sensor when it is not ready to start one.

[Navid200]

I have had this conversation with jamorham before.
I would like to change xDrip to improve it when possible.

Can you help me?
I need to prove, to the other developers specially jamorham, that xDrip is encouraging the user to tap on start sensor when it shouldn't.

The belief is that it doesn't.

I also have seen posts in the Dexcom facebook group by users complaining that they started a brand new sensor and it failed. They are advised, in the facebook group, to call customer service and ask for a replacement for the sensor.

I don't claim that I have personally experienced the same issue with the Dexcom app.
I have never used the Dexcom app.

The following is based on my understanding relying on my readings. So, I COULD be wrong.
The G6 transmitter firmware was modified to drastically discourage users from attempting to restart sensors.
One of the results is that if the transmitter is not out of the sensor for two consecutive read cycles, the transmitter may establish that there has been an attempt to restart and refuse to start.
This is a transmitter behavior. There is nothing we can do to xDrip to change a transmitter behavior.

I agree that xDrip should not encourage the user to rush in starting a sensor.
This is something I have been working on for a quite a while. The problem is that I am not a programmer.
So, when I pursue something, it takes my much longer than it takes the other developers. I am sorry about that.

As a reference, please look at this open issue:
#553
It is a clear bug. No developer has claimed that this is not a bug.
I have an open PR for it:
#1702
But, it's not a very nice solution. The solution is to find a way to change the font size for a seekbar title and make it wrap. I couldn't.
So, I have changed the setting and have moved the text from the title to the summary. It can still be read. It can be seen on a very small screen. So, it addresses the issue.
However, it has not been merged.
I'm not complaining. I am pointing out that it is not very easy to make changes to xDrip.

I am sorry about the problems. I will do what I can to help.

[Navid200]

I just went through a stop sensor and start a new one process.
I noticed there were times someone may see info that may seem contradictory.

Please note that some of the information shown on the G5/G6 system status page is info coming from the transmitter.
Please also note that the 2-way communication is through a queue as you have mentioned already.

So after I tapped on stop sensor a red flag was placed on the screen.
When the next reading cycle was completed, the system status page was still not showing sensor stopped. This may be surprising to someone. It shouldn't be. All it means is that the last info we got from the transmitter told us that it was still running.
This makes sense because the last queue just told the transmitter that we wanted to stop.

After the next read cycle completed, the system status page showed sensor stopped.

The exact same thing happened when I started.
When I tapped on start sensor, the command was shown in the queue in the system status page.
After the next read cycle, the main screen showed "starting sensor". This is thanks to jamorham after the complaints.
But, the system status page still showed sensor stopped. This again makes sense. The last queue told the transmitter that we wanted to start the sensor. But, the transmitter has not had a chance to respond to us yet.
So, at this point, if someone looks on the main screen, they see starting sensor. But, if they look at the system status page, they see sensor stopped. This is not a bug. I actually want to see exactly what the transmitter told us in the last queue. So, as a user, I want this to be exactly as it is.

On the next read cycle, the system status page changed and showed warming up instead of stopped.
We can make changes. I am OK with making changes if it is necessary.

But, please let's not call every discrepancy a bug. Some discrepancies are expected.

[adanvdo]

@Navid200 sorry it took so long. My son hasnt been with me when he needed a sensor replacement until today. Here are the exact steps where I am experiencing the issue.

1. 11:50AM - I manually stopped the sensor as I was seeing sensor errors for over an hour

2. 11:53AM Logs show Sensor Stopped Successfully. "Sensor Stopped" Status displayed on bottom of screen, and "Start Sensor" button is visible

3. 11:58AM - 5 minutes later I start the new sensor

4. 11:58AM - Sensor is logged as Stopped again. A ~5 minute difference between the app and the transmitter.

5. 11:59AM - "Start Sensor" button is enabled again. The app is completely out of sync with the sensor and transmitter. The screen tells me again to Start a sensor, and also displays "Sensor Started" at the bottom of the screen.

6. 11:59AM - I start sensor using the same code. Status on screen displays "Warming Up 1.9 Hours Left"

7. 12:03AM - Session Start Failed error pops up on phone. Logs show that the sensor was started, warming up 1.9 hours left. It is then immediately followed by Session Start Failed message.

8. 12:08PM - App state and sensor/transmitter state are back in sync.

With this, there are obvious issues in how the app handles the queue and status from the transmitter. The app should not display that the sensor is stopped and enable the ability to start a sensor until after the sensor is actually confirmed stopped. Or at the least it needs to be fixed so it doesnt confuse the new session with the old one.
When you start the a sensor before the stopped confirmation, the app thinks the new session you are attempting to start is the old one and enables the UI to accept a Start again. That leads to a "session start failure" which is really confusing if you don't know to read all of the verbose logs and make sure a session is in progress.

[jonprogers]

I think you would have got a fault free start if you had waited a little longer before starting the sensor (only a matter of seconds!)

My reasoning for saying this is as follows, taken from your log capture ay 11:59 in step 3;

• you issued the stop at 11:50:01
• this was sent to the sensor in the comms cycle at 11:53:52
• the next comms cycle would confirm that the sensor was stopped and would be due at 11:58:52 (wakeup for that comms cycle was scheduled for 11:58:47)
• the new sensor was started at 11:58:16 but I do not believe the start sensor should be entered in xDrip until after the 11:58:52 cycle is completed, about 40 seconds after it was done

I don't want to get involved in the debate about how this 'should' function as I don't believe I can add value there, I'm just commenting on my observations and experiences of how I use xDrip without issue. If you can wait for that little bit extra time I think you will find that the sensor start events flow through fault free.

I change my sensor tomorrow, I'll try to watch things a little more carefully than normal and update here if I can add anything else...

Jon.

[adanvdo]

The point I am trying to make here is that the App instructs you to start a new sensor and updates the state of the UI before it is actually ready for it.
Everything I documented proves that. There is a clear and obvious inconsistency between the app UI and the sensor state.

[adanvdo]

If i worked with Java and android i would contribute to fixing this myself. Unfortunately I work with other languages and don't have an Android dev environment

[jonprogers]

The point I am trying to make here is that the App instructs you to start a new sensor and updates the state of the UI before it is actually ready for it. Everything I documented proves that. There is a clear and obvious inconsistency between the app UI and the sensor state.

I see your point perfectly, and also believe it to be a totally valid position. I just hoped I could help alleviate frustration whilst the discussion develops any long term and bullet proof resolution that is agreed to be needed...

Unfortunately, I too lack the skills to do anything tangible to offer a fix.

[Navid200]

I find your description puzzling. When I stop a sensor, it takes quite a while before xDrip shows sensor stopped on the main screen.
Would you mind showing the logs at 11:50 when you stopped the sensor?

[adanvdo]

The first screenshot shows the sensor stopped and start new sensor message. although it was at 11:56 that was still before the sensor was actually stopped at 11:58