[Git][NTPsec/ntpsec][master] 2 commits: In TrueTime driver, remove GOES support (sats shut down in 2005).
Eric S. Raymond
gitlab at mg.gitlab.com
Sun Sep 17 16:04:55 UTC 2017
Eric S. Raymond pushed to branch master at NTPsec / ntpsec
Commits:
cdfe68a8 by Eric S. Raymond at 2017-09-17T16:02:21Z
In TrueTime driver, remove GOES support (sats shut down in 2005).
- - - - -
227e0d56 by Eric S. Raymond at 2017-09-17T16:04:25Z
Documentation polishing.
- - - - -
4 changed files:
- docs/driver_hpgps.txt
- docs/driver_truetime.txt
- docs/rollover.txt
- ntpd/refclock_truetime.c
Changes:
=====================================
docs/driver_hpgps.txt
=====================================
--- a/docs/driver_hpgps.txt
+++ b/docs/driver_hpgps.txt
@@ -13,7 +13,7 @@ Serial Port: /dev/hpgps__u__; 9600bps 8N1, 19200bps 7N2 for the HP Z3801A
As of September 2017 we have reports that the internal clock on a
Z3801A has been recently observed to roll over around to 1998 (see
link:rollover.html[Rollover issues in time sources]). Users should
-audit for rollover before deplying any of these devices.
+audit for rollover before deploying any of these devices.
== Description ==
=====================================
docs/driver_truetime.txt
=====================================
--- a/docs/driver_truetime.txt
+++ b/docs/driver_truetime.txt
@@ -22,11 +22,11 @@ it reliably recover from a trashed or zeroed system clock.
== Description ==
This driver supports several models models of Kinemetrics/TrueTime
-timing receivers, including 468-DC MK III GOES Synchronized Clock,
-GPS- DC MK III and GPS/TM-TMD GPS Synchronized Clock, XL-DC (a
-151-602-210, reported by the driver as a GPS/TM-TMD), GPS-800 TCU (an
-805-957 with the RS232 Talker/Listener module), and very likely others
-in the same model families that use the same timecode formats.
+timing receivers, including GPS- DC MK III and GPS/TM-TMD GPS
+Synchronized Clock, XL-DC (a 151-602-210, reported by the driver as a
+GPS/TM-TMD), GPS-800 TCU (an 805-957 with the RS232 Talker/Listener
+module), and very likely others in the same model families that use
+the same timecode formats.
Most of this code is originally from refclock_wwvb.c (now
refclock_spectracom.c) with thanks. It has been so mangled that wwvb is
@@ -43,7 +43,6 @@ L - Line feed
Quality codes indicate possible error of:
--------------------------------------------------
-468-DC GOES Receiver
GPS-TM/TMD Receiver
? +/- 500 milliseconds # +/- 50 milliseconds
* +/- 5 milliseconds . +/- 1 millisecond
@@ -55,34 +54,6 @@ initial synchronization and when received signal is lost for an
extended period; unlock condition is indicated by other than <SP>
in the quality field.
-== Notes on the 468-DC receiver: ==
-
-Send the clock a +R+ or +C+ and once per second a timestamp will appear.
-Send a +R+ to get the satellite position once (GOES only).
-
-Since the old east/west satellite locations are only historical, you
-can't set your clock propagation delay settings correctly and still use
-automatic mode. The manual says to use a compromise when setting the
-switches. This results in significant errors. The solution; use fudges
-time1 and time2 to incorporate corrections. If your clock is set for 50
-and it should be 58 for using the west and 46 for using the east, use
-the options
-
-+time1 +0.008 time2 -0.004+
-
-This corrects the 4 milliseconds advance and 8 milliseconds retard
-needed. The software will ask the clock which satellite it sees.
-
-The PCL720 from PC Labs has an Intel 8253 look-alike, as well as a bunch
-of TTL input and output pins, all brought out to the back panel. If you
-wire a PPS signal (such as the TTL PPS coming out of a GOES or other
-Kinemetrics/Truetime clock) to the 8253's GATE0, and then also wire the
-8253's OUT0 to the PCL720's INPUT3.BIT0, then we can read CTR0 to get
-the number of microseconds since the last PPS upward edge, mediated by
-reading OUT0 to find out if the counter has wrapped around (this happens
-if more than 65535us (65ms) elapses between the PPS event and our being
-called.)
-
== Notes on the TL-3 receiver: ==
The mini-DIN RS-232 port uses the Apple pinout.
=====================================
docs/rollover.txt
=====================================
--- a/docs/rollover.txt
+++ b/docs/rollover.txt
@@ -128,7 +128,7 @@ synchronized to the solar calendar. With it, Unix time after
Time) coincides with UTC. Unix time before 1972 was an approximation
of GMT (Greenwich Mean Time) without leap seconds.
-On POSIX-compliant Unix systems (which is now effecively all) Unix
+On POSIX-compliant Unix systems (which is now effectively all) Unix
time can be retrieved with nanosecond precision; some older versions
supported only millisecond precision. The subseconds counter is not
involved in any of the rollover or leap-second issues thith the
@@ -192,7 +192,7 @@ Raw GPS time is not leap-second corrected, but the satellite messages
include a leap-second offset field in a special update approximately
every 20 minutes. If the receiver firmware is not carefully designed
there will be a window between device boot time and the next
-leap-second update, and around leap-second correctipns, during which
+leap-second update, and around leap-second corrections, during which
the reported second will be incorrect.
The qualifications about careful design are important because GPS
@@ -213,10 +213,11 @@ To yield a UTC date, the weeks+second information from the GPS satellites
has to be used as an offset to a base date.
The most naive way to do this would to simply use the zero date of the
-current era (1024-week cycle) as the base. Some very early GPS equipment
-seems to have worked this way, but it has the drawback that the device
-time-warps at the next GPS era rollover - which, if your device first ship
-is only a few years before that rollover, is a serious drawback.
+current GPS era (1024-week cycle) as the base. Some very early GPS
+equipment seems to have worked this way, but it has the drawback that
+the device time-warps at the next GPS era rollover - which, if your
+device first ship is only a few years before that rollover, is a
+serious drawback.
There is a relatively simple way to extend the useful life of a GPS
used as a clock. That is to choose a pivot date in GPS weeks. When
@@ -252,7 +253,7 @@ Finally, when you buy a GPS you do not know - and often will not be
able to discover - how far in the past its hidden pivot date is. This
means that time service operators using a GPS as a local Stratum 0
need to be aware of the possibility that their device could roll over
-at any time (but especially near the zeo dats of a GPS era) and be
+at any time (but especially near the zero dats of a GPS era) and be
ready to compensate by dropping in a device with a newer pivot date.
[[ntp_pivots]]
=====================================
ntpd/refclock_truetime.c
=====================================
--- a/ntpd/refclock_truetime.c
+++ b/ntpd/refclock_truetime.c
@@ -15,14 +15,15 @@
/* This should be an atom clock but those are very hard to build.
*
- * The PCL720 from P C Labs has an Intel 8253 lookalike, as well as a bunch
- * of TTL input and output pins, all brought out to the back panel. If you
- * wire a PPS signal (such as the TTL PPS coming out of a GOES or other
- * Kinemetrics/Truetime clock) to the 8253's GATE0, and then also wire the
- * 8253's OUT0 to the PCL720's INPUT3.BIT0, then we can read CTR0 to get the
- * number of uSecs since the last PPS upward swing, mediated by reading OUT0
- * to find out if the counter has wrapped around (this happens if more than
- * 65535us (65ms) elapses between the PPS event and our being called.)
+ * The PCL720 from P C Labs has an Intel 8253 lookalike, as well as a
+ * bunch of TTL input and output pins, all brought out to the back
+ * panel. If you wire a PPS signal (such as the TTL PPS coming out of
+ * a Kinemetrics/Truetime clock) to the 8253's GATE0, and then also
+ * wire the 8253's OUT0 to the PCL720's INPUT3.BIT0, then we can read
+ * CTR0 to get the number of uSecs since the last PPS upward swing,
+ * mediated by reading OUT0 to find out if the counter has wrapped
+ * around (this happens if more than 65535us (65ms) elapses between
+ * the PPS event and our being called.)
*/
#ifdef ENABLE_PPS720
# undef min /* XXX */
@@ -36,7 +37,6 @@
/*
* Support for Kinemetrics Truetime Receivers
- * GOES: (468-DC, usable with GPS->GOES converting antenna)
* GPS/TM-TMD:
* XL-DC: (a 151-602-210, reported by the driver as a GPS/TM-TMD)
* GPS-800 TCU: (an 805-957 with the RS232 Talker/Listener module)
@@ -55,7 +55,6 @@
* L - Line feed
*
* Quality codes indicate possible error of
- * 468-DC GOES Receiver:
* GPS-TM/TMD Receiver: (default quality codes for XL-DC)
* ? +/- 1 milliseconds # +/- 100 microseconds
* * +/- 10 microseconds . +/- 1 microsecond
@@ -66,27 +65,9 @@
*
* The carriage return start bit begins on 0 seconds and extends to 1 bit time.
*
- * Notes on the 468-DC receiver:
- *
+ * This driver used to support the 468-DC receiver, but
* http://www.ebay.com/gds/468-DC-SATELLITE-CLOCK-/10000000006640775/g.html
- * tells us that the GOES sats were shut down in 2005, so this mode is obsolete.
- *
- * Send the clock a 'R' or 'C' and once per second a timestamp will
- * appear. Send a 'P' to get the satellite position once.
- *
- * Since the old east/west satellite locations are only historical, you can't
- * set your clock propagation delay settings correctly and still use
- * automatic mode. The manual says to use a compromise when setting the
- * switches. This results in significant errors. The solution; use fudge
- * time1 and time2 to incorporate corrections. If your clock is set for
- * 50 and it should be 58 for using the west and 46 for using the east,
- * use the line
- *
- * refclock truetime time1 +0.008 time2 -0.004
- *
- * This corrects the 4 milliseconds advance and 8 milliseconds retard
- * needed. The software will ask the clock which satellite it sees.
- *
+ * tells us that the GOES sats were shut down in 2005.
*/
@@ -105,18 +86,12 @@
#define DESCRIPTION "Kinemetrics/TrueTime Receiver"
/*
- * Tags which station (satellite) we see
- */
-#define GOES_WEST 0 /* Default to WEST satellite and apply time1 */
-#define GOES_EAST 1 /* until you discover otherwise */
-
-/*
* used by the state machine
*/
-enum true_event {e_Init, e_Huh, e_F18, e_F50, e_F51, e_Satellite,
- e_Poll, e_Location, e_TS, e_Max};
-static const char *events[] = {"Init", "Huh", "F18", "F50", "F51", "Satellite",
- "Poll", "Location", "TS"};
+enum true_event {e_Init, e_Huh, e_F18, e_F50, e_F51,
+ e_Location, e_TS, e_Max};
+static const char *events[] = {"Init", "Huh", "F18", "F50", "F51",
+ "Location", "TS"};
#define eventStr(x) (((int)x<(int)e_Max) ? events[(int)x] : "?")
enum true_state {s_Base, s_InqTM, s_InqTCU, s_InqGOES,
@@ -125,8 +100,8 @@ static const char *states[] = {"Base", "InqTM", "InqTCU", "InqGOES",
"Init", "F18", "F50", "Start", "Auto"};
#define stateStr(x) (((int)x<(int)s_Max) ? states[(int)x] : "?")
-enum true_type {t_unknown, t_goes, t_tm, t_tcu, t_tl3, t_Max};
-static const char *types[] = {"unknown", "goes", "tm", "tcu", "tl3"};
+enum true_type {t_unknown, t_tm, t_tcu, t_tl3, t_Max};
+static const char *types[] = {"unknown", "tm", "tcu", "tl3"};
#define typeStr(x) (((int)x<(int)t_Max) ? types[(int)x] : "?")
/*
@@ -316,10 +291,8 @@ true_receive(
struct true_unit *up;
struct refclockproc *pp;
struct peer *peer;
- unsigned short new_station;
char synced;
int i;
- int lat, lon, off; /* GOES Satellite position */
/* These variables hold data until we decide to keep it */
char rd_lastcode[BMAX];
l_fp rd_tmp;
@@ -370,49 +343,6 @@ true_receive(
}
/*
- * Timecode: "nnnnn+nnn-nnn"
- * (from GOES clock when asked about satellite position)
- */
- if ((pp->a_lastcode[5] == '+' || pp->a_lastcode[5] == '-') &&
- (pp->a_lastcode[9] == '+' || pp->a_lastcode[9] == '-') &&
- sscanf(pp->a_lastcode, "%5d%*c%3d%*c%3d", &lon, &lat, &off) == 3
- ) {
- const char *label = "Botch!";
-
- /*
- * This is less than perfect. Call the (satellite)
- * either EAST or WEST and adjust slop accodingly
- * Perfectionists would recalculate the exact delay
- * and adjust accordingly...
- */
- if (lon > 7000 && lon < 14000) {
- if (lon < 10000) {
- new_station = GOES_EAST;
- label = "EAST";
- } else {
- new_station = GOES_WEST;
- label = "WEST";
- }
-
- if (new_station != up->station) {
- double dtemp;
-
- dtemp = pp->fudgetime1;
- pp->fudgetime1 = pp->fudgetime2;
- pp->fudgetime2 = dtemp;
- up->station = new_station;
- }
- }
- else {
- /*refclock_report(peer, CEVNT_BADREPLY);*/
- label = "UNKNOWN";
- }
- true_debug(peer, "GOES: station %s\n", label);
- true_doevent(peer, e_Satellite);
- return;
- }
-
- /*
* Timecode: "Fnn"
* (from TM/TMD clock when it wants to tell us what it's up to.)
*/
@@ -535,13 +465,6 @@ true_receive(
if (!up->polled)
return;
- /* We only call doevent if additional things need be done
- * at poll interval. Currently, its only for GOES. We also
- * call it for clock unknown so that it gets logged.
- */
- if (up->type == t_goes || up->type == t_unknown)
- true_doevent(peer, e_Poll);
-
if (!refclock_process(pp)) {
refclock_report(peer, CEVNT_BADTIME);
return;
@@ -622,27 +545,6 @@ true_doevent(
true_debug(peer, "clock %s, state %s, event %s\n",
typeStr(up->type), stateStr(up->state), eventStr(event));
switch (up->type) {
- case t_goes:
- switch (event) {
- case e_Init: /* FALLTHROUGH */
- case e_Satellite:
- /*
- * Switch back to on-second time codes and return.
- */
- true_send(peer, "C");
- up->state = s_Start;
- break;
- case e_Poll:
- /*
- * After each poll, check the station (satellite).
- */
- true_send(peer, "P");
- /* No state change needed. */
- break;
- default:
- break;
- }
- /* FALLTHROUGH */
case t_tm:
switch (event) {
case e_Init:
@@ -717,8 +619,6 @@ true_doevent(
}
break;
case t_unknown:
- if (event == e_Poll)
- break;
switch (up->state) {
case s_Base:
if (event != e_Init)
@@ -728,10 +628,6 @@ true_doevent(
break;
case s_InqGOES:
switch (event) {
- case e_Satellite:
- up->type = t_goes;
- true_doevent(peer, e_Init);
- break;
case e_Init: /*FALLTHROUGH*/
case e_Huh:
sleep(1); /* wait for it */
View it on GitLab: https://gitlab.com/NTPsec/ntpsec/compare/252a8365b39a16911dfe5998fe5426613e9938af...227e0d56dac37b06f71797d86a17d07eae9491fb
---
View it on GitLab: https://gitlab.com/NTPsec/ntpsec/compare/252a8365b39a16911dfe5998fe5426613e9938af...227e0d56dac37b06f71797d86a17d07eae9491fb
You're receiving this email because of your account on gitlab.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/vc/attachments/20170917/9faea5e8/attachment.html>
More information about the vc
mailing list