NameDateSize

..28-Jun-202039

clock.awkH A D18-Aug-201610.2 KiB

dupe.awkH A D18-Aug-201679

ensemble.awkH A D18-Aug-2016717

ensemble.SH A D18-Aug-2016377

etf.awkH A D18-Aug-2016521

etf.SH A D18-Aug-2016730

itf.awkH A D18-Aug-2016546

itf.SH A D18-Aug-2016316

loop.awkH A D18-Aug-20161.2 KiB

loop.SH A D18-Aug-2016372

loop_summaryH A D18-Aug-201618

peer.awkH A D18-Aug-20162.1 KiB

psummary.awkH A D18-Aug-20163.4 KiB

READMEH A D18-Aug-20161.8 KiB

README.statsH A D18-Aug-20169.1 KiB

README.timecodesH A D18-Aug-20165.7 KiB

summary.shH A D18-Aug-20161.8 KiB

tdata.awkH A D18-Aug-20161.1 KiB

tdata.SH A D18-Aug-2016303

README

1Statistics processing scripts (README)
2
3This directory contains a number of scripts for use with the filegen
4facility. Those files ending in .awk are for the Unix awk utility, while
5those ending in .sh are for the csh utility. Normally, the summary.sh
6script is called from a cron job once per day. This script processes the
7daily loopstats, peerstats and clockstats files produced by the daemon,
8updates the loop_summary, peer_summary and clock_summary archive files,
9and deletes the daily files.
10
11In the case of the Austron 2201A GPS receiver, the clockstats file
12contains a wealth of additional monitoring data. These data are summarized
13and writted to the clock_summary file, then a series of special files are
14constructed for later processing by the S utility.
15
16The summary.sh script invokes a number of awk scripts to actually produce
17the data. This may result in multiple scans of the same input file.
18The input file is deleted after processing. In fact, the shell scripts will
19process all input files found of the correct type in chronological order,
20deleting each one as it is scanned, except the current day file.
21
22The summary.sh script can produce input files for the S utility, if it
23is found on the search path. This utility makes PostScript graphs of the
24loopstats data for each day, as well as various statistics produced by
25the Austorn 220aA GPS receiver. The S utility is automatically run
26as a background job. Its control files have the .S extension.
27
28The psummary.awk script can be used to scan the peer_summary file and
29construct an historical reprise of the daily summaries. 
30
31The file formats are documented in the README.stats file and in the
32scripts themselves. Further detail on the radio clock ASCII timecode
33formats and related data are in the README.timecode file.
34
35David L. Mills
36University of Delaware
37mills@udel.edu
381 November 1993
39Revised 12 April 1994 
40

README.stats

1Statistics file formats (README.stats)
2
3The xntp3 daemon can produce a variety of statistics files which are
4useful for maintenance, evaluation and retrospective calibration
5purposes. See the xntpd.8 man page for instructions on how to configure
6this feature. Since these files can become rather large and cumbersome,
7they are ordinarily reduced to summary form by running the summary.sh
8shell script once per day, week or month, as appropriate. There are
9three file collections presently defined: peerstats, loopstats and
10clockstats, each of which is described in this note.
11
12peerstats
13
14The following data are collected in the peerstats files. The files are
15reduced to summary data using the peer.sh shell script. See the peer.awk
16script for further information. A line in the file is produced upon
17reception of each valid update from a configured peer.
18
19  49236 30.756 140.173.96.1 9474 0.000603 0.37532
20
21  49236             modified Julian day number
22  30.756            time of day (s) past midnight UTC
23  140.173.96.1      peer identifier (IP address or receiver identifier)
24  9474              peer status word (hex) (see NTP specification)
25  0.000603          offset (s)
26  0.08929           delay (s)
27  0.37532           dispersion (s)
28
29loopstats
30
31The following data are collected in the loopstats files. The files are
32reduced to summary data using the loop.sh shell script. See the loop.awk
33script for further information. A line in the file is produced at each
34valid update of the local clock.
35
36  49236 11.897 -0.000004 -35.9384 0
37
38  49236             modified Julian day number
39  11.897            time of day (s) past midnight UTC
40  -0.000004         time offset (s)
41  -35.9384          frequency offset (ppm)
42  0                 phase-lock loop time constant
43
44clockstats
45
46The following data are collected in the clockstats files. The files are
47reduced to summary data using the clock.sh shell script, which also
48updates the ensemble, etf, itf and tdata data files as well. See the
49clock.awk, ensemble.awk, etf.awk, itf.awk and tdta.awk scripts for
50further information. A line in the file is produced at each valid update
51received from a configured radio clock. Data are at present recorded for
52several radios. The first part of each data line is similar for all
53radios, e.g.:
54
55  49234 60517.826 127.127.4.1   93 247 16:48:21.814
56
57  49234             modified Julian day number
58  60517.826         time of day (s) past midnight UTC
59  127.127.4.1       receiver identifier (Spectracom 8170/Netclock-2)
60  93 247 16:48:21.814  timecode (format varies)
61
62In the case of the Austron GPS receiver, a good deal of additional
63information is extracted from the radio, as described below. The formats
64shown consist of one line with all the fields shown in order. The
65timecode formats specific to each radio follow. See the file
66README.timecodes for detailed information on the timecode formats used
67by these radios.
68
69Spectracom 8170/Netclock-2 WWVB receiver
70
71  49234 60517.826 127.127.4.1 ?A93 247 16:48:21.814
72
73  The '?' and 'A' characters are present only when the receiver is
74  unsynchronized; otherwise, they are replaced by space ' ' characters.
75
76IRIG audio decoder
77
78  49234 60517.826 127.127.6.0 247 16:48:21?
79
80  The '?' character is present only when the receiver is unsynchronized.
81
82Austron 2200A/2201A GPS receiver
83
84  49234 60580.843 127.127.10.1 93:247:16:49:24.814?
85
86  The '?' character is present only when the receiver is unsynchronized.
87
88Depending on the installed options, the Austron 2200A/2201A recognizes a
89number of special commands that report various data items. See the
90refclock_as2201.c source module for a list of the commands used. These
91data are collected only if the following line is included in the
92configuration file ntp.conf:
93
94  fudge 127.127.10.1 flag4 1    # enable extended statistics collection
95
96The format of each data line returned is summarized in the following
97list.
98
99External time/frequency data (requires input buffer option IN)
100
101These data determine the deviations of external time/frequency inputs
102relative to receiver oscillator time. The following data are typical
103using an external cesium oscillator PPS and 5-MHz outputs.
104
105  49234 60580.843 127.127.10.1 93:247:16:49:24.814 ETF
106
107  -85.9             time interval (ns)
108  -89.0             average time interval (ns)
109  4.0               time interval sigma (ns)
110  +1.510E-11        time interval rate
111  -4.500E-11        deltaf/f
112  +1.592E-11        average deltaf/f
113  5.297E-13         sigma deltaf/f
114  500               number of samples
115
116Model and option identifiers
117
118These data show the receiver model number and option configuration.
119
120  49234 60708.848 127.127.10.1 93:247:16:51:32.817 ID;OPT;VER
121
122  GPS 2201A         model ident (must be "GPS 2200A" or "GPS 2201A")
123  TTY1              rs232 option present (required)
124  TC1               IRIG option present (optional)
125  LORAN             LORAN assist option present (optional)
126  IN                input buffer option present (optional)
127  OUT1              output buffer option present (required)
128  B.00              data processor software version ("B.00" or later)
129  B.00              signal processor software version ("B.00" or later)
130  28-Apr-93         software version date ("28-Apr-93" or later)
131
132Internal time/frequency data
133
134These data determine the deviations of the receiver oscillator with
135respect to satellite time.
136
137  49234 60564.846 127.127.10.1 93:247:16:49:08.816 ITF
138
139  COCO              current mode (must be "COCO")
140  0                 code coast mode (must be zero)
141  +6.6152E-08       code sigma (s)
142  -3.5053E-08       code delta t (s)
143  -4.0361E-11       deltat/t
144  -6.4746E-11       oscillator ageing rate
145  500.00            loop time constant
146  4.984072          electrical tuning (V)
147
148GPS/LORAN ensemble data (requires LORAN assist option LORAN)
149
150These data determine the deviations and weights to calculate ensemble
151time from GPS and LORAN data.
152
153  49234 60596.852 127.127.10.1 93:247:16:49:40.812 LORAN ENSEMBLE
154
155  +9.06E-08         GPS t (s)
156  +3.53E-08         GPS sigma (s)
157  .532              GPS weight
158  +3.71E-08         LORAN t (s)
159  +3.76E-08         LORAN sigma (s)
160  .468              LORAN weight
161  +6.56E-08         ensemble t
162  +6.94E-08         ensemble sigma (s)
163
164LORAN stationkeeping data (requires LORAN assist option LORAN)
165
166These data determine which stations of the LORAN chain are being
167tracked, together with individual signal/noise ratios, deviations and
168weights.
169
170  49234 60532.850 127.127.10.1 93:247:16:48:36.820 LORAN TDATA
171
172  M                 station identifier; data follows
173  OK                status (must be "OK" for tracking)
174  0                 cw flag
175  0                 sw flag
176  1162.17           time of arrival
177  -4.6              snr (-30.0 if not "OK" status)
178  1.67E-07          2-sample phase-time deviation
179  .507              weight (included only if "OK" status)
180  W AQ 0 0 3387.80 -31.0  station identifier and data
181  X OK 0 0 1740.27 -11.2 2.20E-07 .294  station identifier and data
182  Y OK 0 0 2180.71 -4.6 2.68E-07 .198  station identifier and data
183  Z CV 0 0 3392.94 -30.0  station identifier and data
184
185Oscillator status and environment
186
187These data determine the receiver oscillator type, mode, status and
188environment. Nominal operating conditions are shown below.
189
190  49234 60628.847 127.127.10.1 93:247:16:50:12.817 OSC;ET;TEMP
191
192  1121 Software     Control  oscillator model and mode (must be
193                    "Software Control")
194  Locked            status (must be "Locked")
195  4.979905          electrical tuning (V)
196  44.81             oscillator cavity temperature
197
198Receiver position, status and offsets
199
200These data determine the receiver position and elevation, together with
201programmable delay corrections for the antenna cable and receiver.
202
203  49234 60788.847 127.127.10.1 93:247:16:52:52.817 POS;PPS;PPSOFF
204
205  +39:40:48.425     receiver latitude (N)
206  -075:45:02.392    receiver longitude (E)
207  +74.09            receiver elevation (m)
208  Stored            position status (must be "Stored")
209  UTC               PPS/PPM alignment (must be "UTC")
210  0                 receiver delay (ns) (should be zero for calibrated
211                    receiver)
212  200               cable delay (ns)
213  0                 user time bias (ns) (must be zero)
214
215Satellite tracking status
216
217These data determine how many satellites are being tracked. At the
218present state of constellation development, there should be at least
219three visible satellites in view. Much of the time the maximum of
220seven are being tracked; rarely this number drops to two.
221
222  49234 60612.850 127.127.10.1 93:247:16:49:56.820 TRSTAT
223
224  24 T              satellite prn and status (T = track, A = acquire)
225  16 A 13 T 20 T 18 T 07 T 12 T  list continued
226
227UTC leap-second information
228
229These data determine when the next leap second is to occur. The exact
230method to use is obscure.
231
232  49234 60548.847 127.127.10.1 93:247:16:48:52.818 UTC
233
234  -1.2107E-08       A0 term (s)
235  -1.2790E-13       A1 term (s)
236  +9.0000E+00       current leap seconds (s)
237  +2.0480E+05       time for leap seconds (s)
238  +2.0100E+02       week number for delta leap (weeks)
239  +1.9100E+02       week number for future leap (weeks)
240  +4.0000E+00       day number for future leap (days)
241  +9.0000E+00       future leap seconds (s)
242
243David L. Mills
244University of Delaware
245mills@udel.edu
24623 October 1993
247

README.timecodes

1Radio Timecode Formats (README.timecodes)
2
3Following are examples of the serial timecode formats used by various
4timecode receivers as given in the instruction manuals. These examples
5are intended only for illustration and not as the basis of system
6design. The following symbols are used to identify the timecode
7character that begins a subfield. The values given after this symbol
8represent the character offset from the beginning of the timecode string
9as edited to remove control characters.
10
11C         on-time character (start bit)
12Y         year of century
13T         time of day
14D         day of year or month/day
15A         alarm indicator (format specific)
16Q         quality indicator (format specific)
17<LF>      ASCII line feed (hex 0a)
18<CR>      ASCII carriage return (hex 0d)
19<SP>      ASCII space (hex 20)
20
21In order to promote uniform behavior in the various implementations, it
22is useful to have a common interpretation of alarm conditions and signal
23quality. When the alarm indicator it on, the receiver is not operating
24correctly or has never synchronized to the broadcast signal. When the
25alarm indicator is off and the quality indicator is on, the receiver has
26synchronized to the broadcast signal, then lost the signal and is
27coasting on its internal oscillator.
28
29In the following uppercase letters, punctuation marks and spaces <SP>
30stand for themselves; lowercase letters stand for fields as described.
31Special characters other than <LF>, <CR> and <SP> are preceded by ^.
32
33Spectracom 8170 and Netclock/2 WWV Synchonized Clock (format 0)
34
35"<CR><LF>i  ddd hh:mm:ss  TZ=zz<CR><LF>"
36 C       A  D   T
37
38     poll: ?; offsets: Y = none, D = 3, T = 7, A = 0, Q = none
39     i = synchronization flag (<SP> = in synch, ? = out synch)
40     ddd = day of year
41     hh:mm:ss = hours, minutes, seconds
42     zz = timezone offset (hours from UTC)
43
44     Note: alarm condition is indicated by other than <SP> at A, which
45     occurs during initial synchronization and when received signal has
46     been lost for about ten hours
47
48     example: "   216 15:36:43  TZ=0"
49               A  D   T
50
51Netclock/2 WWV Synchonized Clock (format 2)
52
53"<CR><LF>iqyy ddd hh:mm:ss.fff ld"
54 C       AQY  D   T
55
56     poll: ?; offsets: Y = 2, D = 5, T = 9, A = 0, Q = 1
57     i = synchronization flag (<SP> = in synch, ? = out synch)
58     q = quality indicator (<SP> < 1ms, A < 10 ms, B < 100 ms, C < 500
59     ms, D > 500 ms)
60     yy = year (as broadcast)
61     ddd = day of year
62     hh:mm:ss.fff = hours, minutes, seconds, milliseconds of day
63     l = leap-second warning (L indicates leap at end of month)
64     d = standard/daylight time indicator (<SP> standard, D daylight)
65
66     Note: alarm condition is indicated by other than <SP> at A, which
67     occurs during initial synchronization and when received signal has
68     been lost for about ten hours; unlock condition is indicated by
69     other than <SP> at Q, with time since last lock indicated by the
70     letter code A < 13 min, B < 1.5 hr, C < 7 hr, D > 7 hr.
71
72     example: "  92 216 15:36:43.640  D"
73               AQ   D   T
74
75TrueTime 468-DC Satellite Synchronized Clock (and other TrueTime
76receivers)
77
78"<CR><LF><^A>ddd:hh:mm:ssq<CR>"
79              D   T       QC
80
81     poll: none; offsets: Y = none, D = 0, T = 4, A = 12, Q = 12
82     hh:mm:ss = hours, minutes, seconds
83     q = quality/alarm indicator (<SP> = locked, ? = alarm)
84
85     Note: alarm condition is indicated by ? at A, which occurs during
86     initial synchronization and when received signal is lost for an
87     extended period; unlock condition is indicated by other than <SP>
88     at Q
89
90     example: "216:15:36:43 "
91               D   T       Q
92
93Heath GC-1000 Most Accurate Clock (WWV/H)
94
95"<CR>hh:mm:ss.f     dd/mm/yy<CR>"
96 C   T        A     D
97
98     poll: none; offsets: Y = none, D = 15, T = 0, A = 9, Q = none
99     hh:mm:ss = hours, minutes, seconds
100     f = deciseconds (? when out of spec)
101     dd/mm = day, month
102     yy = year of century (from DIPswitches)
103
104     Note: 0?:??:??.? is displayed before synch is first established and
105     hh:mm:ss.? once synch is established and then lost again for about
106     a day.
107
108     example: "15:36:43.6     04/08/91"
109               T        A     D     Y
110
111PST/Traconex 1020 Time Source (WWV/H) (firmware revision V4.01)
112
113"frdzycchhSSFTttttuuxx<CR>" "ahh:mm:ss.fffs<CR>" "yy/dd/mm/ddd<CR>"
114          A   Q               T                   Y  D
115
116     poll: "QMQDQT"; offsets: Y = 0, D = 3 T = 1,, A = 11, Q = 13
117     f = frequency enable (O = all frequencies enabled)
118     r = baud rate (3 = 1200, 6 = 9600)
119     d = features indicator (@ = month/day display enabled)
120     z = time zone (0 = UTC)
121     y = year (5 = 1991)
122     cc = WWV propagation delay (52 = 22 ms)
123     hh = WWVH propagation delay (81 = 33 ms)
124     SS = status (80 or 82 = operating correctly)
125     F = current receive frequency (1-5 = 2.5, 5, 10, 15, 20 MHz)
126     T = transmitter (C = WWV, H = WWVH)
127     tttt = time since last update (minutes)
128     uu = flush character (03 = ^C)
129     xx = 94 (unknown) (firmware revision X4.01.999 only)
130
131     a = AM/PM indicator (A = AM, P = PM, <SP> - 24-hour format)
132     hh:mm:ss.fff = hours, minutes, seconds, milliseconds of day
133     s = daylight-saving indicator (<SP> standard, D daylight)
134
135     yy = year of century (from DIPswitches)
136     dd/mm/ddd = day of month, month of year, day of year
137
138     Note: The alarm condition is indicated by other than ? at A, which
139     occurs during initial synchronization and when received signal is
140     lost for an extended period. A receiver unlock condition is
141     indicated by other than "0000" in the tttt subfield at Q.
142
143     example: "O3@055281824C00000394 91/08/04/216  15:36:43.640"
144                             T       Y        D    T
145
146David L. Mills
147University of Delaware
148mills@udel.edu
14923 October 1993
150