[time-nuts] Four hour cycle in GPS NMEA jitter

[Trent Piepho]

Hello time nuts,

I'm working on a custom embedded Linux device, with a custom inertial reference unit, which contains a GPS module.   The module is a Telit JN3, which is based on the SiRFSTAR IV I believe.  I'd like to use the GPS to sync the Linux system clock.  Eventually I'd like to use the PPS signal, which is routed to a FPGA that's part of the CPU, to implement a custom PPS hardware module that I can write a kernel driver for and use the Linux hardpps system.   And maybe make that feedback to the CPU's main clock source, since the FPGA also controls that and could create a PLL between the TCXO that serves as the master clock signal and the CPU's source clock.

But first things first.  I'm just grabbing the time from NMEA sentences.  And there's quite a bit of jitter there!  Clearly using the first sentence output by the GPS is critical.  I've tried to account for any time delays in the software.  I think it's the GPS module that is creating the largest source of jitter.  It appears to go in four hour cycles, peaking at 0:00Z, 4:00Z, 8:00Z, etc.

Does this sound like something that one would expect with the NMEA output of a non-timing GPS?  Is it related to satellite orbits?  Or perhaps is has something to do with the design of the SiRFStar IV?

I'll attach a graph of what I'm seeing.  If the attachment doesn't come though it's viewable at https://goo.gl/photos/JtYfJCpRSZb3hCnM8.

Methodology for the graph:
System clock is left free running and not disciplined, after an initial one time set based on the GPS time.
On each NMEA GGA sentence, sent at 1 Hz, the system clock's offset from the NMEA timestamp is measured.
Each minute, the mean, std.dev, min and max are found for the last 60 offset samples.  This is plotted on the graph.
Any outlier samples, defined as more than 3 sigma from the previous mean, are also plotted.
Concurrently, the chrony NTP daemon is running and monitoring the IT dept's NTP server, but NOT being used to set the local system clock.
Once a minute, the system clock's offset to chrony's idea of the NTP server's clock is also measured.  Chrony is using an algorithm based on median filtering to get its idea of the NTP server's clock.
The NTP server is just a windows domain controller synced to the internet NTP pool and far from a precision source.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: plot1.png
Type: image/png
Size: 56505 bytes
Desc: plot1.png
URL: <http://febo.com/pipermail/time-nuts_lists.febo.com/attachments/20170320/9eb1009a/attachment.png>