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