System.Time.Clock Design Issues
gwright at comcast.net
Sun Feb 6 11:21:28 EST 2005
On Feb 5, 2005, at 4:33 AM, Keean Schupke wrote:
> Aaron Denney wrote:
>> Right. The NTP source code has plenty of other things that can by
>> synced off of, including many fairly common GPS receivers, and radio
> Does this mean I can sync my system time to TAI using a GPS
> reciever? Sounds like how it should be done...
Many, but not all, GPS clocks can deliver GPS time (i.e., the time based
on the number of seconds since the GPS epoch 1980 January 6 00:00 UTC
converted to a calendar time using days of 86400 seconds and the
leap year rule).
TAI is ahead of GPS time by 19 seconds, and as GPS time does not have
leap seconds, TAI = GPS + 19 s.
Raw GPS time (the number of seconds since the GPS epoch)
is broadcast in a complicated form in the satellites' navigation
along with the current number of UTC leap seconds since the GPS epoch.
From the raw GPS time and the number of leap seconds UTC can be
The gory details of the GPS navigation messages are available in
the signal specification document,
The GPS clock in my office, an old TrueTime XL-AK, can be set to
output GPS time instead of UTC. (Unfortunately, it can't be forced to
output the number of leap seconds directly, you have to calculate
leap seconds from the difference between GPS and UTC times.)
I have worked with other clocks, in particular an Odetics SatSync unit
that would only provide UTC. That clock would not provide low level
access to the fields of the navigation message, so we just had to
maintain a table of leap seconds manually.
> Libraries mailing list
> Libraries at haskell.org
More information about the Libraries