[18055] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: Interesting stratum 1 NTP clock

daemon@ATHENA.MIT.EDU (Robert E. Seastrom)
Thu Jun 25 16:28:02 1998

Date: Thu, 25 Jun 1998 16:21:11 -0400 (EDT)
From: "Robert E. Seastrom" <rs@bifrost.seastrom.com>
To: pozar@lns.com
CC: scharf@vix.com, dirk@power.net, nanog@merit.edu
In-reply-to: <199806242025.NAA07001@kumr.lns.com> (message from Tim Pozar on
	Wed, 24 Jun 1998 13:25:28 -0700 (PDT))


   From: Tim Pozar <pozar@lns.com>

   > Would a GPS hooked to the serial port of a Linux box do the same?

   No.  You need to dectect the event of the second. Some OEM GPS boxes will
   have another pin that will go low/high when this event occurs.

In places where I've seen this done, that pin usually ended up tied to
DCD.  The Cisco appears to permit this to be on { RI, DSR, DTR, CTS,
RTS, DCD } and also support an "inverted" signal, which I take to mean
high->low transition is PPS, not low->high.  It is noteworthy that
certain manufacturers (Rockwell and possibly Trimble come immediately
to mind) do not synchronize the PPS pulse to the top of the second as
standardized by USNO (and indirectly BIH) but rather just give you one
pulse per second starting at an arbitrary (but accurately expressed in
the NMEA sentence!) point in the second.

   Also, beware that currently GPS time is 12 seconds fast from UTC.

Not if you have a "good" GPS that picks up that data in the ephemeris
and corrects automatically.  Almost all of them will do this now.
Your average end-user has no interest in the fact that GPS has no
concept of "leap seconds" to bring itself into compliance with
international standard time, and thus should not have to compensate
for it.

                                        ---Rob



home help back first fref pref prev next nref lref last post