Using the EndRun Technologies Praecis II timing Module With NTP
University Of Hawaii
July 7, 2011
Setting up the Praecis II and antenna
Using Praecis II with NTP
Time Reference Emulation Choice
Verification And Troubleshooting
Making PPS work with Linux
Configuring FreeBSD to use PPS
Graphs Of Various Appendix
A: Minicom Serial Terminal Progam
B: Finding out where your CDMA sources are.
C: Technical Spec to buy Praecis II's (or equivalent) Appendix
D: Why USB-connected serial adapters are unacceptable Appendix
E: My NTP/Praecis Odyssey Appendix
F: Errata for other documents
Graphs Of Various
Appendix A: Minicom Serial Terminal Progam
Appendix B: Finding out where your CDMA sources are.
Appendix C: Technical Spec to buy Praecis II's (or equivalent)
Appendix D: Why USB-connected serial adapters are unacceptable
Appendix E: My NTP/Praecis Odyssey
Appendix F: Errata for other documents
This document is not intended to replace the EndRun Technologies documentation. For the finer points of the Praecis II/Ct command set and status messages, you should consult the Praecis II owner's manual, which can be obtained in PDF format from:
The Praecis II CDMA timing module from EndRun Technologies offers a way to tighten the accuracy of an NTP server to less than 10 μS error from GPS-derived time. The Praecis II began shipping in October 2010, replacing the older Praecis Ct and Praecis Cf products. Besides combining the Ct's time-of-day functions with the Cf's frequency standard functions, the Praecis II also includes a dual-band radio, adding 1.9 Ghz band and continuing to use the 800 Mhz CDMA band as well.
The Praecis timing modules all receive signals from TIA/EIA 95 (IS-95) base stations, which are operated by mobile telephone providers (such as Sprint and Verizon in the US), to provide voice and data service. Receive-only devices like the Praecis II (and Ct and Cf) do not require a service agreement with the mobile provider to receive timing info from the base station.
For the purposes of the application described in this document, Praecis Ct and Praecis II are almost exactly equivalent, and the information herein should apply to the use of Praecis Ct as well as Praecis II.
One of the primary objectives of this document is to assist users of the PerfSONAR Network Performance toolkit in evaluating options and setting up hardware-disciplined NTP service for use with owamp one-way delay measurement software. The relevant version of the PS-NPT as of this writing is 3.2 (netinstall). While some of the concepts here are applicable to earlier versions of PS-NPT, based on Knoppix, it is recommended that you use a current version of the PS-NPT, based on CENTOS, for any new installations. This document shows multiple cases for different Linux-distributions and for FreeBSD, to the extent that they were encountered during the process of studying NTP, owamp, and Praecis II. Some work with FreeBSD, Ubuntu, and Slackware was done to “fast-track” the configuration and study of pulse-per-second timing, which is non-trivial with CENTOS, as it uses the Red Hat derivative of the Linux kernel. More details are in the PPS section, below.
Since the “beginning of time”, so to speak, the core developers of NTP have consistently reinforced a preference for FreeBSD, rather than Linux, as an underlying OS for NTP. On the other hand, the PerfSONAR preference for Linux, versus FreeBSD, or other contemporary operating systems, is influenced by the Web100 kernel patches, and perhaps from community familiarity with Linux. This document addresses operation of a Linux NTP server, disciplined by a Praecis II, with consistent accuracy well within 100 microseconds, a standard that should prove acceptable for network path-delay measurement and analysis.
Praecis II Radios can be acquired directly from EndRun Technologies – contact sales at firstname.lastname@example.org.
If you are going to install the Praecis II in a high-RF interference environment, like a network equipment room or computer room, it is probably a good idea to buy the external antenna with the radio.
The computer to which you attach the Praecis II should have a “real” RS-232 serial port. A USB-based serial adapter will introduce error into your timing signals (see Appendix D).
A technical specification to use in obtaining bids/quotes for purchasing is included in this document as appendix C.
You should also consult the EndRun Technologies Praecis II documentation for instructions on the physical installation of Praecis II.
For many installations, the NTP server may be located close to network and computer equipment, which can produce significant radio-frequency interference. If your installation is in such a place, then you will probably need an external antenna. EndRun Technologies sells an appropriate dual-band vertical antenna with the Praecis II. It is possible to acquire or construct a different antenna, if you understand UHF antenna theory thoroughly. If you already have your Praecis II, you can set it up with the included compact “rubber duckie” antenna, and hope for the best. The external antenna supplied by EndRun Technologies has a magnet-mount base, and therefore is best placed on a ferrous metal surface. Many modern equipment cabinets are made of aluminum, and don't stick to magnets; you may have to find a sheet of steel to place in your selected antenna location as a mounting surface. Small changes in antenna placement can make a big difference in the received signal strength.
Some guidelines for antenna placement are:
Besides increased received signal, another advantage of the external antenna is that it is built to withstand exposure to weather, whereas the Praecis II radio is not. If your radio and antenna can be placed such that the antenna is outside, in coverage of a nearby CDMA base station, you may be able to solve reception problems.
Given NTP's “preference” for uninterrupted operation, it is probably good to securely attach the Praecis II unit to something – either the wall of the cabinet, or the top of the NTP server, with Velcro or tie-wraps. You may also want to strain relief the power cord by tie-wrapping it to the case, to prevent accidental un-plugging. Praecis II will also benefit from temperature stability, so you may wish to consider this in your choice of install location.
You can query the radio through the serial link to examine CDMA coverage and signal levels. Linux-distribution and BSD-family OSes can use minicom as a serial terminal program (see appendix A). The use of a program like minicom on the actual NTP host with which you intend to use the Praecis II is a good way to verify that the serial settings are correct, prior to starting NTP. Having minicom set up prior to operation will also enable you to troubleshoot later, even if the installation is in a remote location. Note that the Praecis device will not echo commands, so you will not see anything as you are typing, but you should see a result after you hit enter. After setting up minicom as shown in Appendix A, a couple of useful commands that will show you the status of your Praecis II are:
SPSTAT – which will show you whether the radio is locked on a CDMA signal, what the signal-to-noise ratio is, and an indicator of any frame errors. It also includes information that can be used to distinguish between base stations and frequencies.
SETTINGS – which prints all of the Praecis II's settings.
CTIME – to turn the periodic time announcements on or off. While you are configuring the device, it's probably best to do “CTIME=OFF”, to prevent the results from commands from scrolling off the screen.
Consult the EndRun Technologies documentation for more details on commands and their outputs.
Below is a short Perl script, which will print periodic signal reports from the Praecis II. It could assist you in observing trends in SNR, and in fine antenna placement.
Output should look like:
The output of the SPSTAT command is described in the Endrun Technologies Praecis II User Manual, on page 23. In the example output above, the radio is locked on a base station signal (LKD), has 2.6 - 2.8 signal-to-noise ratio, and has experienced frame errors in the last 20 minutes or so, The frame-error rate in the right-most column reads like a ratio of errored frames/non-errored frames (where 1.000 is all errored frames, and 0.000 shows no errored frames within the relevant interval) . While it is best to have consistent zero-frame-errors, some errors do not appear to degrade the time accuracy. Loss-of-lock events, however, eventually will. If your signal-to-noise ratio is less than 3.0, you should try to adjust the antenna placement to achieve better SNR. Whatever your SNR is, observe SPSTAT outputs for at least 24 hours to see that your installation maintains a usable signal and stays locked. Note that the output of SPSTAT will appear in the NTP clockstats file, if you use the Trimble Palisade emulation, as described below.
This section provides configuration advice for using the various emulation modes of Praecis II with NTP refclock drivers. If you desire more detail on how these examples and recommendation were derived, you should refer to Appendix E: My NTP/Praecis Odyssey.
The ntp.org NTP daemon software includes pieces of code called “refclock” drivers, which serve to interface various types of stratum 0 hardware clocks to NTP. Three drivers (plus one special driver) can be used with a Praecis II yet only the Trimble Palisade driver has been updated to work with EndRun Praecis radios.
There are three different clock emulations that you can configure the Praecis II to perform: TRIMBLE, TRUETIME, and SPECTRACOM . Truetime and Spectracom each rely on the NTP server host's marking the time of the arrival of an ASCII character on the serial port. When using Trimble Palisade mode, the Praecis II determines the time when the NTP server commands it, by asserting the CTS line on the serial port. Trimble mode is more accurate than either Spectracom or Truetime modes by themselves. Truetime and Spectracom refclock drivers require the admin to supply fake satellite delay parameters to the driver, which must be determined by trial and error.
It is possible to obtain more accuracy by using Truetime or Spectracom modes in concert with the PPS pulse provided by the Praecis II on the DCD pin of the serial port. Setting up the necessary environment for NTP to recognize and use PPS and the ATOM driver is addressed in the section below, entitled “PPS Support”.
An additional advantage of using the Praecis-aware PALISADE NTP refclock driver is that in “Praecis” mode (mode 1), the driver will query the radio periodically for signal-to-noise and frame error reports, and save them in the clockstats file.
Although most admins will probably want to use Trimble mode, the Truetime, Spectracom and PPS, as they are used by the relevant NTP refclock drivers don't require any signal to be sent from the server to the Praecis II, therefore it is possible to “split” a serial line to discipline more than one server at a time. Since the Trimble mode requires a two-way handshake between the Praecis II and the NTP server, it cannot be split.
The configuration of ntpd is normally placed in /etc/ntp.conf. At the top of the file, you can set up the generation of ntp stats files, which can provide useful information about the health and performance of NTP. A stats file setup looks like:
You should check to see that the two specified directories, shown as “/var/spool/ntpstats” and “/var/lib/ntp” exist and are writable by the UID that ntpd runs as, which is “ntp” in many cases. For example (as root, or with sudo):
chown ntp.ntp /var/spool/ntpstats/
The NTP refclock drivers are part of the ntpd program. Refclock drivers can be used by adding the proper lines to the ntp configuration file (usually “ntp.conf”). For those that use RS-232 serial interfaces, it is common to make a soft link from the serial port's representative device in the /dev/ directory to a name that the refclock driver looks for when it starts. For example, when you configure the palisade refclock driver (for use with Praecis II Trimble mode), you enter
server 127.127.29.0 mode 1 prefer
fudge 127.127.29.0 refid CDMA
into ntp.conf, and then make a soft link:
ln -s /dev/ttyS0 /dev/palisade0
The zero in “127.127.29.0” corresponds to the zero in “/dev/palisade0”. Although “palisade0” is intended to be linked to “/dev/ttyS0”, “palisade0” could just as easily be linked to “/dev/ttyS1” and would work properly. If you tell the refclock driver to use “127.127.29.0”, then it will need to find a “/dev/palisade0” linked to the serial port connected to the Praecis II. The actual name of the serial port's device entry in /dev is irrelevant.
To configure Praecis II with the Trimble driver, enter the following in your ntp.conf file.
server 127.127.29.0 prefer
fudge 127.127.29.0 refid CDMA
Stop the ntpd daemon:
/etc/init.d/ntpd stop (CENTOS)
/etc/init.d/ntp stop (Ubuntu)
/etc/rc.d/rc.ntpd stop #(Slackware)
Using a serial terminal program (such as minicom) connected to the Praecis II, enter the following commands.
Make the link from the serial device to /dev/true0:
ln -s /dev/ttyS0 /dev/palisade0 # Linux
ln -s /dev/cuau0 /dev/palisade0 # FreeBSD
Start the NTP daemon:
/etc/init.d/ntpd start #(CENTOS)
/etc/init.d/ntp start #(Ubuntu)
/etc/rc.d/rc.ntpd start #(Slackware)
Truetime mode is addressed in the section on configuring PPS, below.
The third mode, using Spectracom emulation, offers no additional benefits, over those mentioned above, and is not covered here.
Once you have configured and restarted ntpd, you can get a quick sanity check using the following to display the current NTP peers:
which will return something like:
remote refid st t when poll reach delay offset jitter
GPS_PALISADE(0) .CDMA. 0 l 0 0 000 0.000 0.000 0.000
See http://doc.ntp.org/4.2.6p3/ntpq.html for detail about the output.
The ntpd loop filter will take some time to stabilize, and accumulate input from the Praecis. The above display shows that ntpd has not declared the Praecis reachable yet, but the configuration is probably OK. If the GPS_PALISADE reference is not displayed, or the “reach” value does not have a non-zero value within a couple of minutes, then you may need to re-check your configuration. It will probably take some time for NTP to “settle out”, but you should observe that “reach” progresses to “377” and stays there, and that offset reaches and maintains a reasonable value. The output of “ntpq -p” should progress to look something like:
remote refid st t when poll reach delay offset jitter
*GPS_PALISADE(0) .CDMA. 0 l 8 16 377 0.000 0.001 0.001
If your ntpd does not show the refclock as a peer, then the configuration may need correction, or a softlink may be incorrect or missing. Although it is uncommon, it is also possible to compile ntpd without support for any refclock drivers. If this is the case, then you will need to obtain another installation source for your ntpd, or compile it from source.
If you have (as I did) a Praecis Ct that you bought before 2008, and you are having problems with time offsets >= one second, check to see that the configured leap second value is correct. As of this writing, the setting should be “15 15”. If you consult leap second references and the last leap second insertion has occurred after December 31, 2008, then you may have to add leap seconds for a total greater than 15. If your Praecis Ct has a leap second setting that shows 14 or fewer, then it is safe to set it to 15, to see if it makes your clock offset disappear. No new Praecis II should be configured with leap seconds less than 15 (but feel free to check). An authoritative source is:
If you are counting leap seconds using this file to set Praecis II (or Ct) LEAP parameter, then leap second #1 occurred July 1, 1981, and leap second #15 occurred Jan 1, 2009. You may find references to leap second having occurred on December 31, 2008, which is simply a different expression of the same leap second #15.
NTP, Apparmor and refclocks:
Add /dev/ttyS0 and/or /dev/trueX, /dev/palisadeX, /dev/wwvbX, etc to apparmor profile for ntpd. In Ubuntu 10.10, this is in /etc/apparmor/init/network-interface-security/usr.sbin.ntpd. You may also wish to add the path to your peerstats, clockstats, loopstats, etc files, if it is not already in there. Since the location of stats files can vary between packages/distributions, make sure that the ones cited in ntp.conf match the ones in /etc/apparmor/init/network-interface-security/usr.sbin.ntpd.
After editing the profile for ntpd, you will need to restart apparmor (in Ubuntu 10.10 - “/etc/init.d/apparmor restart”).
This section is about making PPS work with Linux. It is not (yet) a complete guide to making PPS work. If you simply want to use Praecis II with a single NTP server, or a server which can run a time-sensitive service like owamp, then you should either configure your Linux box with Trimble mode as described above. If you must have PPS, it may be easier to use FreeBSD, as shown in the section below titled “Configuring FreeBSD To Use PPS”.
Praecis II also provides a pulse-per-second signal on the serial port's DCD pin. It can be used to mark the occurrence of the per-second UTC time “tick” within about 10 microseconds. In order to use the PPS signal, your Linux NTP server must have:
An ntpd that was compiled to include PPS capability
A copy of the “ldattach” utility that includes the “PPS” line discipline type
A hardware PPS source (such as Praecis II).
A time-of-day source (such as Praecis II)
A kernel with the current implementation of the PPS API
Linux kernel versions and parallel developments can be a confusing matter, if you're not accustomed to the details. The “main line” kernel source code is available from http://kernel.org, and distributions (or operating systems built upon) Linux use either the kernel.org kernel, or some derivative. A notable derivative is the Red Hat kernel, which is currently based in Linux kernel version 2.6.18, which was released on kernel.org in late 2006, augmented by a set of patches that are maintained by Red Hat. As of May 2011, the kernel.org source has progressed to version 2.6.39. While the Red Hat kernel adopts some changes made to the kernel.org kernel, and contributes patches to the kernel.org kernel, the Red Hat kernel does not include all kernel.org changes, including PPS support, which was made standard in the kernel.org kernel at version 2.6.38. For more details about linux PPS support, see the Linux PPS home page at: http://wiki.enneenne.com/index.php/LinuxPPS_support .
If you are running CENTOS, Fedora, RHEL, or another Red Hat derivative, you may be able to include kernel PPS support by either replacing your standard Red Hat kernel with a kernel.org kernel, or by patching the Red Hat kernel code. Either course would require considerable familiarity with the chosen process, as well as time and effort, and applicable patches (if they exist). Even if you find PPS patches for a kernel.org. 2.6.18 version, they might be out of date, or they may not work with the Red Hat patch list.
If you intend to set up PPS on linux, other distributions may offer an easier path. During the writing of this document, I discovered that Ubuntu Desktop 10.10 includes the necessary kernel functionality, as intstalled, yet required compiling the ldattach program from source. Ubuntu's kernel packages are much more similar to concurrent linux.org kernel versions . Reportedly, the “util-linux” package for Ubuntu 11.04 includes ldattach.
The 2.6.38 Linux kernel (plus probably later kernels), from kernel.org, has the PPS API code included, and can be used without patching. Once you have a running, PPS-capable kernel, with modules loaded, you will see stuff in /sys/class/pps/.
# lsmod |grep pps
pps_ldisc 1470 2
pps_core 5529 2 pps_ldisc
The ldattach utility is part of the util-linux (http://kernel.org/~kzak/util-linux/), which is included with some distributions and not with others. If you have ldattach on your machine, type “ldattach” with no args, and it will tell you what line disciplines it supports:
If it supports PPS, then you can probably use it to register the PPS line discipline using:
ldattach PPS /dev/ttyS0
Of course, substitute your serial port's dev name, if it is not /dev/ttyS0. If this is successful, ldattach will be running as a daemon:
# ps -ef |grep ldattach
20328 1 0 May16 ? 00:00:00 /usr/sbin/ldattach PPS /dev/ttyS0
It can be difficult to determine whether your ntpd program has been configured to use PPS, unless you compile it yourself. Among the OS flavors I worked with to make this document (Slackware, Ubuntu, FreeBSD), only Ubuntu 10.10 included a PPS-capable ntpd, “out-of-the-box”. Since the CENTOS installs that I used for PerfSONAR did not have PPS-capable kernels, I don't know for sure whether the provided ntpd is PPS-capable. Compiling ntp-4.2.6p3 is straightforward, if you can handle a standard auto-tools install. If you elect to compile, I suggest the following configuration:
Using this, I have compiled pps-aware-ntpd successfully on Slackware 13.1 and FreeBSD 8.2.
[I obviously need to backtrack and make better notes on this.]
In the ntp.conf file, you will need something like:
server 127.127.5.0 prefer
fudge 127.127.5.0 refid CDMA
fudge 127.127.5.0 time1 .00704
#PPS ATOM driver
server 127.127.22.0 minpoll 4 maxpoll 4
fudge 127.127.22.0 flag2 1 flag3 1
See the documentation for ATOM refclock: http://doc.ntp.org/4.2.6p3/drivers/driver22.html
and the Truetime refclock: http://doc.ntp.org/4.2.6p3/drivers/driver5.html, as well as my errata, in Appendix F, below.
Once ntp-capable kernel, ldattach and ntpd are running, you should get:
The distinctive “o” in the first column is your undeniable proof that you're actually using PPS. The omission of “flag2 1” in ntp.conf would result in your time being early by the PPS pulse width (104 μS on Praecis II, with Praecis II configured with “PPSWIDTH=NTP” ). The omission of “time1 0.00704” for the Truetime driver will result in NTP trying for a while to use the two refclocks, and then finally giving up. Using “time1” in this application is undefined, and the necessary must be evaluated empirically, as far as I can tell. The “time1” fudge factor was originally used to correct for propagation time from a satellite, as the original use of the Truetime driver was for a NOAA/NBS GOES Satellite time service receiver, which required such tweaking. Why “time1” is necessary with Praecis II and how to guess what the number should be, is unclear. Although the determination of “time1” is somewhat critical for the accuracy of NTP disciplined by Truetime mode without PPS, when PPS is enabled, it only needs to be adjusted so that time as determined by the Truetime updates are within 0.4 seconds of the relevant PPS edge. [Update: Reading the source code for the Truetime driver reveals that the driver is configured with a default propagation offset time, which you alter by adding the time1 parameter. It may be that the need for time1 in this application is to offset the default "error". ]
The source code (ntpd/refclock_atom.c) states:
Which means (apparently), that when you don't specify time1, the difference between the Truetime time and the ATOM pps time is too large for PPS to stay “locked”. This is counter-intuitive, when you look at the scope trace of PPS and Truetime together, as shown below, under “Graphs Of Various”. The scope trace there shows the PPS trailing/rising edge coinciding with the leading/rising edge of the start bit on the Truetime carriage return character, which agrees with the comments in ntpd/refclock_true.c:
Much of what is written about PPS and NTP on the Internet refers to FreeBSD, which has been preferred over Linux by NTP experts for years. Although you may find references to re-compiling the FreeBSD kernel, it is not necessary to do so in order to use PPS with NTP, and in fact, it has been suggested that the non-kernel PPS interface “handles jitter more gracefully”*. I did have to compile ntpd (instead of using the one included with 8.2-RELEASE), in order to make PPS work. The ntp.conf entries are the same as described above for Linux PPS.
Since PPS/Truetime operation requires no “handshake”, it is common to wonder whether a single Praecis II could be connected to two NTP servers. In fact, it works well. You can simply make a splitter cable with pins 1 (DCD), 2 (RxD), 3(TxD), and 5(GND) on a male DB9 forked to two female connectors, each of which plugs into a server's serial port. It is probably best for the wires to be as short and as equal in length as possible. I took care to twist GND and DCD (pps) together, to prevent crosstalk from the RxD and TxD. Of course, you wouldn't need both RxD and TxD, for me it was quicker to provide both wires than to sort out data direction. Which to exclude is left as an exercise for the reader.
[Need to mention shmpps?]
Graphs Of Various
If you study NTP for a while, and you'll eventually realize that it's like trying to use a surveyor's transit from a row boat – at sea – during a swell. There are no real “hard” references. But then, there never are, really. I realized at some point among my former careers as a navigation engineer, astronomical instrument technician, and NTP guy that it is not simply hard, but impossible, to know exactly where you are and what time it is. The “neat trick” of GPS time, and its refinement by various methods have tightened the available time references over the last 30 years. But to rest easy because GPS time is accurate, and CDMA time is close to GPS time, is to accept the competency of the nameless operators of CDMA networks, and to discount the challenges they face. What follows is a collection of observations that I had hoped to develop into some sort of analytical narrative, but that's going to delay this document indefinitely.
The PPS Signal On 4 Radios At Once
You may have wondered whether the timing offered by CDMA timing modules, and in fact GPS, is really all that accurate. What kind of difference do we see between radios? Between CDMA base stations? The PPS pulse is 104 μS, which is also one serial bit-time at 9600 bps. These 3 oscilloscope captures show the relationship of PPS pulses from 4 radios, with one synced to a different base station than the other three. Note that the 2nd and 3rd, below, have different time scales.
Relationship between PPS and TrueTime Periodic Report
The above trace shows how the timing of the ASCII time-of-day report from Truetime mode relates to PPS output on DCD. Below, the same relationship is shown at significantly higher horizontal “zoom”. The trailing (rising) edge of the PPS pulse coincides with the leading edge of the serial start bit on the CR (ASCII 0x0D).
Effect Of ATOM PPS Driver Edge Change on OWAMP Data
The graph above shows one-way transit times as measured by owamp. The two hosts are separated by a single Gigabit Ethernet switch, and at about 11:30 AM, NTP's ATOM refclock was reconfigured with “fudge flag1 1”, which supposedly uses the falling edge. This graph suggests, however, that the change has caused the PPS-configured host (220.127.116.11) to alter its time to 104 μS later, which suggests that the trailing/rising edge is used when “fudge flag2 1” is configured. The fact that this would align the time with the beginning of the Truetime CR start bit further supports that the ATOM PPS driver is using the trailing/rising edge of the PPS pulse.
Minicom is a serial terminal program that is available as a package for most Linux and BSD-OS distributions. It mimics the behavior of the popular serial terminal program PROCOMM, which was popular on MS-DOS PCs in the 1980's.
During the setup of your Praecis timing module, you will be required to connect a serial “terminal” to the serial port on the radio. Rather than moving the serial cable back and forth between your NTP server and another computer set up as a serial terminal, you can use the minicom program from your NTP host. Also, if your NTP server is set up in a remote location, you can connect with SSH and run minicom remotely, possibly saving you a trip to the remote location. You can install minicom by becoming root and typing:
yum install minicom (RedHat, Fedora, CENTOS)
apt-get install minicom (Debian, Ubuntu)
When the installation is done, type the following, as root, to start minicom in setup mode:
The following should appear:
Use your down-arrow to select “Serial port setup” and hit the Enter key .
Hit “F” to toggle “Hardware Flow Control” to “No”, and then hit E to enter the “Bps/Par/Bits” menu.
Set the parameters to 9600 8N1, by typing “C” and then “Q”.
Hit Enter to make the “Comm Parameters” menu go away.
Hit “A” to edit the name of the “Serial Device”. The most common name of the first serial device in Linux distributions is “/dev/ttyS0”. The second port on a machine would be “/dev/ttyS1, and so on.
On FreeBSD, after some experimentation, I found my Praecis II on “/dev/cuau0”.
After editing the “Serial Device” name, hit Enter.
Arrow-down to “Modem and dialing” and hit Enter.
Hit “A” and make the “Init string” empty by backspacing out all characters. Do the same with the “Reset string” (B), and the “Hang-up string” (K). This will prevent minicom from sending modem commands to the Praecis II. Finally, hit Enter to exit the “Modem and dialing parameter setup” menu.
To save minicom's configuration as default, arrow-down to “Save setup as dfl” and hit Enter.
Select “Exit” to close the configuration menu. Now you can begin interacting with the Praecis II, or type “Ctrl-A”, followed by “Q” to exit the program.
The next time you use minicom, you can invoke it simply as “minicom”, rather than “minicom -s” as you did this first time. If you have incorrectly configured minicom, and it refuses to start, you can start it with “-s” again to correct the problem.
There may be times at which you will wish to modify the configuration of minicom. In order to do so, after starting minicom, type “Ctrl-A”, followed by “Z”.
From the “Minicom Command Summary” menu, type “O” (letter ”Oh”) to open the configuration menu, which is the same menu you used in “-s” setup mode.
To exit minicom, press enter to close any menus, and then type “Ctrl-A” followed by “Q”. When asked “Exit without reset?”, select “Yes”.
This guide uses FCC web resources, and is therefore somewhat U.S.-specific. If you are in another country, your RF oversight agency may have similar resources.
Direct your web browser to:
On the form, click the radio-button next to:
“Match only the following radio service(s):”
and select both
CL - Cellular
CW – PCS Broadband
in the list immediately beneath. (You may have to use “Ctrl” or “⌘” to select multiple entries).
Next, find and click the button labeled “Geosearch” at the top (or bottom) of the form toward the right.
On the Geosearch form, you can either choose to select your State/County, or enter your latitude and longitude. The form says that the search is based on NAD83, which is for all useful purposes identical to the WGS84 coordinate system, used by GPS.
The list obtained will not necessarily be complete, but it may provide guidance on placing your Praecis II and its antenna.
CDMA Timing Module:
Uses CDMA TIA/EIA IS-95 CDMA Pilot and Sync channels to provide UTC time-of-day and pulse-per-second (Accuracy must be less than 10 microseconds to UTC typical when locked) signals via RS-232 interface.
Each unit must use both 869-894 MHz and 1930-1990 MHz CDMA bands, and must provide signals compatible with a standard Network Time Protocol (NTP) "refclock" driver that is current and distributed with NTP 4.2.6, as provided from http://ntp.org.
Each unit must provide cables and adapters to use 120 VAC 60 hz power.
Each unit must include external, dual band (869-894 MHz and 1930-1990 MHz) antenna, with mounting hardware (magnetic, bracket or clamp) appropriate connectors, and at least 12 feet of antenna feed line in order to optimize reception in weak signal areas.
unit will be deployed alone in a separate location, and must
therefore be a complete, self-contained unit.
Each unit must weigh less than 5 lbs, including antenna, feedline and AC adapter.
I have some data on this, I really do. Essentially, USB packetization messes with the timing of serial signals, not to an extent that would mess with RS-232, but seriously to an extent that messes with 10 microsecond level timing.
This is a narrative of some of my experience with NTP, Praecis Ct , and Praecis II
UH's NTP Background
When I began working for the U. Hawaii Computing Center in 1991, NTP-master Kevin Mayeshiro had an NTP server running on our main DNS server, a Sun SPARCStation, under SunOS 4.1. It was disciplined by a Precision Standard Time, Inc. Model 1020 TimeSource™ WWV shortwave receiver (which happens to be in my office now). He had compiled and installed clients on SunOS, NeXT, VMS and Ultrix. Since my desktop was a SPARCStation 2 at the time, I ran NTP as a client. After Kevin moved to UC Davis, I made an attempt to follow through with NTP, with mixed success. For a while, I produced a graph of WWV versus WWVH signal strength against time of day, based on the output of the TimeSource 1020.
In 2002, I purchased 2 (GPS-disciplined) Truetime NTS-200's (1 failed one also in my office), which were placed at UH Manoa and Roundtop Radio site.
In 2004, we purchased Dell 1RU servers to use as bwctl and owamp servers, as well as a Praecis Ct., to produce accurate/precise time for OWAMP. My original owamp server was on FreeBSD, partly because of David Mills' derision of timing in Linux. I was led to believe that it would be easier to get pulse-per-second working on FreeBSD than it would on Linux (which was actually the case), although I was not able to make it work at the time. The problem was that it would start up, sync, and run until NTP mitigation excluded it, and then be ignored forever.
DREN DAMPs, under the care of Phil Dykstra, appeared in our network machine room some time later, and the tip I got from Phil was “use Trimble mode”, which was good advice. When using PPS is difficult, or out-of-scope, or unpractical, Trimble mode, with its server-initiated time-stamping, is much more precise than the Truetime or Spectracom emulation modes, which rely on the server's stamping based on the receipt of a serial character. Still, PPS haunted me, it was said to be “slightly” more accurate than Trimble mode, but how much? Was it worth all the bother? I wanted to see it first hand.
In December, 2010, we had the “Freaky NTP Failure of December 2010”, which taught us several things.
Honolulu (The Present Day)
In 2010, the second iteration of the Translight: Pacific Wave NSF grant brought with it a requirement to deploy PerfSONAR to record various metrics, including one-way delay, and I purchased new equipment, including several Praecis II's. After the initial deployments, I had 4 yet-to-be deployed Praecis II radios with their respective PerfSONAR servers, and I realized that the opportunity to learn some things about NTP, Praecis II's, PPS, and owamp was at hand. I set them up, all on a single Ethernet switch and began attempting to see what I could see.
Initially, all four servers were set up with NTP 4.2.6p3, and owamp3.2-rc4 .
Two of the four were PerfSONAR 3.2 netinstall nodes, and the other two were more PPS-friendly OSes, one FreeBSD 8.2, and the other Slackware 13.1, which was chosen because it installs with a complete kernel development set and uses the kernel.org kernel, and handles kernel modifications and re-installs easily.
A 5th NTP server (limpid02 in the diagram) was involved in a couple of different roles. For a while it was an NTP client to every known NTP server in the research world that I could find, and at other times it has been a network NTP client to all of the Praecis-disciplined servers in the group.
One very useful aspect of this setup is that after the NTP loops settle, owamp measures about 50 μS one-way ping times from host-to-host, which provides an environment in which the effects of system load, mis-configurations, NTP noise/drift/settling has a more obvious influence on the numbers than it would on a longer, noisier path. For example, when PPS was initially enabled on the two PPS hosts, it was obvious that the NTP PPS host's clock offset had jumped earlier than the Trimble-mode hosts by about 104 μS, where it would have probably gone unobserved on a more conventional, production owamp set-up.
Several statements from relevant documentation have proven incorrect.
In the NTP ATOM refclock documentation (http://doc.ntp.org/4.2.6p3/drivers/driver22.html):
flag2 0 | 1
Specifies PPS capture on the rising (assert) pulse edge if 0; falling (clear) edge if 1. (default), 1 for clear.
The default is actually 0, rising edge, as stated in the source code (file ntpd/refclock_atom.c) comments:
* The PPS timestamp is captured on the rising (assert) edge if flag2 is
* dim (default) and on the falling (clear) edge if lit.
The “dim” and “lit” references may be unclear. In this context, “lit” apparently means that flag2 is set to 1, and “dim” means flag2 is set to 0.
This has been confirmed in NTP operation on both FreeBSD and Linux.
[Update: It may be that rising and falling edge configs are backwards, rather than the default being wrong. Anyways, the PPS config shown in the PPS section above is correct and works, regardless which thing is backwards.]
In the EndRun Technologies Praecis II User Manual (part No. USM3002-0000-000 Revision 2 ):
On page 38, under Configure NTP you are instructed to enter the following into ntp.conf:
pps /dev/true0 assert
The “pps” keyword is no longer used by current versions of NTP. Instead, you should configure the ATOM refclock driver, as described in this document, to use PPS from your Praecis II.