From 2b4e098c3dc537b48475fbcde9483bd88bd1ffd0 Mon Sep 17 00:00:00 2001 From: Matt Rude Date: Sat, 21 May 2011 22:31:34 -0500 Subject: delete bad names --- archives/FreeBSD_NTP_GPS_Experiment_#4.html | 247 ---------------------------- 1 file changed, 247 deletions(-) delete mode 100644 archives/FreeBSD_NTP_GPS_Experiment_#4.html (limited to 'archives/FreeBSD_NTP_GPS_Experiment_#4.html') diff --git a/archives/FreeBSD_NTP_GPS_Experiment_#4.html b/archives/FreeBSD_NTP_GPS_Experiment_#4.html deleted file mode 100644 index 473c27f..0000000 --- a/archives/FreeBSD_NTP_GPS_Experiment_#4.html +++ /dev/null @@ -1,247 +0,0 @@ - -FreeBSD NTP Garmin GPS-16 HVS experiment - - -

FreeBSD NTP GPS Experiment #4

-Using a Garmin GPS-16 HVS unit as a NTP time source
- -

-This page monitors an experimental -NTP time server using a - -Garmin GPS-16 HVS receiver as a clock. -
-

Statistics generated every 15 minutes

Setup

-The server is a -Shuttle -computer system, with a 2 GHz Celeron CPU and 256M of RAM, -running -FreeBSD 6.2. -This server sits behind a NAT router, attached to -a broadband cable modem in my basement. The GPS-16 HVS is connected to -com port 1 of the server via a home-brew serial connector, which also -supplies regulated 12VDC power to the GPS. The connector is a modified -serial terminal adapter, with a DB-9F connector on one side and an RJ-45F -connector on the other, with a DC power input jack added to power the GPS. -Power is supplied by a Radio Shack 12 VDC 500 mA 'wall-wart' power -supply. -

- -I obtained the GPS-16 HVS unit from -www.navtechgps.com, under the "Combination GPS/Antenna" section. The -GPS-16 HVS provides the necessary 1 Pulse Per Second (PPS) line needed for -highly accurate timing, as well as accepting a wide range of DC voltages for -power input. While -this units works well, recently other NTP timekeepers have had good luck -with the much-cheaper Garmin GPS-18 LVC (be sure to use the LVC version, -which includes a 1 PPS line). I wired the connector according to the -chart in the -GPS-16 manual, page 7. I also connected the grey 1 PPS line to pin -1 on the DB9 connector (Data Carrier Detect), so that the NTP PPS driver can read it. Even -though the PPS line is only TTL (0-5 VDC), most modern RS-232 ports -can still sense it without any additional electrical conditioning. -

- -After the hardware was built, I tested it and configured the GPS-16 HVS -unit using the SNSRCFG program available at the Garmin website: -www.garmin.com/oem. Click -on the GPS unit, then choose "Downloads & Updates" on the menu at -left. Running the program on a windows desktop, I verified that the -unit was receiving satellite transmissions in the location I had -placed it (a window). I left most everything in the configuration -in the default mode, except: I turned off all NMEA sentences except -GPRMC (which is what the NTP driver looks for), and enabled the -PPS line. -

- -The software configuration was fairly simple. To run the NTP daemon -at system startup, I added 'xntpd_enable="YES"' to the /etc/rc.conf -file on the FreeBSD system. The NTP daemon drivers need to know -where to find the data and signals for using the GPS. The NMEA -and PPS drivers look for devices with names /dev/gpsx and /dev/ppsx -respectively, where x is the unit number. In this case I created -symbolic links in the /dev directory as such: -
- -

-gps0 -> cuad0
-pps0 -> cuad0
-

- -These refer to the first serial communications port (COM 1), where -the GPS unit was connected. Since I didn't want to lose the links -any time 'make' was run in the /dev directory, such as a system -update, I added:
- -

-# link GPS receiver for NTP use
-link    cuad0   gps0
-link    cuad0   pps0
-

- -to /etc/devfs.conf. -

- -Now the NTP configuration itself. In this case I used the generic -GPS NMEA driver for the serial stream, and the PPS driver to -discipline the clock (increase the accuracy of the GPS NMEA sentence). -To tell NTP which clock is to be disciplined, the 'prefer' tag is -added to the NMEA driver line. I also added an entry to poll an NTP -server on my ISPs network, and finally enabled the local system clock -to act as a backup in case everything else went down. Here's the -/etc/ntp.conf file in its entirety: - -

-# Local clock, in case network link goes down
-server  127.127.1.0
-fudge   127.127.1.0 stratum 10
-
-# NMEA GPS driver
-server  127.127.20.0 prefer
-
-# Pulse Per Second (PPS) driver fine-tunes
-#  the data provided by the NMEA GPS
-server  127.127.22.0
-
-# Network NTP server for comparison, but tell NTP never to use
-#  it for a timesource
-server tock.midco.net noselect
-
-# Where to keep track of the local clock drift
-driftfile /etc/ntp.drift
-
-# Tell ntpd to keep statistics
-statsdir        /var/log/ntp/
-filegen clockstats      file clockstats type day        enable
-filegen peerstats       file peerstats  type day        enable
-filegen loopstats       file loopstats  type day        enable
-statistics clockstats peerstats loopstats
-
-# Send log output to a seperate file for NTP
-logfile /var/log/ntp/messages
-

-
- -

Results

-So far the results of the system have been very good. Here is a -typical time reading: - -

-> ntpq -p
-     remote           refid      st t when poll reach   delay   offset  jitter
-==============================================================================
- LOCAL(0)        LOCAL(0)        10 l   52   64  377    0.000    0.000   0.002
-+GPS_NMEA(0)     .GPS.            0 l   15   64  377    0.000   -0.018   0.004
-oPPS(0)          .PPS.            0 l    6   64  377    0.000   -0.018   0.004
-xtock.midco.net  .GPS.            1 u   19   64  377   16.811    1.340   0.072
-

- -The offset wanders around a bit but the jitter, indicating the clock -stability, is always very low. This setup performs much better than -the eTrex GPS, due to the availability of -the 1 PPS signal. The GPS-16 HVS has locked up once during the -experiment (running about 1 month as of April, 2007), requiring -cycling the power to reset the receiver. Also the GPS does lose -lock occasionally, and the time and PPS jump when lock is re-established. -

- -

Rationale

-Why build a GPS time server in the first place? After all, there are -already -publicly available -time servers that administrators can use to synchronize their -system clocks. The reasons are many, but the primary one in this -case is that the broadband network this system is connected to is -so congested that trying to sync to public time servers was almost -impossible. Note: as of April 2007, this has gotten much better, -due to a network upgrade performed by midconet. -The ntpd daemon was getting so far off that it was -causing clock resets by more than half a second, and sometimes multiple -seconds, rather than slowly slewing the clock as is normally done. -Other systems on my home LAN that sync to this server were also having -problems because of all this bouncing around of the current time -reading. Some sort of stabilizing influence was needed other than -depending on external network time servers. -

- -One easy but less accurate way around this would be to run an NTP -server with the localclock driver as the source. Since this -runs off the systems quartz frequency standard, the time will -drift with temperature and sometimes voltage, but will still be -much more stable than NTP trying to synch to multiple servers -on a clogged network connection. Such a system should itself -be synched either manually or perhaps through a crontab by -running ntpdate against a public NTP server. This sacrifices -accuracy for stability, and is probably sufficient for many -applications. Those -time-nuts among us looking for ever greater accuracy can -never leave well enough alone, however. :) -

- -Other possible time sources are various radio clocks, shortwave radio -receivers feeding WWV/WWVH signals into a sound card, WWVB radio -clocks, LORAN-C radio clocks, CDMA (cellular phone) clocks, -precision frequency sources fed into -the PPS driver, etc. The - -Reference Clock Driver -page has many more options, and makes for some fascinating reading. -

- -Update: April 16, 2007
-The system has been running fairly well. When the GPS receiver loses -signal lock, ntpd switches to the next highest stratum server, which -is the external server used for comparison. Since this server runs -at an offset from the GPS, this causes some instability in the test -server. To help reduce this, I added the 'noselect' option to the -external server line, which instructs ntpd to never use that -server as a timesource. Ntpd should now switch to the 'local' clock -when GPS is unavailable, which should be fine for short periods. Since -the local clock is frequency-adjusted by ntpd based on other clocks -such as the GPS, it should act as a hold-over clock while the GPS -receiver reaquires signal lock. -

-Note: this configuration is aimed at this GPS/NTP experiment. One would -not normally configure an NTP server synchronizing a network this way. -Having ntpd fall back to other external servers is the normal mode -of operation, sacraficing a small measure of stability for overall -reliability and accuracy. -

- -Update: December 26, 2007
-A further study the frequency of GPS loss-of-lock events: The system -queries the GPS receiver about every 64 seconds, or 1340 times per -day. If the receiver is unlocked the GPRMC sentence includes a 'V' -character, if the receiver has a positive lock an 'A' appears in the -sentence. A script was constructed to report the number of unlocked -sentences per day contained in the daily 'clockstats' log files. The -results for the period from March 14, 2007 through December 26, 2007 -appears here. The graph seems -to indicate a yearly trend in the average number of daily lost-lock -events. This may be due to satellite constellation configuration, -attenuation of radio signals by atmospheric moisture, changes in -receiver sensitivity or noise floor due to temperature, or -some combination of these effects. Again, the receiver is located -on the sill of a south-facing window, indoors, with a good view of the -southern sky through the glass.

- -Links:
-NTP server using PC gnu/linux and FreeBSD
- -Adding a FreeBSD NTP server based on an GPS 18 LVC
- -Using a GPS receiver as a NIST traceable frequency standard
- -NIST GPS data archive
-NIST Time and Frequency -Lab
-NIST Ion Storage -Group
- - - - -- cgit v1.2.3-59-ga6da