New sensor warming up, but not started?

[gitanO0]

Odd thing today after years of using G6 and xdrip+ on Android. I put on a new sensor, started it as usual... then a few minutes later, xdrip+ reported the sensor being stopped. Now, about 15 minutes into the new session, xdrip+ reports at the top of the main app, "Now start your sensor or check settings". At the bottom of the app, above the 24 hour graph, it says, "Warming up 1.8 hours left". If I go to the menu, there is an option to "start sensor", which isn't usually there when the sensor is actually started. If I go to the system status screen, everything looks normal. Not sure what's going on here. Any clues, ideas?

I should add that in the system status screen, sensor status states, "Warming up 1.8 hours left".
I fear things are started in a proper fashion, but I'm not sure what when wrong during my startup process.

If I look at the error/event log, I see, after some "starting new sensor" messages an Ob1G5StateMachine message stating, "Could not read reply to auth challenge: com.polidea.rxandroidble2.exceptions.BleGattCannotStartException: GATT exception from the MAC address .......... with type BleGattOperation{description='CHARACTARISTIC_READ'}

Then the next message in the log: "Marking sensor session as stopped"
then
"Sensor stopped at xxx date/time"

[Navid200]

Do you mind posting a screenshot of the system status page? You can blackout the transmitter ID if you like.

[gitanO0]

[gitanO0]

Since that screenshot was taken, the status screen is reading "disconnected" and "deep sleeping"... everything else is the same.

[gitanO0]

It looks like part of the app thinks things are started properly and another part of the app is set to "stopped", either way, doesn't look good for getting a proper session going.

[Navid200]

One item on the system status page that is more important than everything else is "Last connected".
Was it not there before you restarted the phone?

[gitanO0]

I believe it that it had connected. Now the status page is showing "got needed 13:54" "warming up 1.2 hours left", "connected" and Last Connected "1 minute ago"

[gitanO0]

but still, on the main app screen it says, "Now start your sensor or check settings"

[Navid200]

What's important is what you see on the system status page.
Does it say it is warming up there?

[gitanO0]

I'll post a new screenshot

[gitanO0]

If I click the little red flag in the main graph area, just to the right of the green "start" flag, it says, "Stopped by Transmitter"

[gitanO0]

Is there a way I can "reset" this session and try all over again?

[jamorham]

Once it completes warm up it should be fine. Did you stop a session manually just before starting this one? I think that is where it can occasionally get confused.

[gitanO0]

yes

[jamorham]

You also probably can do another sensor start and xDrip will accept it and the transmitter will ignore it which also would cure the problem but as soon as it gets the first reading it will automatically start the sensor in xDrip I believe.

[gitanO0]

ah, ok. I'll try that

[gitanO0]

[gitanO0]

Ok, I actually tapped the "start sensor" menu option, put in the code and now the app says, in red at the top, "Please wait while sensor warms up! (60 minutes)"

and at the bottom, "Warming up Ends in 10 days 1 hour left"

Menus is now saying, "stop sensor" instead of "start sensor"

and system status page has good messages from top to bottom.

[gitanO0]

Will report back when warmup is done and confirm if this is still an issue. Not looking like an issue as of now.

[gitanO0]

2 hour warm up passed and everthing is working normally. Crisis averted.

[gitanO0]

Thanks @jamorham and @Navid200 for the help!

[Navid200]

You are welcome

[old-square-eyes]

I have just had this same issue. I also tried to restart the session in xDrip to overcome the phantom stop (I have had this a few times before but just saw the red flag after @gitanO0's comment). Personally I don't think a 2hr wait is satisfactory in this situation. For one it's nearly midnight here when this is going down... another late night grinding the diabetes!

It occurred to me that xDrip will pick up an already started session, if only it were in the right state itself (I have done this for other reasons). According to xDrip, in this state, the session is started on the TX... therefore you should be able to Stop the session in xDrip, and "Clear Transmitter Queue" before it's sent. Then restart collector / toggle source. Then xDrip will reconnect on next 5mins and interpret the already started session and carry on with it. It's risky as you might not be able to clear the queue in time before it's sent to the transmitter. But nothing lost as far as I can tell because a 2hr wait as described above is as long as sending a proper stop command and starting proper again.

Having said all that (and successfully killed the TX queue in time). It didn't work and xDrip still tells me I don't have a session. I am convinced that it's the actual TX that has not started, in spite of xDrip reporting that it has. I think the clue is in the red flag "Stopped by Transmitter: Stopped". xDrip had you thinking it's still started but it's not and you gotta start all over again.

Final edit: OK I restarted per @jamorham and it picked up the original session and immediately continued/kicked-off on the next reading (no two hour warm up). I'm pretty confused now and likely no longer have a useful/clean test. But I'll leave this here anyway in case it's of any use.

[Navid200]

No app can show you exactly what is going on in that instant on a G6 (or G5 or G7) transmitter. This is because there is never a persistent connectivity between a transmitter and an app. The system operates based on a sample and hold mechanism.
The connection happens only once every 5 minutes for a few seconds. xDrip shows what is going on based on what it has received the last time it had a handshake, which happens only once every 5 minutes.
There are times xDrip requests an info and it will not receive it until the next time slot.

This gets complicated when you establish connectivity with a transmitter for the first time and you have used a different app or device to start a session on the same transmitter already. In this case, you will need more than one handshake before you have all the info validated.

All confusion can be avoided if you establish connectivity and allow 3 consecutive handshakes before starting a sensor if needed.
If you wait for proper connectivity, if there is already an ongoing session, xDrip will detect it and update everything and you will not even need to start a sensor. But, this cannot happen right away.

There are people who advocate the use of variants for starting sessions on multiple transmitters. Variants were never offered for that purpose. And the intent can be easily accomplished using another temp phone. But, it is ironic how much grief users go through following incorrect instructions.

[old-square-eyes]

Thanks @Navid200.

Quick question on that. How is starting a session on a variant any different to using a temp phone in this context?

[Navid200]

That's a very good question.

When I add something to xDrip, I never ask myself "how is this going to behave on a variant"?
I don't believe any developer does.
That's never on my mind. Let me give you an example:

I recently added the ability to save logs locally: https://navid200.github.io/xDrip/docs/Logs.html
The logs are saved in the Download folder and the filename is always the same. Therefore, when you save the logs, it overwrites the previous log.
But, if you do that and then go to a variant and do the same, the variant is going to save its logs over the logs that were saved by the main xDrip.
Do you see what I mean? I never added the ability to distinguish the saved logs in order to allow one to save logs from different variants and be able to compare them.

Now, that was just a very simple example.
Bluetooth protocol is not very simple.

When the variants were offered, the only intent was to allow a parent to follow multiple diabetic children with the same phone. That is a very useful intent and we have satisfied that intent.
But, there are always people who try different things and unfortunately, they publish it.

You can use a single phone to have Bluetooth connectivity with many many different Bluetooth devices.
But, Dexcom never created their devices for that purpose. If you use the same phone in order to have connectivity to two different Dexcom devices at the same time, you are getting into an unchartered territory. I strongly advise against that.

Using a test phone, you will be using a dedicated piece of hardware for establishing a Bluetooth link with a Dexcom device. That is exactly what Dexcom is designed for.
After the new sensor has gone through the unstable phase and you want to switch to it, you change the transmitter ID on your main phone and switch from the first transmitter to the second. Therefore, you never connect to two different transmitters from the same phone.

[old-square-eyes]

Valid points thanks. Don't want to go off topic too much, but as a side variants have greatly improved my management for a few different reasons. It would be a real shame if they were sunset.

[Navid200]

I'm not aware of the variants going away.

I just wish people wouldn't use them for what they were not intended.