Yo Martin! On Fri, 8 Dec 2017 10:20:59 +0100 Martin Burnicki <martin.burni...@meinberg.de> wrote:
> again sorry for the late reply. I've been mostly offline for a few > weeks now. Compounded by my being confined to bed for a bit, then taking forever to get caught back up. Nothing serious on my end, just the same grunge going around my city. > >> I'm mostly working with GPS PCI cards, where the kernel driver > >> reads a high resolution, accurate time stamp from the PCI card, > >> plus an associated system time stamp, plus some TSC counts. The > >> calling application can check the TSC values to see if reading the > >> time stamp pairs has taken longer than "usual", and repeat the > >> call, or feed both time stamps into SHM. > > > > Coll? Anyhting cheap I could afford? > > It's the Meinberg PCI GPS card. Not cheap, unfortunately. Well, you're Meinberg, just send me one. :-) > > We assume it is zero. Not valid, but what else can we do? PPS is > > already way down in the noise. > > I know there's nothing you can do to determine the IRQ latency on a > standard PC. Well, with a Meinberg budget, there are things you can do. Get a PCIe GPIO card. Tweak your kernel, or ntpd, to move a pin on the GPIO on detecting the PPS. I see the Gateworks gw16113 claims 12 nS output rise time, no idea of total latency... Get one of these, measure time down to 100 pico second range: http://tapr.org/kits_ticc Have it measure the time from the PPS in to the GPIO out. That give you an upper bound on PPS in latency. Take a WAG how much overhead is in the GPIO output and refine that upper bound a bit. > However, we should be more specific here with the terms we use. OK. > The receiver needs to know the ephemeris data set (as well as the > satellite's clock correction parameters) for each satellite to be able > to compute the satellite's exact position in space at a given time, > which is required for exact positioning and timing. Each satellite > sends only its own ephemeris and clock correction parameters. Yup. Plus the entire almanac. > > The almanac may take 12 to 24 mins to download, but the almanac is > > just for predicting future GPS sat locations. > > Yes. The almanac can be used to predict which satellites should be > visible at a given time and a given receiver position. However, > almanac parameters yield only a limited accuracy when computing a > satellite's position in space, so the ephemeris parameters are also > required for a high accurate fix. Yup. > Basically the almanac would not even be required for high precision > navigation if the ephemeris data is available. Navigation works > perfectly fine based on GPS time only. Yes, but. Without an almanac, initial GPS sat selection, and then ephemeris download, can take a while. > If you are going to use the GPS receiver for exact UTC timing, > however, you need to be sure that the GPS UTC correction parameters > are also available in the receiver. The UTC correction parameter set > is a single data set sent by every satellite, similar to the almanac > data sets, some health data, etc. This is indeed sent only once every > ~12 minutes. A non-issue, except on startup. > The latter is usually in the range of a few nanoseconds, so indeed it > is below the noise level of IRQ latencies. Yeah, but well in range of time-nuttery. Like the TICC mentioned above. > > I'm sure there a few small cases where my simplification is not > > right, but I've not seen PPS shift from the almanac. > > The whole number of seconds of the UTC offset is currently 18, so if > the *UTC parameter set* is not available in the receiver the GPS > receiver is unable to convert UTC time to UTC. If the receiver anyway > claims to be fully synchronized the we have the problem that > gpsd/ntpd set the system time wrong by 18 seconds. Yup, we do see that often on cheaper GPS on startup. > Eventually you remember an incident on 2016-01-26 where the UTC time > provided by most GPS receivers was off by about 13 microseconds, which > could also be seen by PPS slopes handled via an IRQ. Yeah, nothing we can do when the GPS operators mess up.... RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin
pgp9EhfFGDKdx.pgp
Description: OpenPGP digital signature
_______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions