[ntp:questions] ESR looking for good GPS clocks

Dennis Ferguson dennis.c.ferguson at gmail.com
Tue Mar 6 18:21:50 UTC 2012


On 5 Mar, 2012, at 18:33 , Terje Mathisen wrote:

> Chris Albertson wrote:
>> How to measure?   You need to modify the interrupt handler to raise a
>> pin on a (say) parallel port. then measure the time from PPS to that
>> pin going high with a time interval counter.  Such counters are cheap
>> now on eBay.
> 
> What I'm asking for is GPS unit with such an interval timer embedded on it, said counter to be restarted on every PPS signal.
> 
> The query protocol then becomes, as seen from the host:
> 
> while (1) {
>  before = gethirestime();
>  gps_time = poll_gps();
>  after = gethirestime();
>  if (after - before < MAX_LATENCY)
>    use_timestamp(after, gps_time);
>  sleep(1);
> }
> 
> I.e. polling the GPS (at any time) returns the current time in NTP 32:32 format directly. There is no need to ever interrupt anything with a clock source you can poll at any time.

Note that the problem with the above is that you are asking poll_gps()
to complete a transaction which is going to require more than 100 bits
to be exchanged on a full-speed USB interface (I've not seen a GPS chipset
that provides higher speed USB than that) which only delivers
12 bits per microsecond.  (after - before) is nearly certain to
exceed 10 microseconds, so you are going to get no where near
sub-microsecond timing unless you have some idea of where in the
(after - before) interval the gps_time timestamp was actually acquired.
More than this, the nature of the transaction is such that the gps_time
timestamp is much more likely to be acquired earlier in the (after - before)
interval rather than later, so using the `after' timestamp as a match probably
maximizes the error.  The best arrangement is to have the GPS device
acquire the timestamp just as early in the transaction as it can (ideally
by acquiring a timestamp speculatively when it sees the first bit of
any incoming transaction), use the `before' timestamp for comparison
and forget about 'after'.

The two timestamps will still allow you to do error filtering, you just
need to acquire more samples and compare them to each other.  That is,
any additional delays which occur will cause the difference

    gps_time - before

to increase, never decrease, so if you take multiple samples the best
of them will be the ones with the relatively smallest (i.e. most negative)
values of that difference.  Figuring out which samples are the best is
more complicated if you also need to assume there might be a significant
frequency offset between the GPS clock and the host clock, but even
this can be handled with a least median of squares filter if it can
be assumed that less than half the samples suffered a significant
additional delay.  You needn't limit the sample rate to once per second,
either, if more frequent sampling helps.

Dennis Ferguson


More information about the questions mailing list