correcting dumb names

author: Matt Rude <[email protected]> 2011-05-21 22:30:56 -0500
committer: Matt Rude <[email protected]> 2011-05-21 22:30:56 -0500
commit: 9dadd9eb53928e5b16b89f6bbba96973997142e5 (patch)
tree: 987e424f215958e5d31db4352d4010a2dcbf2c5a /archives
parent: 774723f7399d94b0773bff7404ae03088db4963f (diff)
download: time.mattrude.com-9dadd9eb53928e5b16b89f6bbba96973997142e5.tar.gz
time.mattrude.com-9dadd9eb53928e5b16b89f6bbba96973997142e5.tar.bz2
time.mattrude.com-9dadd9eb53928e5b16b89f6bbba96973997142e5.zip
8 files changed, 417 insertions, 0 deletions
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 @@
+<HTML><HEAD>
+<TITLE>FreeBSD NTP eTrex GPS experiment</TITLE></HEAD>
+<BODY BGCOLOR=FFFFFF>
+<CENTER>
+<H1>FreeBSD NTP GPS Experiment #2</H1>
+Using a commercial GPS unit as a NTP time source<BR>
+</CENTER>
+<HR>
+<B>This system is no longer running. Check
+<A HREF="../ntp-gps.html">here</A> for other GPS/NTP systems.</B><BR><BR>
+
+This page monitors an experimental 
+<A HREF="http://www.ntp.org">NTP time server</A> using a
+<A HREF="http://www.garmin.com">
+Garmin</A> eTrex GPS receiver as a clock. 
+<BR>
+<HR>
+<H3>Setup</H3>
+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: <A HREF="http://www.jens-seiler.de/etrex/datacable.html">
+http://www.jens-seiler.de/etrex/datacable.html</A>, and here:
+<A HREF="http://www.nomad.ee/micros/etrex.shtml">
+http://www.nomad.ee/micros/etrex.shtml</A>. The power supply is a
+12VDC 'wall-wart' transformer connected to an automotive variable-
+voltage accessory adapter, set to 3VDC.<BR><BR>
+
+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:<BR><BR>
+
+<PRE>
+# 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
+</PRE>
+<BR>
+
+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.<BR><BR>
+
+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.<BR><BR>
+
+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.<BR><BR>
+
+<H3>Results</H3>
+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. <BR><BR>
+
+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 
+<A HREF="http://jcnsystems.dyndns.org/~nordlie/time/">graphs</A>.
+It appears that in this case, the time signal can vary +-150ms and
+even worse in some cases.<BR><BR>
+
+<H3>Rationale</H3>
+Why build a GPS time server in the first place? After all, there are
+already 
+<A HREF="http://www.boulder.nist.gov/timefreq/">publicly available
+time servers</A> 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. <BR><BR>
+
+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 
+<A HREF="http://www.eecis.udel.edu/~mills/ntp/html/refclock.html">
+Reference Clock Driver</A>
+page has many more options, and makes for some fascinating reading.
+<BR><BR>
+
+<H3>Update: January 24, 2005</H3>
+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.
+<BR><BR>
+
+<H3>Update: January 28, 2005</H3>
+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.
+<BR><BR>
+
+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.
+<BR><BR>
+
+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.
+<BR><BR>
+
+<B>Links:</B><BR>
+<A HREF="http://www.boulder.nist.gov/timefreq/service/gpscal.htm">
+Using a GPS receiver as a NIST traceable frequency standard</A><BR>
+<A HREF="http://www.boulder.nist.gov/timefreq/service/gpstrace.htm">
+NIST GPS data archive</A><BR>
+<A HREF="http://www.boulder.nist.gov/timefreq/">NIST Time and Frequency
+Lab</A><BR>
+<A HREF="http://www.boulder.nist.gov/timefreq/ion/">NIST Ion Storage
+Group</A><BR>
+
+
+</BODY>
+</HTML>
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 @@
+<HTML><HEAD>
+<TITLE>FreeBSD NTP Garmin GPS-16 HVS experiment</TITLE></HEAD>
+<BODY BGCOLOR=FFFFFF>
+<CENTER>
+<H1>FreeBSD NTP GPS Experiment #4</H1>
+Using a Garmin GPS-16 HVS unit as a NTP time source<BR>
+</CENTER>
+<HR>
+This page monitors an experimental 
+<A HREF="http://www.ntp.org">NTP time server</A> using a
+<A HREF="http://www.garmin.com">
+Garmin</A> GPS-16 HVS receiver as a clock. 
+<BR>
+<UL>
+<LI><A HREF="http://jcnsystems.dyndns.org/~nordlie/time">Statistics generated every 15 minutes</A></LI>
+</UL>
+<HR>
+<H3>Setup</H3>
+The server is a 
+<A HREF="http://us.shuttle.com/home.aspx">Shuttle</A> 
+computer system, with a 2 GHz Celeron CPU and 256M of RAM,
+running 
+<A HREF="http://www.freebsd.org">FreeBSD</A> 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.
+<BR><BR>
+
+I obtained the GPS-16 HVS unit from <A HREF="http://www.navtechgps.com/">
+www.navtechgps.com</A>, 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 <A HREF="http://www.navtechgps.com/pdf/16_17HVS_manual.pdf">
+GPS-16 manual</A>, 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.
+<BR><BR>
+
+After the hardware was built, I tested it and configured the GPS-16 HVS
+unit using the SNSRCFG program available at the Garmin website:
+<A HREF="http://www.garmin.com/oem">www.garmin.com/oem</A>. 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. 
+<BR><BR>
+
+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:
+<BR>
+
+<PRE>
+gps0 -> cuad0
+pps0 -> cuad0
+</PRE>
+
+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:<BR>
+
+<PRE>
+# link GPS receiver for NTP use
+link cuad0 gps0
+link cuad0 pps0
+</PRE>
+
+to /etc/devfs.conf.
+<BR><BR>
+
+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:
+
+<PRE>
+# 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
+</PRE>
+<BR>
+
+<H3>Results</H3>
+So far the results of the system have been very good. Here is a
+typical time reading:
+
+<PRE>
+> 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
+</PRE>
+
+The offset wanders around a bit but the jitter, indicating the clock
+stability, is always very low. This setup performs much better than
+the <A HREF="../ntp-gps2">eTrex</A> 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.
+<BR><BR>
+
+<H3>Rationale</H3>
+Why build a GPS time server in the first place? After all, there are
+already 
+<A HREF="http://www.boulder.nist.gov/timefreq/">publicly available
+time servers</A> 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. <I>Note: as of April 2007, this has gotten much better,
+due to a network upgrade performed by midconet.</I> 
+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.
+<BR><BR>
+
+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 <A HREF="http://www.leapsecond.com/time-nuts.htm">
+time-nuts</A> among us looking for ever greater accuracy can
+never leave well enough alone, however. :)
+<BR><BR>
+
+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 
+<A HREF="http://www.eecis.udel.edu/~mills/ntp/html/refclock.html">
+Reference Clock Driver</A>
+page has many more options, and makes for some fascinating reading.
+<BR><BR>
+
+<B>Update: April 16, 2007</B><BR>
+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.
+<BR><BR>
+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. 
+<BR><BR>
+
+<B>Update: December 26, 2007</B><BR>
+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 <A HREF="images/gps_lock_drops.jpg">here</A>. 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.<BR><BR>
+
+<B>Links:</B><BR>
+<A HREF="http://www.wraith.sf.ca.us/ntp/">NTP server using PC gnu/linux and FreeBSD</A><BR>
+<A HREF="http://www.david-taylor.myby.co.uk/ntp/FreeBSD-GPS-PPS.htm">
+Adding a FreeBSD NTP server based on an GPS 18 LVC</A><BR>
+<A HREF="http://www.boulder.nist.gov/timefreq/service/gpscal.htm">
+Using a GPS receiver as a NIST traceable frequency standard</A><BR>
+<A HREF="http://www.boulder.nist.gov/timefreq/service/gpstrace.htm">
+NIST GPS data archive</A><BR>
+<A HREF="http://www.boulder.nist.gov/timefreq/">NIST Time and Frequency
+Lab</A><BR>
+<A HREF="http://www.boulder.nist.gov/timefreq/ion/">NIST Ion Storage
+Group</A><BR>
+
+
+</BODY>
+</HTML>
diff --git a/archives/pdf/95jungps.pdf b/archives/pdf/95jungps.pdf
new file mode 100644
index 0000000..1a14f92
--- /dev/null
+++ b/archives/pdf/95jungps.pdf
diff --git a/archives/pdf/Continuous%20Multi%20Channel.pdf b/archives/pdf/Continuous%20Multi%20Channel.pdf
new file mode 100644
index 0000000..dba55e2
--- /dev/null
+++ b/archives/pdf/Continuous%20Multi%20Channel.pdf
diff --git a/archives/pdf/Prescision%20Oscillators.pdf b/archives/pdf/Prescision%20Oscillators.pdf
new file mode 100644
index 0000000..779122c
--- /dev/null
+++ b/archives/pdf/Prescision%20Oscillators.pdf
diff --git a/archives/pdf/Smart%20Clock.pdf b/archives/pdf/Smart%20Clock.pdf
new file mode 100644
index 0000000..2280b4d
--- /dev/null
+++ b/archives/pdf/Smart%20Clock.pdf
diff --git a/archives/pdf/TheScienceOfTimekeeping.pdf b/archives/pdf/TheScienceOfTimekeeping.pdf
new file mode 100644
index 0000000..536d79e
--- /dev/null
+++ b/archives/pdf/TheScienceOfTimekeeping.pdf
diff --git a/archives/pdf/gps-Dec00.pdf b/archives/pdf/gps-Dec00.pdf
new file mode 100644
index 0000000..1798774
--- /dev/null
+++ b/archives/pdf/gps-Dec00.pdf
author	Matt Rude <[email protected]>	2011-05-21 22:30:56 -0500
committer	Matt Rude <[email protected]>	2011-05-21 22:30:56 -0500
commit	9dadd9eb53928e5b16b89f6bbba96973997142e5 (patch)
tree	987e424f215958e5d31db4352d4010a2dcbf2c5a /archives
parent	774723f7399d94b0773bff7404ae03088db4963f (diff)
download	time.mattrude.com-9dadd9eb53928e5b16b89f6bbba96973997142e5.tar.gz time.mattrude.com-9dadd9eb53928e5b16b89f6bbba96973997142e5.tar.bz2 time.mattrude.com-9dadd9eb53928e5b16b89f6bbba96973997142e5.zip