search

NightscoutFoundation / xDrip

Nightscout version of xDrip+
https://jamorham.github.io/#xdrip-plus
GNU General Public License v3.0
1.39k stars 1.14k forks source link

G6 Timestamp Issue when newly activated. #1778

Closed joshbohmer closed 6 months ago

joshbohmer commented 3 years ago

When first activating a G6 transmitter xDrip incorrectly reports the timestamps as negative for the first few hours. The transmitters internal times starts from 0ms.

This prevents xDrip from generating any packets that need a timestamp (like backfill requests) from being generated for the first few hours after a new transmitter is activated

Once xDrips timestamp goes positive <0 the errors go away.

tolot27 commented 3 years ago

While investigating the issue I discovered that the screenshot above shows slightly different values of "tx start:" (transmitter_start_timestamp). That is really strange because the transmitter start time is stored in the database.

jamorham commented 3 years ago

I think this is probably quite simple. Its just that a transmitter timestamp before transmitter start is being requested.

I expect this will come from backfilling and simply capping the backfill window to the transmitter start (or session start) would resolve the issue. I will look at that.

I don't think its related to the other mentioned issues.

tolot27 commented 3 years ago

@jamorham And why are different time strings reported for "tx start"? The max difference is 12 seconds. That cannot be a rounding issue.

emp-00 commented 3 years ago

@joshbohmer : I have never seen such an error message. No hits in my logs for "TimeKeeper" and "comparison". Running Dexcom G6 with xDrip nightly 2021-05-21. Also never saw such messages (before or after sensor start) with other xDrip versions. Totally new to me.

joshbohmer commented 3 years ago

@jamorham think you're correct about the backfill observation

The timestamp reaches 0 after 3 hours, so it makes sense.

@emp-00 You'll only ever see this for the first 3 hours after waking a transmitter wakeup & if xDrip requests backfill data (or anything else that calculates the timestamp before 0)

Navid200 commented 7 months ago

The limitation that backfill does not work until the start time is 3 hours in the past gets really bad with G7. Instead of 3 hours, the limitation is 24 hours for G7. Screenshot_20240306-101114

I will try to condition the backfill action so that it will not attempt to backfill prior to the start time.

joshbohmer commented 7 months ago

Interesting, I thought that was done already but clearly not.

Simplest method I would think will be to do MAX(0,start_timestamp)

This will ensure we never request before the transmitter start

Navid200 commented 7 months ago

@joshbohmer The start_timestamp would be the start time on the current sensor, right? With G7, if you pre-soak, that would be about 12 hours before the last timestamp of the previous sensor.

This gets a little bit complicated as we have seen overlapping curves. So, it needs to be done carefully taking into account all the different overlapping issues.

I hope to be able to create the overlapping curves and explain why it happens and if I can do that, I should be able to avoid it.

Navid200 commented 7 months ago

After today's Nightly (March 10, 2024), I just tested with a G6 and was able to backfill shortly after a start. I will be able to test a G7 in about 14 days.

Navid200 commented 6 months ago

xDrip could not backfill a G7 until 24 hours after start. With the latest Nightly, March 10, 2024, that problem seems to have been resolved.

I am closing this only because I don't believe there is anything else to fix. But, if I am overlooking something in that respect, please let me know and we can reopen. Thanks.