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 20 ms 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 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 to a serial port. The tty_clk line discipline/streams module inserts a timestamp following this character in the input data stream. The PPS Clock Discipline 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.

The modem control leads interface requires converting to RS232 levels and connecting to the data carrier detect (DCD) lead of a serial port. The ppsclock and ppsapi streams modules capture a timestamp upon transition of the DCD signal. Note that the ppsclock module functionality has been subsumed by the new ppsapi 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.

The tty_clk module is included in the NTP software distribution, while the ppsclock module can be obtained via the web at that link or by anonymous FTP from ftp.udel.edu in the pub/ntp directory. 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 ntpd to operate with these modules is described in Building and Installing the Distribution page.

The PPS driver is operates in conjunction with another reference clock driver that produces the PPS pulse, as described in the Mitigation Rules and the prefer Keyword page. One of the drivers described in the Reference Clock Drivers 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 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, some Unix system kernels support a PPS signal directly, 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 /usr/include/sys/timex.h header file. The presence of these kernel provisions is automatically detected and supporting code compiled.

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, 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>