Controller Time Drift


Khalid Baheyeldin
 

From another thread ...

On Sat, Mar 20, 2021 at 10:25 PM, Khalid Baheyeldin wrote:
On Sat, Mar 20, 2021 at 05:41 PM, Howard Dutton wrote:
However many seconds they drift apart multiply by 15 for the # of arc-seconds that would be over that hour or two and ask yourself if that is ok.  Keep in mind that in a temperature controlled enviroment the drift can be less than what happens at extreme temps outside.
There is drift on my FYSETC S6 V2.0.

Here is what I started with, from the web interface:
Browser Time: 23:55:46
OnStep Time: 23:55:51

After two hours
Browser Time: 01:56:35
OnStep Time: 01:56:48

That means 8 seconds over 2 hours, so 4 seconds per hour, which is 60 arc seconds per hour.

Air temperature outside is 5C, although the scope would be below that, and even below freezing, due to heat loss to the clear sky.

However, with autoguiding there does not seem to be an ill effect.

Here is the Running Man Nebula, Flame Nebula, and M 78.
All single 300 second shots with colour stretching.

If it is clear tomorrow, I will wire in the GPS PPS only (not TX/RX) and see if there is a difference.
The RMS may be nominally better, but I don't expect the end result (images) to be different.
That was about the FYSETC S6 with OnStep 5.1v, with no signal providing PPS (GPS was ripped out of the box).
When autoguiding, the corrections were in both directions on both axes, so there is drift that is observable in the graph.

I repeated the same test with the Blue Pill and an F303CC.
The PCBs have a DS3231 RTC, and PPS is enabled on it.
Also with OnStep 5.1v.

I started with this, at 15:46 local time. With the mount powered up, date/time uploaded, but not tracking.

3/23/21 19:46:24 UT (web browser)
3/23/21 19:46:24 UT (02:30:15  LST)

Then by 17:46 it was:

3/23/21 21:46:19 UT (web browser)
3/23/21 21:46:53 UT (04:31:04  LST)

And a bit later:
3/23/21 21:51:54 UT (web browser)
3/23/21 21:52:30 UT (04:36:42  LST)

So it is not an issue with the FYSETC S6 resonator/oscillator.

What else can it be?
Those who have other boards (CnCv3, MKS Gen-L, MiniPCB) and OnStep 5.1v, can you share your results after 2 hours?


Dave Schwartz
 

As I recall from previous discussions, and I may be wrong, the time is only set at the beginning of the session... with an RTC, during initialization, and with a GPS, as soon as PPS becomes active.

I do know, from reading the code at the time, that PPS is not used continuously to condition the clock. OnStep gathers about 15 PPS pulses, conditions its timers from that and then that's it. I don't know what would happen if you reupload the time or if PPS were to go away and then reappear (probably hard to do that with an RTC as it would involve ripping out hardware from a running system but entirely possible with a GPS).


On March 23, 2021 7:32:05 p.m. EDT, Khalid Baheyeldin <kbahey@...> wrote:
From another thread ...

On Sat, Mar 20, 2021 at 10:25 PM, Khalid Baheyeldin wrote:
On Sat, Mar 20, 2021 at 05:41 PM, Howard Dutton wrote:
However many seconds they drift apart multiply by 15 for the # of arc-seconds that would be over that hour or two and ask yourself if that is ok.  Keep in mind that in a temperature controlled enviroment the drift can be less than what happens at extreme temps outside.
There is drift on my FYSETC S6 V2.0.

Here is what I started with, from the web interface:
Browser Time: 23:55:46
OnStep Time: 23:55:51

After two hours
Browser Time: 01:56:35
OnStep Time: 01:56:48

That means 8 seconds over 2 hours, so 4 seconds per hour, which is 60 arc seconds per hour.

Air temperature outside is 5C, although the scope would be below that, and even below freezing, due to heat loss to the clear sky.

However, with autoguiding there does not seem to be an ill effect.

Here is the Running Man Nebula, Flame Nebula, and M 78.
All single 300 second shots with colour stretching.

If it is clear tomorrow, I will wire in the GPS PPS only (not TX/RX) and see if there is a difference.
The RMS may be nominally better, but I don't expect the end result (images) to be different.
That was about the FYSETC S6 with OnStep 5.1v, with no signal providing PPS (GPS was ripped out of the box).
When autoguiding, the corrections were in both directions on both axes, so there is drift that is observable in the graph.

I repeated the same test with the Blue Pill and an F303CC.
The PCBs have a DS3231 RTC, and PPS is enabled on it.
Also with OnStep 5.1v.

I started with this, at 15:46 local time. With the mount powered up, date/time uploaded, but not tracking.

3/23/21 19:46:24 UT (web browser)
3/23/21 19:46:24 UT (02:30:15  LST)

Then by 17:46 it was:

3/23/21 21:46:19 UT (web browser)
3/23/21 21:46:53 UT (04:31:04  LST)

And a bit later:
3/23/21 21:51:54 UT (web browser)
3/23/21 21:52:30 UT (04:36:42  LST)

So it is not an issue with the FYSETC S6 resonator/oscillator.

What else can it be?
Those who have other boards (CnCv3, MKS Gen-L, MiniPCB) and OnStep 5.1v, can you share your results after 2 hours?

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.


Howard Dutton
 

On Tue, Mar 23, 2021 at 05:04 PM, Dave Schwartz wrote:
OnStep gathers about 15 PPS pulses, conditions its timers from that and then that's it.
NOT like that at all, it's continuous.


Dave Schwartz
 

If it is continuous then how can we square that with the pretty extreme clock drift Khalid is getting with PPS (17sec/hr)? Might be interesting to repeat the F303 test with PPS disabled (I think it would be difficult to physically disconnect PPS on that PCB since the other four pins have to remain connected for the NV) and see how it does with only its own crystal. Seems implausible that its such a badly calibrated crystal on the DS3231 because that would show up quickly in the RTC (does the time initialized from the RTC drift that badly while it is off?). I assume this test was indoors with a constant room temperature.

On 2021-03-23 8:17 p.m., Howard Dutton wrote:
On Tue, Mar 23, 2021 at 05:04 PM, Dave Schwartz wrote:

OnStep gathers about 15 PPS pulses, conditions its timers from
that and then that's it.

NOT like that at all, it's continuous.


Mike Ahner
 

On Wed, Mar 24, 2021 at 08:50 AM, Dave Schwartz wrote:
Seems implausible that its such a badly calibrated crystal on the DS3231 because that would show up quickly in the RTC (does the time initialized from the RTC drift that badly while it is off?). I assume this test was indoors with a constant room temperature.
According to the datasheet, the DS3231 IS temperature compensated and classed highly accurate at 3.5ppm at -40c to +85c, well outside most of our operating temperature ranges. On the other hand, PC clocks are considered very inaccurate and are typically adjusted 1-3 or more times per day. Then there is always latency when using ethernet, latency with webpages, latency with operating systems such as Windows or Linux. The NTP time standard corrects for this latency when updating PC clocks.

I wouldn't trust the web browser to show accuracy approaching anything close to a DS3231.
-Mike


Mike Ahner
 

On Wed, Mar 24, 2021 at 10:55 AM, Mike Ahner wrote:
the DS3231 IS temperature compensated and classed highly accurate at 3.5ppm at -40c to +85c
From Wikipedia on Real-time clocks
Typical crystal RTC accuracy specifications are from ±100 to ±20 parts per million (8.6 to 1.7 seconds per day), but temperature-compensated RTC ICs are available accurate to less than 5 parts per million.[11][12] In practical terms, this is good enough to perform celestial navigation, the classic task of a chronometer.


Howard Dutton
 
Edited

On Wed, Mar 24, 2021 at 06:50 AM, Dave Schwartz wrote:
If it is continuous then how can we square that with the pretty extreme clock drift Khalid is getting with PPS (17sec/hr)?
A F303 HAL timer problem?

Here's what my MKS Gen-L v2.0 running the latest OnStep (master) looks like, this is one hour after setting the time from my Laptop/PC.  No PPS...


Dave Schwartz
 

On 2021-03-24 11:55 a.m., Mike Ahner wrote:

I wouldn't trust the web browser to show accuracy approaching anything close to a DS3231.
My PC will.

A few months ago I wanted to start doing occultation timing (haven't had clear skies coincide with a predicted event to do one yet) where I needed precise, GPS-conditioned timestamps on the frames. I had a few spare GPS modules so I hung one off my observatory PC. Its surprisingly difficult to find a free GPS clock synchronization program so I wrote a Python script to parse the time out of valid GPRMC strings as they are received and set the clock through the win32api. Works like a charm.

So I hooked up another module to my laptop here in the office and started the script.

At 1:45 I started Khalid's test on my STM32 BP system with F303 upgrade and DS3231 with PPS.

Here's the GPS doing its thing:

C:\Users\dave\Documents\Python>gpssync.py COM1 300
Setting system time to 2021/03/24 17:49:34 UTC
Setting system time to 2021/03/24 17:54:34 UTC
Setting system time to 2021/03/24 17:59:34 UTC
Setting system time to 2021/03/24 18:04:34 UTC
Setting system time to 2021/03/24 18:09:34 UTC
Setting system time to 2021/03/24 18:14:34 UTC
Setting system time to 2021/03/24 18:19:34 UTC
Setting system time to 2021/03/24 18:24:34 UTC
Setting system time to 2021/03/24 18:29:34 UTC
Setting system time to 2021/03/24 18:34:34 UTC
Setting system time to 2021/03/24 18:39:34 UTC
Setting system time to 2021/03/24 18:44:34 UTC
Setting system time to 2021/03/24 18:49:34 UTC
Setting system time to 2021/03/24 18:54:34 UTC

Checking with time.gov occasionally shows the clock stays less than 0.05s off (usually less than half that).

Now, just after 3:20pm, the status page shows the PC and OnStep time have gotten 1 second apart.

*Site:*
3/24/21 19:22:40 UT (web browser)
3/24/21 19:22:39 UT (02:09:51  LST)

1 second in 5700 is 0.0175% error. Doesn't seem to be much of a drift problem with a PPS-conditioned F303.

I'll update in a few more hours...


Dave Schwartz
 

At over 2 hours, its bouncing around between 1 and 2 seconds difference so the drift is probably around 1.5 seconds.

On 2021-03-24 3:33 p.m., Dave Schwartz wrote:
On 2021-03-24 11:55 a.m., Mike Ahner wrote:

I wouldn't trust the web browser to show accuracy approaching anything close to a DS3231.
My PC will.

A few months ago I wanted to start doing occultation timing (haven't had clear skies coincide with a predicted event to do one yet) where I needed precise, GPS-conditioned timestamps on the frames. I had a few spare GPS modules so I hung one off my observatory PC. Its surprisingly difficult to find a free GPS clock synchronization program so I wrote a Python script to parse the time out of valid GPRMC strings as they are received and set the clock through the win32api. Works like a charm.

So I hooked up another module to my laptop here in the office and started the script.

At 1:45 I started Khalid's test on my STM32 BP system with F303 upgrade and DS3231 with PPS.

Here's the GPS doing its thing:

C:\Users\dave\Documents\Python>gpssync.py COM1 300
Setting system time to 2021/03/24 17:49:34 UTC
Setting system time to 2021/03/24 17:54:34 UTC
Setting system time to 2021/03/24 17:59:34 UTC
Setting system time to 2021/03/24 18:04:34 UTC
Setting system time to 2021/03/24 18:09:34 UTC
Setting system time to 2021/03/24 18:14:34 UTC
Setting system time to 2021/03/24 18:19:34 UTC
Setting system time to 2021/03/24 18:24:34 UTC
Setting system time to 2021/03/24 18:29:34 UTC
Setting system time to 2021/03/24 18:34:34 UTC
Setting system time to 2021/03/24 18:39:34 UTC
Setting system time to 2021/03/24 18:44:34 UTC
Setting system time to 2021/03/24 18:49:34 UTC
Setting system time to 2021/03/24 18:54:34 UTC

Checking with time.gov occasionally shows the clock stays less than 0.05s off (usually less than half that).

Now, just after 3:20pm, the status page shows the PC and OnStep time have gotten 1 second apart.

*Site:*
3/24/21 19:22:40 UT (web browser)
3/24/21 19:22:39 UT (02:09:51  LST)

1 second in 5700 is 0.0175% error. Doesn't seem to be much of a drift problem with a PPS-conditioned F303.

I'll update in a few more hours...





Mike Ahner
 

On Wed, Mar 24, 2021 at 02:52 PM, Dave Schwartz wrote:
At over 2 hours, its bouncing around between 1 and 2 seconds difference so the drift is probably around 1.5 seconds.
Now I'm really curious.

Is the OnStep controller sitting in the just after-boot mode, no tracking? Or have you started tracking at least?

There are many timers involved with OnStep and not all can be the highest priority. I may not express the problem clearly, but I wonder if the time for an ISR to run, (which usually blocks other less important ISRs, Interrupts and other routines from running) is adding to the MCU clock error. In other words, if the clock timer used for real time is delayed by some micro-seconds as other ISRs get priority and run, that delay would begin to add up. I think the PPS only disciplines the oscillator that is driving the MCU, I don't believe it can correct for delays causing missed clock cycles.

I would then also ask the question if the F303 has a little more overhead in handling ISRs and returning. This too would add to the cumulative inaccuracy. 

Maybe you can test by either auto-start tracking or not tracking, depending on which is your current test mode.

-Mike


Dave Schwartz
 

A valid question.

For the current test, its not tracking... I've done nothing except turn it on, set time so its synced with the PC and occasionally bring up the status page. The SHC is running (and doesn't time out) so it is doing its regular poll cycle. Workload is 19 to 24%.

On 2021-03-24 4:33 p.m., Mike Ahner wrote:
On Wed, Mar 24, 2021 at 02:52 PM, Dave Schwartz wrote:

At over 2 hours, its bouncing around between 1 and 2 seconds
difference so the drift is probably around 1.5 seconds.

Now I'm really curious.

Is the OnStep controller sitting in the just after-boot mode, no tracking? Or have you started tracking at least?

There are many timers involved with OnStep and not all can be the highest priority. I may not express the problem clearly, but I wonder if the time for an ISR to run, (which usually blocks other less important ISRs, Interrupts and other routines from running) is adding to the MCU clock error. In other words, if the clock timer used for real time is delayed by some micro-seconds as other ISRs get priority and run, that delay would begin to add up. I think the PPS only disciplines the oscillator that is driving the MCU, I don't believe it can correct for delays causing missed clock cycles.

I would then also ask the question if the F303 has a little more overhead in handling ISRs and returning. This too would add to the cumulative inaccuracy.

Maybe you can test by either auto-start tracking or not tracking, depending on which is your current test mode.

-Mike


Khalid Baheyeldin
 

On Wed, Mar 24, 2021 at 09:50 AM, Dave Schwartz wrote:
I assume this test was indoors with a constant room temperature.
Yes, indoors, and yes, 21C.


Khalid Baheyeldin
 

On Wed, Mar 24, 2021 at 04:58 PM, Dave Schwartz wrote:
For the current test, its not tracking... I've done nothing except turn it on, set time so its synced with the PC and occasionally bring up the status page.
Same test in my case: set date and time, and not tracking.

Can't understand why the discrepancy from my F303CC to Dave's.
I am using OnStep 5.1v (latest master).

I do have a drift script (part of my OnStep-Python project) that will measure and report drift in coordinates, as well as time from controller vs. time from PC.

I will run it later today and see what it reports.


Dave Schwartz
 

I have OnStep 5.1u loaded.

At the 4 hour point, the PC clock is still -0.050s from NIST. Difference between OnStep time on Status page bouncing around between 4 and 5 seconds (mostly 4) below web browser time so call it about 4.25s which comes out to an accuracy of 0.0295%.

Have now resynchronized and turned on tracking. Workload between 19 and 25% with most readings at 22%.

More to come later...

On 2021-03-24 5:29 p.m., Khalid Baheyeldin wrote:
On Wed, Mar 24, 2021 at 04:58 PM, Dave Schwartz wrote:

For the current test, its not tracking... I've done nothing except
turn it on, set time so its synced with the PC and occasionally
bring up the status page.

Same test in my case: set date and time, and not tracking.

Can't understand why the discrepancy from my F303CC to Dave's.
I am using OnStep 5.1v (latest master).

I do have a drift script <https://github.com/kbahey/onstep-python/blob/master/examples/drift_test.py> (part of my OnStep-Python project) that will measure and report drift in coordinates, as well as time from controller vs. time from PC.

I will run it later today and see what it reports.


Lloyd Simons
 

This thread was interesting so I thought I would see if my new S6 has drift as well. I am using OnStep version 4.23o and testing indoors with tracking off (temp 17.8 °C). I connected to the ASCOM driver in NINA to set the time. The net time and system time (actively controlled via NTP) stay in sync (system time begins to drift a bit then resyncs every 6 seconds or so). One thing to note is that on connection OnStep time is about 1 second behind system time. After 1h, it is about 2 seconds ahead. After 2h, it is about 6.5 seconds ahead. I don't see this being an issue for me since I guide, but it is interesting.


Dave Schwartz
 

I'll test my S6 tomorrow (GPS w/PPS, no RTC).

On 2021-03-24 6:30 p.m., Lloyd Simons wrote:
This thread was interesting so I thought I would see if my new S6 has drift as well. I am using OnStep version 4.23o and testing indoors with tracking off (temp 17.8 °C). I connected to the ASCOM driver in NINA to set the time. The net time and system time (actively controlled via NTP) stay in sync (system time begins to drift a bit then resyncs every 6 seconds or so). One thing to note is that on connection OnStep time is about 1 second behind system time. After 1h, it is about 2 seconds ahead. After 2h, it is about 6.5 seconds ahead. I don't see this being an issue for me since I guide, but it is interesting.


Khalid Baheyeldin
 

On Wed, Mar 24, 2021 at 06:30 PM, Lloyd Simons wrote:
The net time and system time (actively controlled via NTP) stay in sync (system time begins to drift a bit then resyncs every 6 seconds or so). One thing to note is that on connection OnStep time is about 1 second behind system time.
That is expected, since sometimes the update of the controller's time takes a few tens or hundreds of milliseconds, and if it straddles a second, then you get off by one situations.

After 1h, it is about 2 seconds ahead. After 2h, it is about 6.5 seconds ahead.
Let us know what the situation is after 2 full hours.

I don't see this being an issue for me since I guide, but it is interesting.
Exactly my thought too. I did not see any drift in stars, and guiding was in both directions on both axes.

But I would love to know the reason for this: initially I thought it is the lack of PPS on my S6 (no GPS), but the Blue Pill controller, which has PPS from the RTC, shows similar drift ...

Anyone with MiniPCB and MaxPCB? Can you pitch in with your observations from the web interface over 2 hours?


Mike Ahner
 

On Wed, Mar 24, 2021 at 05:52 PM, Khalid Baheyeldin wrote:
But I would love to know the reason for this: initially I thought it is the lack of PPS on my S6 (no GPS), but the Blue Pill controller, which has PPS from the RTC, shows similar drift ...
Another interesting test would be to turn off the PPS signal in Config.h and see if there is any significant difference just using the STM32 onboard crystal.

According to the PINMAP, the PPS signal is measured and then used to calculate corrections to the Sidereal clock frequency.

Sorry if it's mentioned but has this test been run on just an STM32F103 Blue Pill?
If I get time later, I'll test on mine.


Howard Dutton
 
Edited

On Wed, Mar 24, 2021 at 03:52 PM, Khalid Baheyeldin wrote:
Anyone with MiniPCB and MaxPCB?
Done this test many times.


Khalid Baheyeldin
 

Here is the S6 again.
No tracking. No GPS. No PPS.

18:18
3/24/21 22:18:41 UT (web browser)
3/24/21 23:18:41 UT (06:06:24  LST)

19:26
3/24/21 23:26:24 UT (web browser)
3/25/21 00:26:29 UT (07:14:23  LST)

Here is the drift test from OnStep Python, while pointing to Denebola and tracking.

The RAdlta (Delta) column shows a consistent 152 of drift per 10 seconds, and it lengthens to 154 after 10 minutes.

Time            OnStep Time   Sidereal      St  RA            DE        Equ                  RAdlta RA"/min RA"Max DE"/min DE"Max
19:34:38.920726 19:34:44.9485 07:22:40.2400 N/A 11:51:18.1341 +14*27:18 177.799753,14.477587   0.00   0.00   0.00   0.00   0.00
19:34:49.007491 19:34:55.0509 07:22:50.3700 N/A 11:51:28.2641 +14*27:18 177.841920,14.477587   0.00 910.08 151.68   0.00   0.00
19:34:59.116572 19:35:05.1732 07:23:00.5200 N/A 11:51:38.4041 +14*27:18 177.884253,14.477587 152.28 911.87 303.96   0.00   0.00
19:35:09.208720 19:35:15.2755 07:23:10.6600 N/A 11:51:48.5541 +14*27:18 177.926420,14.477587 151.68 911.27 455.64   0.00   0.00
19:35:19.303616 19:35:25.3878 07:23:20.7900 N/A 11:51:58.6841 +14*27:18 177.968670,14.477587 151.98 911.42 607.62   0.00   0.00
19:35:29.405889 19:35:35.5001 07:23:30.9300 N/A 11:52:08.8241 +14*27:18 178.010920,14.477587 151.98 911.51 759.59   0.00   0.00
19:35:39.503982 19:35:45.6124 07:23:41.0700 N/A 11:52:18.9641 +14*27:18 178.053170,14.477587 151.98 911.57 911.57   0.00   0.00
19:35:49.613708 19:35:55.7347 07:23:51.2200 N/A 11:52:29.1241 +14*27:18 178.095503,14.477587 152.28 911.87 1063.85   0.00   0.00
19:35:59.722349 19:36:05.8570 07:24:01.3700 N/A 11:52:39.2641 +14*27:18 178.137795,14.477587 152.13 911.98 1215.98   0.00   0.00
19:36:09.813224 19:36:15.9593 07:24:11.5100 N/A 11:52:49.4041 +14*27:18 178.180003,14.477587 151.83 911.87 1367.81   0.00   0.00
19:36:19.905142 19:36:26.0717 07:24:21.6400 N/A 11:52:59.5341 +14*27:18 178.222253,14.477587 151.98 911.87 1519.78   0.00   0.00
19:36:29.988201 19:36:36.1640 07:24:31.7600 N/A 11:53:09.6641 +14*27:18 178.264420,14.477587 151.68 903.49 1671.46   0.00   0.00
19:36:40.087156 19:36:46.2763 07:24:41.9000 N/A 11:53:19.7941 +14*27:18 178.306670,14.477587 151.98 904.19 1823.44   0.00   0.00
19:36:50.174779 19:36:56.3787 07:24:52.0400 N/A 11:53:29.9241 +14*27:18 178.348878,14.477587 151.83 904.70 1975.27   0.00   0.00
19:37:00.272288 19:37:06.4910 07:25:02.1700 N/A 11:53:40.0641 +14*27:18 178.391128,14.477587 151.98 905.21 2127.25   0.00   0.00
19:37:10.363724 19:37:16.5933 07:25:12.3000 N/A 11:53:50.1941 +14*27:18 178.433295,14.477587 151.68 905.53 2278.93   0.00   0.00
19:37:20.503028 19:37:26.7455 07:25:22.4900 N/A 11:54:00.3441 +14*27:18 178.475753,14.477587 152.73 906.21 2431.65   0.00   0.00
19:37:30.720707 19:37:36.9775 07:25:32.7500 N/A 11:54:10.6441 +14*27:18 178.518503,14.477587 153.78 907.17 2585.43   0.00   0.00
19:37:40.844514 19:37:47.1198 07:25:42.9100 N/A 11:54:20.7941 +14*27:18 178.560795,14.477587 152.13 907.48 2737.56   0.00   0.00
19:37:50.978120 19:37:57.2620 07:25:53.0800 N/A 11:54:30.9841 +14*27:18 178.603253,14.477587 152.73 903.21 2890.29   0.00   0.00
19:38:01.112811 19:38:07.4142 07:26:03.2600 N/A 11:54:41.1541 +14*27:18 178.645628,14.477587 152.43 903.78 3042.72   0.00   0.00
19:38:11.258261 19:38:17.5664 07:26:13.4500 N/A 11:54:51.3341 +14*27:18 178.688087,14.477587 152.73 904.37 3195.45   0.00   0.00
19:38:21.391058 19:38:27.7186 07:26:23.6200 N/A 11:55:01.5141 +14*27:18 178.730503,14.477587 152.58 904.87 3348.02   0.00   0.00
19:38:31.525829 19:38:37.8608 07:26:33.8000 N/A 11:55:11.6941 +14*27:18 178.772878,14.477587 152.43 905.29 3500.45   0.00   0.00
19:38:41.663830 19:38:48.0230 07:26:43.9800 N/A 11:55:21.8741 +14*27:18 178.815295,14.477587 152.58 905.71 3653.03   0.00   0.00
19:38:51.813208 19:38:58.1852 07:26:54.1700 N/A 11:55:32.0541 +14*27:18 178.857753,14.477587 152.73 906.13 3805.76   0.00   0.00
19:39:01.946167 19:39:08.3274 07:27:04.3500 N/A 11:55:42.2341 +14*27:18 178.900170,14.477587 152.58 903.04 3958.33   0.00   0.00
19:39:12.126361 19:39:18.5195 07:27:14.5700 N/A 11:55:52.4441 +14*27:18 178.942712,14.477587 153.03 903.60 4111.36   0.00   0.00
19:39:22.316994 19:39:28.7216 07:27:24.8000 N/A 11:56:02.6941 +14*27:18 178.985378,14.477587 153.47 904.21 4264.84   0.00   0.00
19:39:32.448338 19:39:38.8738 07:27:34.9800 N/A 11:56:12.8741 +14*27:18 179.027753,14.477587 152.43 904.56 4417.27   0.00   0.00
19:39:42.728747 19:39:49.1556 07:27:45.3000 N/A 11:56:23.0941 +14*27:18 179.070628,14.477587 154.23 905.25 4571.49   0.00   0.00

This was not the case when we initially ported the S6, also with no GPS or PPS (see this thread).

So looks like a timer got messed up along the way.