G7 - Pair next sensor

[WesSec]

Hi everyone,

While replacing my sensor this afternoon, I had an idea for a feature and wanted to see if it's technically feasible and if there's community interest.

The Problem
When a sensor is scheduled to expire at an inconvenient time (like the middle of the night or during a busy workday) I usually insert the new sensor in advance. While the official warmup for a G7 is only 30 minutes, in reality, new sensors are often jumpy and inaccurate for the first few hours (sometimes up to a day) while they acclimate. Conversely, the expiring sensor is usually highly accurate right up until it dies.

Currently, I have to choose between two bad options:

• Switch to the new sensor early, wasting the remaining hours of reliable data from the old sensor and dealing with inaccurate readings.
• Set an alarm to wake up at 3 AM (or interrupt on a busy day) just to manually enter the new pairing code in xDrip.

The Idea: Queueing a future sensor
It would be incredibly useful to pair a "next-in-line" sensor while the current sensor is still active.

• The old sensor stays paired and provides readings until its exact expiry.
• The new sensor is paired simultaneously, connects, and completes its warmup phase in the background.
• Upon expiry of the old sensor, xDrip automatically transitions to using the new sensor's readings.

Example Use Case (Dexcom G7)
If my G7 is set to expire at 3 AM, I want to maximize its reliable lifespan. Instead of waking up at 3 AM to enter the new pairing code, I could insert the new sensor at 11 PM before bed and enter the pairing code into xDrip. xDrip holds the connection, lets the new sensor warm up, and continues displaying my old sensor's data. At 3 AM, xDrip automatically handles the switchover while I sleep, and I wake up to a new sensor that has already been "soaking" for 4 hours and is providing stable readings.

I'm assuming the Bluetooth stack can handle holding the connections to both sensors simultaneously during this overlap period, but I'd love to hear your thoughts on the technical feasibility of this.

[Navid200]

This is a very good idea.

Can we talk about pros and cons first please?

I always insert a new sensor in the morning. I did this even when I used G5. My thinking was that by the time I go to sleep at night, I would like the sensor to have worked for quite a while so that it would be less likely to cause an unexpected behavior.
As long as I insert a sensor in the morning, it will expire in 10 days before midnight.

I definitely understand that for a special case, I may end up inserting a sensor at 3pm. then as you describe, in ten days, it will expire at 3 am. I definitely don't want to wake up at 3 am to deal with it. In an exceptional case like that, I switch late at night and as you have correctly explained, I do sacrifice a few hours of stable operation from my previous sensor.
That is what your proposal will avoid. It definitely is good if we can find a way to avoid that. I'm not debating that.

My question is how often does this happen?

You may be wondering why does any of this matter? What is wrong with my proposal?
That would be a fair question.
My concern is the following.

1- What you are suggesting is simple in function. But, in order to implement it in code, it will require a lot of work.
2- When you switch the transmitter ID, you will have to manually approve a pair request. You won't only if your phone runs Android 10 or older. Android 11 and newer requires a manual approval.
3- If you have 2 G7 devices that are both in rapid reconnect mode, they both will be looking for connectivity once in a minute rather than only once every 5 minutes. I have experienced serious problems in a scenario like that. That is why my guides always ask you to peel off the old sensor and move it away more than 10 meters before changing the transmitter ID to that of the new sensor.

I have been using G7 for close to 3 years now. In that period, I have only once had to start a sensor at 3 pm.

This is my guide for starting a subsequent G7: https://navid200.github.io/xDrip/docs/Dexcom/SubsequentG7.html

I am interested to know your thoughts on any of this.

[Navid200]

Every transmitter runs using its internal free-running oscillator. The frequency is once every 5 minutes. However, the accuracy is not perfect. This means that the two transmitters will not transmit exactly at the same time. Not only that, but their frequencies are not going to be exactly the same either.

xDrip or any other app that connects to a transmitter always wakes up a little bit early to make sure if the transmitter oscillator runs a little bit too fast, it will be captured and continues to scan for a little bit longer just in case the transmitter runs a little bit too slow.

If we want to implement what you suggest, we will have to have two phase-locked loops instead of just one running in xDrip. This is not easy and will drain the battery as well.

If you are not suggesting that and only suggest that we pair with the new transmitter but do not keep connecting to it until the time comes that we switch to it, this will cause a different problem. The Bluetooth link is two =-sided. The transmitter is also aware of the link. After the second transmitter pairs, if it does not receive connectivity handshake once every 5 minutes, it will change to rapid reconnect mode because it will assume that there is no link any longer.
Whwn the time comes for us to connect to this new transmitter, xDrip will have no idea when to wake up because by now (about 12 hours later), its internal oscillator could have drifted significantly.

If we want to address all of these, the mechanism needed will be extremely complicated and power-hungry.

I don't understand why you have 2 out of every 10 sensors end at an inconvenient time. But, there is a solution that is not going to be very cost-effective. When this happens, say you know your current sensor will end at 3 am, don't wait for the day to come to start the new sensor. Start the new sensor one day earlier. Then, switch to it a day sooner. This means you switch from your old sensor one day sooner to address the inconvenient end time.
This is a horrible solution. But, the change to xDrip you are suggesting is worse solution than that with all due respect.

[WesSec]

But, the change to xDrip you are suggesting is worse solution than that with all due respect.

Point taken. This is why I wanted to discuss it. The complexity is too much for what it brings

Thanks and speak soon!

[xitation]

I love this idea!
, shame it sounds complex to implemt though.

[asavageiv]

This is great to find because I had the same idea and started implementing it on my own. I didn't know that the sensor would switch to rapid reconnect mode if a handshake was not completed after 5 minutes. This tells me I need to refactor the code so at least the handshake completes. If I go that far, I may factor out enough to take parallel readings. Maybe they will be useful in the future. For example, I could see how far off the sensor was after warmup vs after 12 hours. Could we use the old sensor to calibrate the new one?

I have a very chaotic schedule and I often find my expiry happens at inconvenient times. Usually it's because it's at night when I'm sleeping. I also try and "soak" my sensors for 12 hours because I find them to be inaccurate for that first day. Soaking minimizes the time with bad readings (where my AAPS loop is affected). Since my phone is usually plugged in when I'm sleeping, the extra battery drain on the phone side wouldn't be an issue for me.

Is there a potential battery problem on the sensor side if it gets stuck in rapid reconnect mode for 12 hours?

I don't expect any of my changes will/would be merged into xdrip anytime soon, but I will make them available when they're ready.

[Navid200]

I always see what the new sensor is reading while I am still using the old one for about 12 hours. In that period, it has been my observation that the new sensor usually reads lower than the old sensor. And the delta gradually decreases during the 12 hours of overlap.

G7 fluctuates.
During the first 12 hours, G7 also could fluctuate more.

I am putting myself in the shoes of the individuals who so far have shown interest in this.
I understand that there are jobs or life styles that do not allow consistency. So, I can imagine a situation when you have to go to bed and your new sensor has only run for 1-2 hours so far.

I have had to do this myself, And I use AAPS. So, if readings fluctuate, AAPS could inject insulin that it shouldn't or it could stop injecting insulin when it shouldn't.

AAPS has 2 smoothing options. I use the most aggressive filter. It is called "Exponential smoothing". Its disadvantage is that it adds delay. I am not happy that I have to live with this added delay.
So, I have submitted a feature request for AAPS: nightscout/AndroidAPS#4677
When that feature is added to AAPS, we will be able to set up an automation that will automatically enable exponential smoothing when a new G7 sensor is started. But, after a set amount of time, like 24 hours, it will automatically switch to the less aggressive filter (Average smoothing) with less delay. But, for now, I am using the more aggressive filter continuously. It is working fine. The smoothing deals with the G7 fluctuations.

---

The proposal in this PR here is an extremely complicated feature to implement.
In my opinion there are simpler alternatives that address the need that it is meant to address.
xDrip does not get readings from two different sources at the same time. That is why you can only choose one item on the hardware data source. You are effectively asking xDrip to get readings at the same time from two different sources.
This will open a can of worms.

---

There are features we seriously need in xDrip. There are open issues we need to fix. We can use your talent. We need to use our limited resources (talent) to address the needs in the correct priority.

Do you know that if you are sleeping and for some reason your sensor stops working and a missed reading alert triggers, if you have lowered the volume on your phone, you may never hear the missed reading alert?
In my opinion, that is a serious shortcoming that we need to address.
There is a lot in xDrip we need to improve. We need your help to focus on what needs to get done.

---

Can you see this open issue?
#3641
It popped up when Android 14 came out! That was years ago. Issues like that come up as soon as we make an update. We have just retired Android 7. I am nervously watching all the forums to see if anyone brings up a new issue caused by it.
Maintaining this app takes a lot of effort.
Every new feature will need to be maintained. Don't think that the challenge will be over after you figure out how to add a new feature. The issues will come up for all features.
One of the reasons I cannot address requests for new features as fast as I would like to is that most of my time goes into dealing with issues!
We cannot just keep adding feature after feature.
We need to strike a balance. We need to prioritize.

I perfectly understand the problem you have described.
My suggestion is to use an existing smoothing feature in AAPs to address it please.

[asavageiv]

Thank you for your attention and time Navid. Your stance makes perfect sense to me.

I always see what the new sensor is reading while I am still using the old one for about 12 hours.

How are you doing this? 2 phones?

[Navid200]

No, I use a variant.
Please have a look at this and let me know if you have any questions:
https://navid200.github.io/xDrip/docs/Dexcom/SubsequentG7.html

[Navid200]

This is a screenshot showing my main xDrip as well as a variant:

The one at the top is my main xDrip connected to my 10-day old G7 that will expire tonight.
The one at the bottom is the variant connected to my new G7 that I inserted a few hours ago.

What I would like you to see are the times. I have marked them with yellow markers.

You can see that the new sensor is about 1 minute ahead of the old sensor.
But, there is no known relationship between the two. It's just random. Each sensor has a free-running oscillator in it that is not locked to any time reference. So, the two can have any possible relationship. The next time, the new sensor could be behind the old sensor. The time difference could be different. It could be 2 minutes or 3 minutes ....

But, it doesn't end there. The frequencies are not exactly the same either! They both run at one cycle per 5 minutes. But, if you dig down and measure the time more accurately, you will see that they drift with respect to each other. If the difference between the two is for example 56 seconds now, it 12 hours, the delta may be 64 seconds or it may become 52 seconds.

xDrip acts like a phase-locked loop to stay locked to the sensor. Every time xDrip gets a reading, it sets itself to wake up just a little bit sooner than 5 minutes later. It does this so that it can be sure that it will always find the next ping at the right time. As the sensor slightly drifts, xDrip keeps drifting with it.
But, if xDrip has to stay connected to two different sensors, it will have to do this twice. This is not a very simple task.

I had explained all of this before. I thought a picture may help give a better understanding.
The proposal here is not impossible to implement. But, it is extremely challenging. And when the time for the review comes, the challenge becomes to explain why it is necessary.