Changed clock on uploader device may cause issues with records

[Pogman]

If the clock is changed on the phone either by user or automatically due to travel etc there may be issues related to internal record keeping.

As it stands now time is expected to move forward for each progressive poll. Future polling for pump-sensor sync is basing on the most recent date as recorded. If the clock is adjusted backwards then polling may be incorrectly set.

There may be other issues related to a changed clock that need to be explored.

[cfaagaard]

Suggestion (you might already considered this): Use the RTC (from the pump) instead of the datetime for timing-functionality.

[volkerrichert]

his is only a onetime problem? After the next sync i'll will be in sync again. Right?

If not, just add a menu item "i changed the pump time and resync"...

I don't like the idea to rely on the RTC of the Pump. It' drifting to much.

[cfaagaard]

Ok. Good point. Was not aware of the RTC drifting. Will look into this as I am using the RTC :-)

[Pogman]

This issue is more a note to "look into it" - The concern is that a uploader device clock change backwards will do something like this:

1 ... 3 ... 6 ... 9 ... 12 ---- oldest =1 newest =12

Clock changes back to 5, and now records get messy:

1 ... 3 ... !5! ... 6 ... 9 ... 12 ---- oldest =1 newest =12

It's going to be a rare enough situation and the easiest way to deal with it is probably a auto detection of records that are ahead of the device clock - push a warning note for user and clear the records.

[volkerrichert]

But our dates are on phone time, So the difference of pump time and phone time is e.g. 1sec instead of 200sec. So the "real"/ used time adjust this. But yeah, if the clock differs a lot and the time is changed between measuring and polling this can happen. But this can be detected. The expected time should be in the expected time frame and the difference between both clocks shouldn't change that much in comparison to the last query. If not, pump time was adjusted.

But yes, really rare case. I would ignore it and add an "clock" icon in geen/yellow/red to inform the user about RTC drift.

[cfaagaard]

I may be wrong as this is an area (hardware) I am not too familiar with; but I read somewhere that the pump is using a chip “DS3231” which should be extremely accurate in terms of RTC. So no matter of the date/time on the pump or on the uploader-phone, the RTC from the pump should be the same. Even if you change date/time on the pump/phone.

Or have I misunderstood the RTC-“concept”?

[Pogman]

A RTC should be fairly accurate with a small drift per year but the pump drifts by a few seconds per day.

My half-baked theory is that the pump is synced to the way the sensor works. Which is to send a number of voltage pulses and measure the response, there is a fixed count to these pulses and this count averages 5 minutes. There is something in the Medtronic patents that refers to this but it's been some time since I looking so... half-baked.

[cfaagaard]

Ok. How can one test this? (the RTC-drifting). I use the RTC; I save the RTC for the last reading for the pump and use it in the next reading. I do not rely on the date/time for the pump or uploader.

(EDIT; and maybe not; I can live with a few seconds per day)

[Pogman]

Maybe something like this to see the drift:

get the time from a network atomic clock run for 500 polls (500 x 5min) compare where you expected to be with the actual atomic clock, difference is the drift for that period.

[cfaagaard]

Sounds like a fun test. :-) I will let you know of the result. (see you in 5x500 minutes).

[cfaagaard]

I tested the RTC-drifting. And it seems there is about 4 seconds drift per day for the RTC.

See my findings here: https://github.com/cfaagaard/CGM.NET/wiki/RTC-drifting

[Pogman]

@cfaagaard yep that's what I got to and around +30 secs a week - I still find the size of the drift really surprising after all this time (pun!)

[Pogman]

Time issues integrity checks added. Even when user changes to clock into the future or past any messiness in the uploader db will throw an integrity error and run a reset procedure. This will resync history from the pump with new times and rewrite records as needed in nightscout.

Additionally nightscout server time is compared with the uploader device and user notified if out of whack and advised on how to correct.

[tuzoenduro]

Question, so the timestamp for BGs posted on NS is the phone and not the pump?

[Pogman]

If you have the correct time on the uploader device and say you bolus at 3pm then NS will say 3pm. It's all worked out accounting for the pumps odd drifty timekeepiing.

[tuzoenduro]

Cool, that is what I thought. Thank you!!

On Wed, Feb 13, 2019 at 7:29 PM Pogman notifications@github.com wrote:

If you have the correct time on the uploader device and say you bolus at 3pm then NS will say 3pm. It's all worked out accounting for the pumps odd drifty timekeepiing.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/pazaan/600SeriesAndroidUploader/issues/154#issuecomment-463312600, or mute the thread https://github.com/notifications/unsubscribe-auth/APr1vGAToz_7RC-F863UC5gb1GmM1x3xks5vNFmigaJpZM4PPJbU .

--

---

Dr. Luis Toussaint

[Pogman]

Closed - completed and available in 0.7.0 release