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

[Trent Piepho]

Thanks to all who responded.  Yes, I know PPS is the way get a more
accurate timestamps.  That is the plan, but it takes more time to write
FPGA programs.  The surprise is not that there is considerable jitter on
the NMEA output, but rather why does the jitter have patterns in it?

It seems significant enough that someone who had used NMEA for time
would have noticed it before.  Unless it is somehow unique to me, but
how would that be?

On Tue, 2017-03-21 at 16:43 -0700, Kiwi Geoff wrote:
> For example, here is a (24 hour) graph from my Garmin 18x (firmware
> v3.6) where a plot (thanks to Hal) shows the start time of the NMEA
> sentence from the time of the GPS 1PPS edge.

I've tried to duplicate that graph to some extent, plotting NMEA
sentence offset from system clock.  Attached and also at
https://goo.gl/photos/TBEg27SRqY2EQW3HA

In this plot I've taken the offset from the system clock, fitted it to a
simple f(x)=a+b*x model, then plotted the residuals.  I.e., I've taken
out a constant clock drift (of 5.7 ppm).  While interesting, there
doesn't appear to be any pattern that synced to every four hours start
at 00 UTC time.  It's not a lot different than your plot from the 18x.

However, if I plot not the raw offsets, but the mean and variance over
an interval, we see there is a clear four hour pattern, and it's synced!

https://goo.gl/photos/JZhBbFKFzkBAykti6

Why would a GPS module produce jitter with a pattern like this?


On Tue, 2017-03-20 at 15:19 -0700, Chris Albertson wrote:
> If you have an FPGA available then you could significantly improve
> system time keeping.   Currently the PPS interrupts the CPU to
> snapshot internal counter.   Unpredictable interrupt latency lifts NTP
> timekeeping to about 1 or 2 microseconds but is the counter snap
> shooting could be moved out to FPGA hardware there would be no unknown
> latency and you could get NTP to break a "magic" 1uS barrier.   I've

My initial idea for the PPS hardware would be to start a counter in the
FPGA, there is a good 100 MHz clock for this, on the edge of the PPS
signal.  The irq handler can use the value of the counter to subtract
out most of the software interrupt latency.  Most, since the Linux PPS
framework wants to create the system clock component of the PPS
timestamp pair _after_ the hardware part is generated.  There is some
delay and jitter in how long it takes the CPU to create the system
timestamp after I have created the latency compensated PPS timestamp.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gpsoffset.png
Type: image/png
Size: 78440 bytes
Desc: gpsoffset.png
URL: <http://febo.com/pipermail/time-nuts_lists.febo.com/attachments/20170321/53bdf2bd/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jitter3.png
Type: image/png
Size: 60075 bytes
Desc: jitter3.png
URL: <http://febo.com/pipermail/time-nuts_lists.febo.com/attachments/20170321/53bdf2bd/attachment-0001.png>