[ntp:questions] ESR looking for good GPS clocks
unruh at invalid.ca
Sun Mar 4 04:09:10 UTC 2012
On 2012-03-03, Terje Mathisen <"terje.mathisen at tmsw.no"> wrote:
> 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
>> 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.
And this would help how? Between the time you requested the time, and
the unit received the request, your usb card would have hasd to decode
the request, frame it into a serial usb signal, waited for the usb bus
to clear, sent it to the device, the device having to then wait to be
ready to decode the usb signal, decodeing it, and finally timestamping
it. At which point an eternity would have gone by. The timestamp would
be useless as far as any timing accuracy was concerned.
Plus You or I do not have the ability to reprogram the gps to timestamp
the usb request, or send it out. And for the manufacturer to do so would
be silly because of the huge and variable delays in the the above chain.
The sawtooth correction is to get close to ns accuracy. What this is
talking about is ms accuracy. a million times worse. (well maybe only a
few thousand times worse, but you get what I mean)
> 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
More information about the questions