HI
> On Mar 21, 2017, at 4:52 PM, Trent Piepho <[email protected]> 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 -- [email protected] > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
