Hi
NMEA sentences are not the best thing to use for timing. If you *do* decide to use them, configure the receiver so that one and only one sentence comes out. Any time you have more than one, you run the risk of collision in the serial buffer on the part. Next thing to do is to pick the shortest useful sentence you can find. In some cases you only have one option. Next up is to be sure that your PC is set up so that there is minimal lag in serial processing. That may not be as simple as you might think. All modern OS’s head off to do “interesting things” from time to time. The usual approach is to kill just about anything that *might* create an issue. Once you have all that, you start pruning the outliers and fitting to the center of the data. Since you don’t have a super duper clock on your motherboard, you are fitting both the randomness of the clock and the GPS. The answer is to go slow and look at data over a lot of samples. The other answer to all this is to use a GPS with a PPS out. Feed that into some sort of capture process and go from there. The result is likely to improve things by at least a couple orders of magnitude. Bob > On Mar 20, 2017, at 5:00 PM, Trent Piepho <tpie...@kymetacorp.com> wrote: > > 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. > <plot1.png>_______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
