[ntp:questions] ESR looking for good GPS clocks

Terje Mathisen "terje.mathisen at tmsw.no" at ntp.org
Sat Mar 3 22:49:56 UTC 2012

unruh wrote:
> On 2012-03-03, Terje Mathisen<"terje.mathisen at tmsw.no">  wrote:
>> The idea is of course to NOT use the USB-RS232 emulation driver, instead
>> (or on top of) you want a private command to poll for the latest PPS
>> timestamp.
> The PPS does not send a timestamp. The PPS is such that the rising edge
> of the signal is exactly .000000000 seconds. That is all. Your computer

As you well know, this is not true:

All "timing gps" units try to send the PPS as close to 0.0000... as they 
can, but they also send the sawtooth correction in order to signal 
exactly how wrong the latest PPS was.

Even though this is normally within 100 ns, there is absolutely nothing 
that stops you (or me) from using exactly the same kind of setup to 
instead signal:

At the time when you sent the last poll, the UTC/GPS time was exactly 
2012-03-03 23:45:57.1234567 s.

Combine this with having the program measuring the time between sending 
the poll and receiving the response, and you have both a timestamp and a 
quality measure.

There is of course no physical (or virtual) PPS signal going over the 
USB protocol in this setup.

> has to then timestamp that rising edge. The serial ->usb takes that
> pulse, encodes it as a usb command, and sends that special command along
> the usb line as a normal usb packet. It has not timestamp. It is simply
> a message "the dcd line has gone high". The accuracy might be ms. I
> doubt but do not know if you can get 100us out of it. Any less I doubt,
> but do not know.

You do know how the USB protocol stack works, right?

>> The reply you get from this command can then contain the actual time at
>> the point of polling, instead of just what it was at the latest PPS.
> What command? Sending a command to the gps unit. Horribly slow. It
> spends most of its time working at getting the position and time
> accurately and puts off sending out commands to low level ( except that
> PPS pulse).

ESR was asking for a purpose-built USB GPS unit, it would obviously have 
some kind of embedded cpu to handle the USB stack and the differential 
timing between the gps chipset sending a PPS and host cpu sending a USB 


- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

More information about the questions mailing list