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

[Bob Camp]

HI


> On Mar 21, 2017, at 4:52 PM, Trent Piepho <tpiepho at kymetacorp.com> wrote:
> 
> 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?

The simple answer is that we *do* see it and that’s why we use PPS and not NMEA. 
Arrival times on NMEA sentences varying over a 100 ms region is not at 
all unusual. Getting them out “exactly on time” is not a priority compared to the
other tasks overworked CPU in the module needs to perform. 

Bob


> 
> 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.
> <gpsoffset.png><jitter3.png>_______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.