clements@BBN.COM (02/27/90)
My call for interest in building the new WWV/WWVH time code generators
has produced a total of one other enthusiast from the bushes. He's on
the left coast and I'm on the right coast, but we're talking about it.
I got the spec from the procurement office. It has 58 pages of legalistic
boiler plate, with many more pages included by reference, and 15 pages
of technical spec. This has convinced me that it would be silly to
try to form the "Friends of WWV/WWVH, Inc." that I suggested to build
the TCGs. The legalisms are far too intimidating for me. But we might
just build them anyway as a gift to the government if there is no
bidder that they can afford. It turns out the deadline for bidders to
reply is this Thursday.
Anyhow, here is a portion of the spec of direct relevance to NTP-ers.
It describes how the WWV/WWVH time code will be enhanced to deal better
with Daylight Saving Time and with Leap Seconds. FYI.
[Excerpt from spec, Attachment 1 to Department of Commerce Solicitation
number 52RANB00C059, issued 1-23-90]
Attachment 1
Page 1 of 15
Revised 11/22/89
SPECIFICATIONS
TIME CODE GENERATOR/PROGRAMMER
1.0 Scope
This specification establishes the requirements for two time code
generator/programmer systems that will be used to generate precision
timing signals for use by NIST standard time and frequency stations WWV
and WWVH. Each of these systems will consist of:
(1) Three (3) time code generator/programmer units, and
(2) Software and interfacing hardware to provide for entering commands
to the time code generators through a computer.
[...]
2.5.6 Time Code Generator - BCD Format Table
Second Data
00 low subcarrier
01 0
02 0
03 0
04 0
05 0
06 0
07 0
08 0
09 position marker 1
10 minute 1
11 minute 2
12 minute 4
13 minute 8
14 0
15 minute 10
16 minute 20
17 minute 40
18 0
19 position marker 2
20 hour 1
21 hour 2
22 hour 4
23 hour 8
24 0
25 hour 10
26 hour 20
27 0
28 0
29 position marker 3
30 day 1
31 day 2
32 day 4
33 day 8
34 0
35 day 10
36 day 20
37 day 40
38 day 80
39 position marker 4
40 day 100
41 day 200
42 0
43 (new) leap second warning
44 (new) Daylight Saving Time indicator #2
45 (new) year 1
46 (new) year 2
47 (new) year 4
48 (new) year 8
49 position marker 5
50 UT1 sign
51 (new) year 10
52 (new) year 20
53 (new) year 40
54 (new) year 80
55 Daylight Saving Time indicator #1
56 UT1 .1
57 UT1 .2
58 UT1 .4
59 position marker 0
Note: Daylight Saving Time indicator bits #1 and #2 are scheduled for
change by the operator. The normal procedure is for DST indicator
bit #1 to change at 0000 UTC on the day of a change to or from
Daylight Saving Time and DST indicator bit #2 to change in the same
way 24 hours later at 0000 UTC on the day after the time change.
When both bits are set to "0", standard time is in effect and it is
not a day of time change; when both bits are set to "1", Daylight
Saving Time is in effect and it is not a day of time change. Each
receiver can then interpret these bits unambiguously so as to change
onto or off of Daylight Saving Time at 2:00 AM receiver local time.
Note: Leap seconds are always inserted/deleted at the last second of the
UTC month. Leap second warning is scheduled to be turned on at any
time during the month to which a leap second is being added, and is
automatically turned off immediately after the leap second. The UT1
bits also automatically change after a leap second. Incremental UT1
changes may be scheduled by the operator at any time.
[End of excerpt from spec.]
Again, the above is the spec for the NEW generators, not what exists
today. Today the DUT1 stuff doesn't change automatically, for example.
And there is no leap second warning or year info.
Not clear how a single leap second warning bit helps you when the
leap second is negative. Does anyone know whether negative leap
seconds are expected to be needed in the next century or so?
/Rcc
Bob Clements, K1BC, clements@bbn.comMills@udel.edu (02/27/90)
Bob, Tnx for the info. As for negative leaps, it does not seem likely during our lives or the lives of the timecode generator that such would happen barring impact of a very large meteorite, in shich case there may be nothing left to broadcast timecodes to. I'd like to find out if this is in fact the format allegedly used on WWVB now. I'd also like to find out what codes are used in Europe. Dave
clements@BBN.COM (02/28/90)
> [...] I'd like to find out if this is in fact the format allegedly used > on WWVB now. [...] > Dave WWVB's format is quite different. The MSB-to-LSB of each digit is reversed, the UT1 sign bit is three bits, and all the fields are in different parts of the minute. As to whether the Leap and Year info is there, I have tried again to read WWVB under the line noise, under different local weather (moisture) conditions and had no luck. /Rcc
William Armitage <wja%computer-science.nottingham.ac.uk@NSFnet-Relay.AC.UK> (02/28/90)
> I'd like to find out if this is in fact the format allegedly used > on WWVB now. I'd also like to find out what codes are used in > Europe. Here's the header file describing the layout of the codes on Rugby MSF 60KHz. This is the slow code consisting of keying off the carrier for 100 or 200ms each second. Some seconds carry a second bit by keying from 200ms to 300ms off the second. Data is BCD with the Most significant bit first. The data sequence is spread over a minute with the minute marked by the 01111110 pattern, the data is for the following minute mark. There's a fast code burst on the minute but i don't have anything to decode it with, the slow code is going into a modem port on a sun. Currently the signal is too noisy for production use. ------------------------ msf.h --------------------------------- /* * Layout of slow code transmited by the Rugby 60Khz MSF * * taken from the Rewbichron2 constriuction article in * Radio and Electronics World * * Anybody have a description of the DUT1 code? * * William Armitage <wja@cs.nott.ac.uk> July 89 */ #define MSF_FASTCODE 0 /* high speed data */ /* * first level data bits * 100ms to 200ms after keyup - on = 0 * * date information - starts at second 17, there are some DUT codes first */ #define MSFS1_YEAR_MSB 17 /* year - since 1900 (Most significan BCD)*/ #define MSFS1_YEAR_MSBLEN 4 #define MSFS1_YEAR_LSB 21 /* least significant BCD */ #define MSFS1_YEAR_LSBLEN 4 #define MSFS1_MONTH_MSB 25 /* month - (1 - 12) */ #define MSFS1_MONTH_MSBLEN 1 #define MSFS1_MONTH_LSB 26 #define MSFS1_MONTH_LSBLEN 4 #define MSFS1_DAY_MSB 30 /* day of month */ #define MSFS1_DAY_MSBLEN 2 #define MSFS1_DAY_LSB 32 #define MSFS1_DAY_LSBLEN 4 #define MSFS1_DOW_LSB 36 /* day of week (sun = 0) */ #define MSFS1_DOW_LSBLEN 3 #define MSFS1_HOUR_MSB 39 /* hour */ #define MSFS1_HOUR_MSBLEN 2 #define MSFS1_HOUR_LSB 41 #define MSFS1_HOUR_LSBLEN 4 #define MSFS1_MIN_MSB 45 /* minute */ #define MSFS1_MIN_MSBLEN 3 #define MSFS1_MIN_LSB 48 #define MSFS1_MIN_LSBLEN 4 #define MSFS1_SYNC 52 /* framing pattern 01111110 */ #define MSFS1_SYNCLAST 59 /* final zero */ #define MSFS1_SYNC_LEN 8 /* * second level data bits * 200ms to 300ms after keyup - on = 0 * * parity checks and British summer time bits, * starts on second 54 in minute * parity is odd */ #define MSFS2_YEAR_CHECK 54 #define MSFS2_DAYMONTH_CHECK 55 #define MSFS2_DOW_CHECK 56 #define MSFS2_HOURMIN_CHECK 57 #define MSFS2_BST 58