Contents of this page are obsolete. This page is preserved and stored at this URL just from historical viewpoint. Original URL was http://www.mm.media.kyoto-u.ac.jp/members/kameda/...
Please visit www.kameda-lab.org for recent information. (2002/12/06, kameda@ieee.org)

Pulse-per-second (PPS) Signal Interfacing


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 50 us in time and 0.1 PPM in frequency. The PPS signal can be connected in either of two ways, either 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 Gadget Box PPS Level Converter and CHU Modem page.

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. The optional tty_clk line discipline/streams module inserts a timestamp following this character in the input data stream. The 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. In order to use the kernel PPS signal, the xntp3 distribution must be compiled with TTYCLK defined.

The modem control leads interface requires converting to RS232 levels and connecting to the data carrier detect (DCD) lead of a serial port. The optional ppsclock streams module captures a timestamp upon transition of the DCD signal. The driver reads the latest timestamp with a designated ioctl() system call to determine the time of arrival of the PPS pulse to within a few tens of microseconds. In order to use the kernel PPS signal, the xntp3 distribution must be compiled with PPSCLOCK defined.

Both the tty_clk and ppsclock modules are described in the Line Disciplines and Streams Drivers page. Directions for building the modules themselves are in the ./kernel directory. Directions on how to configure xntpd to operate with these modules is described in Building and Installing the Distribution page.

Both of these mechanisms are supported by the ATOM_PPS reference clock driver described in the Reference Clock Drivers page and its dependencies. This driver is ordinarily used in conjunction with another clock driver that supports the radio clock that produces the PPS pulse, as described in the Mitigation Rules and the prefer Keyword page. This driver 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 ATOM_PPS 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.

For the utmost time quality, a number of Unix system kernel modifications can be made as described in the A Kernel Model for Precision Timekeeping 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 ntp_adjtime() system call described in that page and the ./include/sys/timex.h header file in the xntp3 distribution. In order to use the kernel PPS signal, the xntp3 distribution must be compiled with KERNEL_PLL defined.

In some configurations may have multiple radio clocks, each with PPS outputs, as well as a kernel modified to use the PPS signal. In order to provide the highest degree of redundancy and survivability, the kernel PPS discipline, tty_clk module, ppsclock 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 prefer Keyword page.


David L. Mills (mills@udel.edu)