From 9dadd9eb53928e5b16b89f6bbba96973997142e5 Mon Sep 17 00:00:00 2001 From: Matt Rude Date: Sat, 21 May 2011 22:30:56 -0500 Subject: correcting dumb names --- archives/FreeBSD_NTP_GPS_Experiment_2.html | 170 ++++++++++++++++++ archives/FreeBSD_NTP_GPS_Experiment_4.html | 247 ++++++++++++++++++++++++++ archives/pdf/95jungps.pdf | Bin 0 -> 406581 bytes archives/pdf/Continuous%20Multi%20Channel.pdf | Bin 0 -> 774517 bytes archives/pdf/Prescision%20Oscillators.pdf | Bin 0 -> 868071 bytes archives/pdf/Smart%20Clock.pdf | Bin 0 -> 412052 bytes archives/pdf/TheScienceOfTimekeeping.pdf | Bin 0 -> 1156980 bytes archives/pdf/gps-Dec00.pdf | Bin 0 -> 129854 bytes 8 files changed, 417 insertions(+) create mode 100644 archives/FreeBSD_NTP_GPS_Experiment_2.html create mode 100644 archives/FreeBSD_NTP_GPS_Experiment_4.html create mode 100644 archives/pdf/95jungps.pdf create mode 100644 archives/pdf/Continuous%20Multi%20Channel.pdf create mode 100644 archives/pdf/Prescision%20Oscillators.pdf create mode 100644 archives/pdf/Smart%20Clock.pdf create mode 100644 archives/pdf/TheScienceOfTimekeeping.pdf create mode 100644 archives/pdf/gps-Dec00.pdf (limited to 'archives') diff --git a/archives/FreeBSD_NTP_GPS_Experiment_2.html b/archives/FreeBSD_NTP_GPS_Experiment_2.html new file mode 100644 index 0000000..257d1ae --- /dev/null +++ b/archives/FreeBSD_NTP_GPS_Experiment_2.html @@ -0,0 +1,170 @@ + +FreeBSD NTP eTrex GPS experiment + +
+

FreeBSD NTP GPS Experiment #2

+Using a commercial GPS unit as a NTP time source
+
+
+This system is no longer running. Check +here for other GPS/NTP systems.

+ +This page monitors an experimental +NTP time server using a + +Garmin eTrex GPS receiver as a clock. +
+
+

Setup

+The server is a Shuttle system, with a 2 GHz Celeron CPU and 256M of RAM, +running FreeBSD 4.10. This server sits behind a NAT router, attached to +a broadband cable modem in my basement. The eTrex is connected to +com port 2 of the server via a home-brew serial cable, which also +supplies regulated 3VDC power to the GPS. I learned how to make the +cable here: +http://www.jens-seiler.de/etrex/datacable.html, and here: + +http://www.nomad.ee/micros/etrex.shtml. The power supply is a +12VDC 'wall-wart' transformer connected to an automotive variable- +voltage accessory adapter, set to 3VDC.

+ +I'm running the stock ntpd daemon via setting xntpd_enable="YES" in +/etc/rc.conf. In the /etc/ntp.conf file, I've selected both the +generic NMEA and local clock device drivers:

+ +
+# Local clock, in case GPS fails
+server  127.127.1.0
+fudge   127.127.1.0 stratum 10
+
+# NMEA GPS driver
+server  127.127.20.1 prefer
+
+
+ +I also made a symbolic link '/dev/gps1', which points to +/dev/ttyd1, the name of the comm 2 port in FreeBSD. The driver expects this +link to tell it where the GPS is attached to the system.

+ +The eTrex has NMEA mode set on its 'system:interface' setting to +output NMEA sentences, which the driver then parses to get the +current GPS time. UTC time is then calculated from this (GPS time +doesn't use leap seconds, UTC does, however the NMEA $GPRMC sentence +that the driver defaults to has the UTC in it, calculated by the +GPS unit itself), and the clock is set.

+ +I've also enabled statistics file generation to track how the receiver +is doing. A collection of shell scripts cull the data from the stats +files and hand them off to Ploticus, which generates the graphs for +the current UTC day's data every 15 minutes.

+ +

Results

+In the timekeeping world, GPS clocks are known for their jitter. +Their short-term stability is not all that hot, but long-term +stability is very good, since the satellites are kept locked to +national time standards to within about 5 nanoseconds. This being +said, the Garmin eTrex is designed as a position GPS, not a +timing GPS. The difference is that timing GPS units have a 1 pulse per +second (PPS) output which is steered to within 50 nanoseconds +(ideally) of actual GPS time. A computer connected to this would +have this PPS signal fed into a signal line (the DCD pin of the +serial port is the usual place) and use it to discipline the +local clock to very close to the exact time. Since the PPS +signal carries no data as to which second it's indicating, the +serial NMEA string is also used to tell the server what the actual +time is.

+ +Non-timing GPS units like the eTrex spit out NMEA sentences about once +every second. The variation is due to the fact that the GPS unit was +designed with low cost, rather than super-accurate timing in mind, and +as such the construction and output of the NMEA sentence is considered +a lower priority by the GPS' CPU. This shows up as rather large jitter +in these GPS units, as you can see in the +graphs. +It appears that in this case, the time signal can vary +-150ms and +even worse in some cases.

+ +

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. 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, and I had almost all the +hardware for this experiment at hand. This setup is not ideal, in +that it uses a non-timing GPS receiver, and the receiver is located in a +basement where it has trouble keeping locked on satellite signals +at times.

+ +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, 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: January 24, 2005

+The system has been running for two days now. The GPS unit loses +satellite lock on a fairly regular basis (indicated by the flat +spots on the 'time offset' graphs), and the ntpd daemon falls back +to the computers local oscillator as a timebase. Locating the GPS +outdoors with a better view of the sky would doubtless overcome +this problem, but I'm in no hurry to do that at this time. +

+ +

Update: January 28, 2005

+It appears that the GPS receiver hasn't received an update for over +24 hours now. The ntp daemon has been running on the local +oscillator, which is about 0.125 sec out of sync with public +ntp servers. I will need to check the receiver and see what's +going on. Since the clockstats file only updates every time the +GPS NMEA sentence is used to adjust the clock, the stats page +still contains data on it, while the peerstats file shows the +local clock with no offset, variance, or jitter. Since peerstats +continues to update, the two files get out of sync and generate +plots that could mislead those not familiar with how ntpd works. +

+ +It seems clear now (and further research on the web confirms this) +that GPS receivers not designed for timing applications are not +appropriate by themselves to construct stratum 1 ntp servers. While +the timing of the NMEA sentences will get ntpd within about 1 +second of UTC, timing receivers with 1 PPS output lines are +advertised to providing accuracy to about 50ns. The next phase +of this experiment will be acquiring a PPS GPS receiver and +placing it where it can get a good view of the sky. +

+ +The eTrex or other non-timing GPS receivers could be used in NMEA +mode to provide second information when an accurate 1 PPS source +is also used (i.e. a WWV/H/B radio clock, or cesium frequency +source), however it would seem false economy to invest in one +of these sources to discipline a cheap GPS receiver. The best +'bang for the buck' looks like getting a timing GPS receiver +in the first place, since it can provide both the NMEA second +information and a PPS signal. +

+ +Links:
+ +Using a GPS receiver as a NIST traceable frequency standard
+ +NIST GPS data archive
+NIST Time and Frequency +Lab
+NIST Ion Storage +Group
+ + + + diff --git a/archives/FreeBSD_NTP_GPS_Experiment_4.html b/archives/FreeBSD_NTP_GPS_Experiment_4.html new file mode 100644 index 0000000..473c27f --- /dev/null +++ b/archives/FreeBSD_NTP_GPS_Experiment_4.html @@ -0,0 +1,247 @@ + +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. +
+ +
+

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
+ + + + diff --git a/archives/pdf/95jungps.pdf b/archives/pdf/95jungps.pdf new file mode 100644 index 0000000..1a14f92 Binary files /dev/null and b/archives/pdf/95jungps.pdf differ diff --git a/archives/pdf/Continuous%20Multi%20Channel.pdf b/archives/pdf/Continuous%20Multi%20Channel.pdf new file mode 100644 index 0000000..dba55e2 Binary files /dev/null and b/archives/pdf/Continuous%20Multi%20Channel.pdf differ diff --git a/archives/pdf/Prescision%20Oscillators.pdf b/archives/pdf/Prescision%20Oscillators.pdf new file mode 100644 index 0000000..779122c Binary files /dev/null and b/archives/pdf/Prescision%20Oscillators.pdf differ diff --git a/archives/pdf/Smart%20Clock.pdf b/archives/pdf/Smart%20Clock.pdf new file mode 100644 index 0000000..2280b4d Binary files /dev/null and b/archives/pdf/Smart%20Clock.pdf differ diff --git a/archives/pdf/TheScienceOfTimekeeping.pdf b/archives/pdf/TheScienceOfTimekeeping.pdf new file mode 100644 index 0000000..536d79e Binary files /dev/null and b/archives/pdf/TheScienceOfTimekeeping.pdf differ diff --git a/archives/pdf/gps-Dec00.pdf b/archives/pdf/gps-Dec00.pdf new file mode 100644 index 0000000..1798774 Binary files /dev/null and b/archives/pdf/gps-Dec00.pdf differ -- cgit v1.2.3-59-ga6da