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_#2.html | 170 ---------------------------- 1 file changed, 170 deletions(-) delete mode 100644 archives/FreeBSD_NTP_GPS_Experiment_#2.html (limited to 'archives/FreeBSD_NTP_GPS_Experiment_#2.html') diff --git a/archives/FreeBSD_NTP_GPS_Experiment_#2.html b/archives/FreeBSD_NTP_GPS_Experiment_#2.html deleted file mode 100644 index 257d1ae..0000000 --- a/archives/FreeBSD_NTP_GPS_Experiment_#2.html +++ /dev/null @@ -1,170 +0,0 @@ - -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
- - - - -- cgit v1.2.3-59-ga6da