What time
is it?
From
the GPS explorations described in another write-up, I was fairly
confident of my place in space, and began to think about different ways
of telling time. GPS time is straightforward. The satellites carry
atomic
clocks on board, and from the information they transmit it is possible
to extract the time with more than sufficient
accuracy to know when to take a lunch break.
I knew almost nothing about different
time standards
when I first started looking into the subject. However, I have learned
that International
Atomic Time (TAI) is the gold standard for time, and has been since
1972. It is described here. Coordinated
universal time (UTC)
is based on TAI, but
with leap seconds added. The reason for adding leap seconds is to keep
UTC within one second of Astronomical Time, which (skipping many
details...) is based on
the actual rate of earth’s
rotation. The current method of measuring
and recording Astronomical Time is UT1.
Longwave
radio station WWVB (60 KHz) transmits the time from Fort Collins
Colorado in a
slow digital format (1 bit per second). This is the same time (UTC)
that WWV
transmits (and WWVH in Hawaii). However, in addition to
atomic clock time, WWVB
also transmits the difference to the nearest 0.1 second between UTC and
UT1.
People for whom imprecision causes
distress may wish to know current astronomical time to the nearest one
tenth
second, rather than UTC from GPS or WWV or from
the computer (Network Time Protocol).
Thanks
to radio station WWVB that is possible, although not quite
straightforward. [In
truth, factors such as
propagation path influence the accuracy of time received
from WWVB.]
Clocks (physical devices) that use WWVB generally
ignore the UT1 delta and display only atomic time, either to
seconds or minutes. To access the UT1 correction in WWVB
data, one is
obliged to receive and decode the signal at a lower level than
typically provided by off-the-shelf clocks.
Few radio receivers tune as far down in
the longwave spectrum as WWVB transmits. Fortunately, 60 KHz receiver
chips
are inexpensive, for example: https://www.amazon.com/60kHz-atomic-clock-radio-module/dp/B01KH3VEGS.
[The similar one in the accompanying illustrations was purchased from
England a couple of years ago.]
Prior to undertaking the present study, one of my misconceptions was
that WWVB could only be received on the US East Coast during hours of
darkness. [My MFJ radio wristwatch synchronizes
with WWVB time, if
left on a window ledge overnight.] It would have been easy to test and
disprove this nighttime-only assumption by tuning a longwave
(or general coverage) receiver to 60 KHz, as demonstrated in the video
at the end of these paragraphs.
The photo (left) identifies components of a test setup. At first I did
not
expect to receive anything. That is why the receiver/decoder is not
connected to the Arduino in this photo. The illustration at
the beginning of this write-up and the dashed line (left)
shows where the receiver connects when actively
participating. The
(real) green wire at the bottom comes from another Arduino that is
running a WWVB simulator from: https://www.popsci.com/diy/article/2010-03/build-clock-uses-atomic-timekeeping.
The decoding program (Arduino sketch)
that I used may be found in the comments section of a YouTube video
demonstration by
‘rbton’
(https://www.youtube.com/watch?v=OeZzNehKL_Y&t=3s).
I modified this program to use Serial output in place of an LCD
display for testing and debugging. My adaptation also ignores the NTP part of the program.
Finally, to have a clearer picture of
the raw data, I stored decoded bits redundantly for display via
the serial channel.
However, I did not modify the primary decoding logic in this
very useful sketch.
Simulation:
The above clip shows decoding of simulator
output. At this point I had attempted unsuccessfully to receive and
decode
real WWVB signals. I sort of knew that it wouldn’t work, because at
this stage the receiver’s LED was blinking erratically, as if receiving
or attempting to decode background noise or static (video demo below).
Real
decodes: It’s
always the antenna! I moved the small ferrite loop to a nearby window
ledge. The window faces west (toward Fort Collins) although I doubt
that matters. My plan was to start the decoder after dark and hope that
it would decode something during the wee hours. The first
decode to pass the program’s validity checker came at 11:07 PM EST.
As shown, the current [at the time of this writing] UT1
(astronomical time) correction (called DUT1 ) is +0.2 seconds. Between
this first decode and daybreak just
over
30 valid decodes were obtained,
the majority coming in the last few hours of
darkness. The number of decodes was disappointing, however. I had
expected more, given that the radio wristwatch with its miniscule
internal loop antenna is able to receive WWVB at night. I
decided
to try one more change to the test setup, namely a different slightly
larger ferrite loop, taped to a block of wood in order to clear the
window frame. At the same time I strengthened the program’s validity
check, although the original one (based on 13 bits) had not falsely
passed any invalid decodes.
To my astonishment this slightly revised
setup
produced valid decodes while it was still
daylight—4
PM Eastern time (2 PM Mountain time) on a sunny afternoon. Up until
this point I had thought that only nighttime reception was possible,
having not yet tuned an appliance receiver to the WWVB frequency.
Before
this test (screen capture above), the sketch was modified to
display the bit stream of the minute corresponding to
the decode, in a shorter more readable format. A
comment in the original sketch explains, “WWVB sends the time AFTER the
time mark, so we need to add a minute for the correct time.” Between 4
and 8 PM, about 60% of decode tries
were valid. This percentage subsequently decreased, so it is possible
that reception was unusually good on this particular afternoon.
—Moderately long
sequences of valid decodes were also observed in the pre-dawn hours.
The
revised validity checker occasionally reports a false
negative. In other words, it detects a bit error when the program has
correctly decoded day and time, and other values of interest,
for the same minute.
Summary:
This brief exploration yielded more than the usual share of surprises,
and clarified some previously puzzling things for me. For example, I
had wondered how the MFJ watch was able to detect spring and fall time
changes, and adjust the hour hand accordingly, although not exactly on
the specified 2 AM hour. Daylight Saving Time information is part of
the WWVB message. (It is a 2-bit code: 00=Not DST, 10=DST begins today,
11=During DST, 01=DST ends today.) I was also curious how the radio
watch would know when to trust a time decode. (The watch only needs
hour and minute, and of course DST, but not day or year.) A guess would
be that it reads the mark and reserved bits, same as our first validity
check. It could perform more complex checks, such as requiring decoded
time to increment correctly on two or more successive
decodes. —I
don’t know how it actually works.
If the tenths-of-seconds communicated by
WWVB’s UT1 correction is not precise enough,
one can obtain the exact duration of any day (rotation of the earth) by
visiting https://www.timeanddate.com/time/earth-rotation.html.
According to experts the main cause for the slowing of earth’s rotation
is tidal friction: http://www.physlink.com/education/askexperts/ae695.cfm.
Curiously there will come a point when this particular cause is no
longer operative—billions of years hence, they say!
Time Demo: wwvb.mp4
Project descriptions on this page are intended for entertainment only.
The author makes no claim as to the accuracy or completeness of the
information presented. In no event will the author be liable for any
damages, lost effort, inability to carry out a similar project, or to
reproduce a claimed result, or anything else relating to a decision to
use the information on this page.
