2000-03-29 16:38:44 +04:00
|
|
|
<html><head><title>
|
|
|
|
|
Pulse-per-second (PPS) Signal Interfacing
|
|
|
|
|
</title></head><body><h3>
|
|
|
|
|
Pulse-per-second (PPS) Signal Interfacing
|
|
|
|
|
</h3><hr>
|
|
|
|
|
|
|
|
|
|
<P>Some radio clocks and related timekeeping gear have a
|
|
|
|
|
pulse-per-second (PPS) signal that can be used to discipline the local
|
|
|
|
|
clock oscillator to a high degree of precision, typically to the order
|
|
|
|
|
less than 20 <font face=Symbol>m</font>s in time and 0.01 PPM in
|
|
|
|
|
frequency. The PPS signal can be connected in either of two ways: via
|
|
|
|
|
the data leads of a serial port or via the modem control leads. Either
|
|
|
|
|
way requires conversion of the PPS signal, usually at TTL levels, to
|
|
|
|
|
RS232 levels, which can be done using a circuit such as described in the
|
|
|
|
|
<A HREF=gadget.htm>Gadget Box PPS Level Converter and CHU Modem</A>
|
|
|
|
|
page.
|
|
|
|
|
|
|
|
|
|
<P>The data leads interface requires regenerating the PPS pulse and
|
|
|
|
|
converting to RS232 signal levels, so that the pulse looks like a
|
|
|
|
|
legitimate ASCII character to a serial port. The <TT>tty_clk</TT> line
|
|
|
|
|
discipline/streams module inserts a timestamp following this character
|
|
|
|
|
in the input data stream. The <A HREF=driver22.htm>PPS Clock
|
|
|
|
|
Discipline</A> driver uses this timestamp to determine the time of
|
|
|
|
|
arrival of the PPS pulse to within 26 us at 38.4 kbps while eliminating
|
|
|
|
|
error due to operating system queues and service times.
|
|
|
|
|
|
|
|
|
|
<P>The modem control leads interface requires converting to RS232 levels
|
|
|
|
|
and connecting to the data carrier detect (DCD) lead of a serial port.
|
|
|
|
|
The <TT>ppsclock</TT> and <TT>ppsapi</TT> streams modules capture a
|
|
|
|
|
timestamp upon transition of the DCD signal. Note that the
|
|
|
|
|
<TT>ppsclock</TT> module functionality has been subsumed by the new
|
|
|
|
|
<TT>ppsapi</TT> interface specification, which is supported by the NTP
|
|
|
|
|
daemon. As the latter is expected to become an IETF cross-platform
|
|
|
|
|
standard, it should be used in new configurations. The PPS Clock
|
|
|
|
|
Discipline driver reads the latest timestamp with a designated system
|
|
|
|
|
call or interface routine to determine the time of arrival of the PPS
|
|
|
|
|
pulse to within a few microseconds. Alternatively, if provisions have
|
|
|
|
|
been made in the kernel for PPS signals, the signal is captured directly
|
|
|
|
|
by the kernel serial driver without using the PPS driver.
|
|
|
|
|
|
|
|
|
|
<P>The <TT>tty_clk</TT> module is included in the NTP software
|
|
|
|
|
distribution, while the <A
|
|
|
|
|
HREF=http://www.eecis.udel.edu/~mills/ntp/ntp/ppsclock.tar.Z><TT>
|
|
|
|
|
ppsclock</TT></A> module can be obtained via the web at that link or by
|
|
|
|
|
anonymous FTP from ftp.udel.edu in the <TT>pub/ntp</TT> directory. Both
|
|
|
|
|
the <TT>tty_clk</TT> and <TT>ppsclock</TT> modules are described in the
|
|
|
|
|
<A HREF=ldisc.htm>Line Disciplines and Streams Drivers</A> page.
|
|
|
|
|
Directions for building the modules themselves are in the
|
|
|
|
|
<TT>./kernel</TT> directory. Directions on how to configure
|
|
|
|
|
<TT>ntpd</TT> to operate with these modules is described in <A
|
|
|
|
|
HREF=build.htm>Building and Installing the Distribution </A>page.
|
|
|
|
|
|
|
|
|
|
<P>The PPS driver is operates in conjunction with another reference
|
|
|
|
|
clock driver that produces the PPS pulse, as described in the <A
|
|
|
|
|
HREF=prefer.htm>Mitigation Rules and the <TT>prefer</TT> Keyword
|
|
|
|
|
</A>page. One of the drivers described in the <A
|
|
|
|
|
HREF=refclock.htm>Reference Clock Drivers</A> page furnishes
|
|
|
|
|
the coarse timecode used to disambiguate the seconds numbering of the
|
|
|
|
|
PPS pulse itself. The NTP daemon mitigates between the radio clock
|
|
|
|
|
driver and <TT>PPS</TT> driver as described in that page in order to
|
|
|
|
|
provide the most accurate time, while respecting the various types of
|
|
|
|
|
equipment failures that could happen.
|
|
|
|
|
|
|
|
|
|
<P>For the utmost time quality, some Unix system kernels support a PPS
|
|
|
|
|
signal directly, as described in the <A HREF=kern.htm>A Kernel Model
|
|
|
|
|
for Precision Timekeeping </A>page. Specifically, the ppsclock module
|
|
|
|
|
can be used to interface the PPS signal directly to the kernel for use
|
|
|
|
|
as discipline sources for both time and frequency. These sources can be
|
|
|
|
|
separately enabled and monitored using the <TT>ntp_adjtime()</TT> system
|
|
|
|
|
call described in that page and the <TT>/usr/include/sys/timex.h</TT>
|
|
|
|
|
header file. The presence of these kernel provisions is automatically
|
|
|
|
|
detected and supporting code compiled.
|
|
|
|
|
|
|
|
|
|
<P>In some configurations may have multiple radio clocks, each with PPS
|
|
|
|
|
outputs, as well as a kernel provisions for the PPS signal. In order to
|
|
|
|
|
provide the highest degree of redundancy and survivability, the kernel
|
|
|
|
|
PPS discipline, <TT>tty_clk</TT> module, <TT>ppsclock</TT> module and
|
|
|
|
|
kernel modifications may all be in use at the same time, each backing up
|
|
|
|
|
the other. The sometimes complicated mitigation rules are described in
|
|
|
|
|
the Mitigation Rules and the <TT>prefer</TT> Keyword page.
|
|
|
|
|
|
2000-04-22 20:46:49 +04:00
|
|
|
<hr><a href=index.htm>Home</a><address><a
|
2000-03-29 16:38:44 +04:00
|
|
|
href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a>
|
|
|
|
|
</address></a></body></html>
|
