System.Time.Clock Design Issues
Gregory Wright
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
>> clocks.
>>
>>
> 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
standard
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
message,
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
calculated.
The gory details of the GPS navigation messages are available in
the signal specification document,
http://www.navcen.uscg.gov/pubs/gps/sigspec/gpssps1.pdf
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.
Best Wishes,
Greg
> Keean.
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
More information about the Libraries
mailing list