630 lines
30 KiB
Plaintext
630 lines
30 KiB
Plaintext
The Clock Mini-HOWTO
|
|
Ron Bean, rbean@execpc.com
|
|
v2.1, November 2000
|
|
|
|
How to set and keep your computer's clock on time.
|
|
______________________________________________________________________
|
|
|
|
Table of Contents
|
|
|
|
|
|
1. Introduction
|
|
|
|
1.1 Does Anybody Really Know What Time It Is?
|
|
1.2 Where to Find Stuff: "The Usual Places"
|
|
1.3 Acknowledgements
|
|
|
|
2. How Linux Keeps Track of Time
|
|
|
|
2.1 Basic Strategies
|
|
2.2 Potential Conflicts
|
|
2.3 Should the RTC use Local Time or UTC, and What About DST?
|
|
2.4 How Linux keeps Track of Time Zones
|
|
2.5 The Bottom Line
|
|
|
|
3. Software
|
|
|
|
3.1 Clock(8) and Hwclock(8)
|
|
3.2 Adjtimex(8)
|
|
3.3 Xntpd and ntpd: the Network Time Protocol
|
|
3.4 Chrony
|
|
3.5 Clockspeed
|
|
|
|
4. Radio Clocks
|
|
|
|
4.1 CHU and the "Gadget Box"
|
|
4.2 WWV and the "Most Accurate Clock"
|
|
4.3 GPS and the "Totally Accurate Clock"
|
|
4.4 Low-frequency Time Signals: DCF77, MSF(Rugby), WWVB
|
|
|
|
|
|
______________________________________________________________________
|
|
|
|
1. Introduction
|
|
|
|
1.1. Does Anybody Really Know What Time It Is?
|
|
|
|
The Real-Time-Clock (RTC) chips used on PC motherboards are
|
|
notoriously inaccurate, usually gaining or losing the same amount of
|
|
time each day. Linux provides a simple way to correct for this in
|
|
software, which can make the clock *very* accurate, even without an
|
|
external time source. But most people don't know how to set it up, for
|
|
several reasons:
|
|
|
|
|
|
· It's not mentioned in most of the general documentation on how to
|
|
set up linux, and it can't be set up automatically (unless you have
|
|
an external time source), so the default is not to use it.
|
|
|
|
· If you type "man clock" you may get the man page for clock(3),
|
|
which is not what you want. Try "man 8 clock" or "man 8 hwclock"
|
|
(some distributions search the man pages in numerical order if you
|
|
don't give a section number, others search in the order specified
|
|
in /etc/man.config).
|
|
|
|
· Most people don't seem to care what time it is anyway.
|
|
|
|
· Those few who do care often want to sync the system clock to an
|
|
external time source, such as a network time server or radio clock.
|
|
This makes the accuracy of the RTC (mostly) irrelevant.
|
|
|
|
This mini-HOWTO describes the low-tech approach (which can be very
|
|
accurate by itself), and provides pointers to several more
|
|
sophisticated options. In most cases the documentation is well
|
|
written, so I'm not going to repeat that information here.
|
|
|
|
Previous versions included detailed instructions for the old clock(8)
|
|
program for anyone still running an older system, but I've dropped
|
|
that section because most distributions now use hwclock(8) instead,
|
|
which has much better documentation. If you still want a copy of the
|
|
clock(8) instructions I can email them to you, but read the section on
|
|
hwclock(8) first.
|
|
|
|
|
|
Note
|
|
You must be logged in as "root" to run any program that affects
|
|
the RTC or the system time, which includes most of the programs
|
|
described here. If you normally use a graphical interface for
|
|
everything, you may also need to learn some basic unix shell
|
|
commands.
|
|
|
|
|
|
Note
|
|
If you run more than one OS on your machine, you should only let
|
|
one of them set the RTC, so they don't confuse each other. The
|
|
exception is the twice-a-year adjustment for Daylight Saving(s)
|
|
Time (see the section on DST for details).
|
|
|
|
If you run a dual-boot system that spends a lot of time running
|
|
Windows, you may want to check out some of the clock software
|
|
available for that OS instead. Follow the links on the NTP website at
|
|
<http://www.eecis.udel.edu/~ntp/software.html>. Many of the radio
|
|
clocks mentioned here include software for Windows.
|
|
|
|
1.2. Where to Find Stuff: "The Usual Places"
|
|
|
|
In some places I've mentioned that software can be downloaded from
|
|
"the usual places", which means any place you could download a
|
|
complete Linux system if you didn't get it on a CD-ROM. In the old
|
|
days that meant the ftp archive at sunsite.unc.edu, and various mirror
|
|
sites around the world. That site has been renamed
|
|
<http://metalab.unc.edu/linux/> (since Sun no longer sponsors it).
|
|
Some distributions also have their own websites, which may include a
|
|
lot of this stuff.
|
|
|
|
I assume most people get Linux on CD these days, and those CDs often
|
|
include software that is not part of the default installation, so you
|
|
may already have some of the programs mentioned here without knowing
|
|
it.
|
|
|
|
The latest version of this mini-HOWTO can be found at the home of the
|
|
Linux Documentation Project, which is currently
|
|
<http://www.linuxdoc.org/> (and is also reachable from the metalab
|
|
site mentioned above). I think all the old links are now forwarded to
|
|
this one.
|
|
|
|
All HOWTOs are written in SGML and converted to various other formats
|
|
by standardized conversion programs. Most people seem to want the HTML
|
|
version, which is at <http://www.linuxdoc.org/HOWTO/mini/Clock.html>.
|
|
Revision history can be found as comments in the SGML source. Most
|
|
Linux distributions install a complete set of HOWTO's in
|
|
/usr/doc/HOWTO/ and /usr/doc/HOWTO/mini.
|
|
|
|
1.3. Acknowledgements
|
|
|
|
This mini-HOWTO has been greatly improved thanks to various people who
|
|
have sent me email since the first version in 1996. In some cases
|
|
they wrote with questions but ended up giving me as much information
|
|
as I gave them. Unfortunately I haven't compiled a list of names
|
|
(maybe next time). You know who you are :-).
|
|
|
|
2. How Linux Keeps Track of Time
|
|
|
|
2.1. Basic Strategies
|
|
|
|
A Linux system actually has two clocks: One is the battery powered
|
|
"Real Time Clock" (also known as the "RTC", "CMOS clock", or "Hardware
|
|
clock") which keeps track of time when the system is turned off but is
|
|
not used when the system is running. The other is the "system clock"
|
|
(sometimes called the "kernel clock" or "software clock") which is a
|
|
software counter based on the timer interrupt. It does not exist when
|
|
the system is not running, so it has to be initialized from the RTC
|
|
(or some other time source) at boot time. References to "the clock" in
|
|
the ntpd documentation refer to the system clock, not the RTC.
|
|
|
|
The two clocks will drift at different rates, so they will gradually
|
|
drift apart from each other, and also away from the "real" time. The
|
|
simplest way to keep them on time is to measure their drift rates and
|
|
apply correction factors in software. Since the RTC is only used when
|
|
the system is not running, the correction factor is applied when the
|
|
clock is read at boot time, using clock(8) or hwclock(8). The system
|
|
clock is corrected by adjusting the rate at which the system time is
|
|
advanced with each timer interrupt, using adjtimex(8).
|
|
|
|
A crude alternative to adjtimex(8) is to have chron run clock(8) or
|
|
hwclock(8) periodically to sync the system time to the (corrected)
|
|
RTC. This was recommended in the clock(8) man page, and it works if
|
|
you do it often enough that you don't cause large "jumps" in the
|
|
system time, but adjtimex(8) is a more elegant solution. Some
|
|
applications may complain if the time jumps backwards.
|
|
|
|
The next step up in accuracy is to use a program like ntpd to read the
|
|
time periodically from a network time server or radio clock, and
|
|
continuously adjust the rate of the system clock so that the times
|
|
always match, without causing sudden "jumps" in the system time. If
|
|
you always have a network connection at boot time, you can ignore the
|
|
RTC completely and use ntpdate (which comes with the ntpd package) to
|
|
initialize the system clock from a time server-- either a local server
|
|
on a LAN, or a remote server on the internet. But if you sometimes
|
|
don't have a network connection, or if you need the time to be
|
|
accurate during the boot sequence before the network is active, then
|
|
you need to maintain the time in the RTC as well.
|
|
|
|
2.2. Potential Conflicts
|
|
|
|
It might seem obvious that if you're using a program like ntpd, you
|
|
would want to sync the RTC to the (corrected) system clock. But this
|
|
turns out to be a bad idea if the system is going to stay shut down
|
|
longer than a few minutes, because it interferes with the programs
|
|
that apply the correction factor to the RTC at boot time.
|
|
|
|
If the system runs 24/7 and is always rebooted immediately whenever
|
|
it's shut down, then you can just set the RTC from the system clock
|
|
right before you reboot. The RTC won't drift enough to make a
|
|
difference in the time it takes to reboot, so you don't need to know
|
|
its drift rate.
|
|
|
|
Of course the system may go down unexpectedly, so some versions of the
|
|
kernel sync the RTC to the system clock every 11 minutes if the system
|
|
clock has been adjusted by another program. The RTC won't drift enough
|
|
in 11 minutes to make any difference, but if the system is down long
|
|
enough for the RTC to drift significantly, then you have a problem:
|
|
the programs that apply the drift correction to the RTC need to know
|
|
*exactly* when it was last reset, and the kernel doesn't record that
|
|
information anywhere.
|
|
|
|
Some unix "traditionalists" might wonder why anyone would run a linux
|
|
system less than 24/7, but some of us run dual-boot systems with
|
|
another OS running some of the time, or run Linux on laptops that have
|
|
to be shut down to conserve battery power when they're not being used.
|
|
Other people just don't like to leave machines running unattended for
|
|
long periods of time (even though we've heard all the arguments in
|
|
favor of it). So the "every 11 minutes" feature becomes a bug.
|
|
|
|
This "feature/bug" appears to behave differently in different versions
|
|
of the kernel (and possibly in different versions of xntpd and ntpd as
|
|
well), so if you're running both ntpd and hwclock you may need to test
|
|
your system to see what it actually does. If you can't keep the kernel
|
|
from resetting the RTC, you might have to run without a correction
|
|
factor on the RTC.
|
|
|
|
The part of the kernel that controls this can be found in
|
|
/usr/src/linux-2.0.34/arch/i386/kernel/time.c (where the version
|
|
number in the path will be the version of the kernel you're running).
|
|
If the variable time_status is set to TIME_OK then the kernel will
|
|
write the system time to the RTC every 11 minutes, otherwise it leaves
|
|
the RTC alone. Calls to adjtimex(2) (as used by ntpd and timed, for
|
|
example) may turn this on. Calls to settimeofday(2) will set
|
|
time_status to TIME_UNSYNC, which tells the kernel not to adjust the
|
|
RTC. I have not found any real documentation on this.
|
|
|
|
I've heard reports that some versions of the kernel may have problems
|
|
with "sleep modes" that shut down the CPU to save energy. The best
|
|
solution is to keep your kernel up to date, and refer any problems to
|
|
the people who maintain the kernel.
|
|
|
|
If you get bizarre results from the RTC you may have a hardware
|
|
problem. Some RTC chips include a lithium battery that can run down,
|
|
and some motherboards have an option for an external battery (be sure
|
|
the jumper is set correctly). The same battery maintains the CMOS RAM,
|
|
but the clock takes more power and is likely to fail first. Bizarre
|
|
results from the system clock may mean there is a problem with
|
|
interrupts.
|
|
|
|
2.3. Should the RTC use Local Time or UTC, and What About DST?
|
|
|
|
The Linux "system clock" actually just counts the number of seconds
|
|
past Jan 1, 1970, and is always in UTC (or GMT, which is technically
|
|
different but close enough that casual users tend to use both terms
|
|
interchangeably). UTC does not change as DST comes and goes-- what
|
|
changes is the conversion between UTC and local time. The translation
|
|
to local time is done by library functions that are linked into the
|
|
application programs.
|
|
|
|
This has two consequences: First, any application that needs to know
|
|
the local time also needs to know what time zone you're in, and
|
|
whether DST is in effect or not (see the next section for more on time
|
|
zones). Second, there is no provision in the kernel to change either
|
|
the system clock or the RTC as DST comes and goes, because UTC doesn't
|
|
change. Therefore, machines that only run Linux should have the RTC
|
|
set to UTC, not local time.
|
|
|
|
However, many people run dual-boot systems with other OS's that expect
|
|
the RTC to contain the local time, so hwclock needs to know whether
|
|
your RTC is in local time or UTC, which it then converts to seconds
|
|
past Jan 1, 1970 (UTC). This still does not provide for seasonal
|
|
changes to the RTC, so the change must be made by the other OS (this
|
|
is the one exception to the rule against letting more than one program
|
|
change the time in the RTC).
|
|
|
|
Unfortunately, there are no flags in the RTC or the CMOS RAM to
|
|
indicate standard time vs DST, so each OS stores this information
|
|
someplace where the other OS's can't find it. This means that hwclock
|
|
must assume that the RTC always contains the correct local time, even
|
|
if the other OS has not been run since the most recent seasonal time
|
|
change.
|
|
|
|
If Linux is running when the seasonal time change occurs, the system
|
|
clock is unaffected and applications will make the correct conversion.
|
|
But if linux has to be rebooted for any reason, the system clock will
|
|
be set to the time in the RTC, which will be off by one hour until the
|
|
other OS (usually Windows) has a chance to run.
|
|
|
|
There is no way around this, but Linux doesn't crash very often, so
|
|
the most likely reason to reboot on a dual-boot system is to run the
|
|
other OS anyway. But beware if you're one of those people who shuts
|
|
down Linux whenever you won't be using it for a while-- if you haven't
|
|
had a chance to run the other OS since the last time change, the RTC
|
|
will be off by an hour until you do.
|
|
|
|
Some other documents have stated that setting the RTC to UTC allows
|
|
Linux to take care of DST properly. This is not really wrong, but it
|
|
doesn't tell the whole story-- as long as you don't reboot, it does
|
|
not matter which time is in the RTC (or even if the RTC's battery
|
|
dies). Linux will maintain the correct time either way, until the next
|
|
reboot. In theory, if you only reboot once a year (which is not
|
|
unreasonable for Linux), DST could come and go and you'd never notice
|
|
that the RTC had been wrong for several months, because the system
|
|
clock would have stayed correct all along. But since you can't predict
|
|
when you'll want to reboot, it's better to have the RTC set to UTC if
|
|
you're not running another OS that requires local time.
|
|
|
|
The Dallas Semiconductor RTC chip (which is a drop-in replacement for
|
|
the Motorola chip used in the IBM AT and clones) actually has the
|
|
ability to do the DST conversion by itself, but this feature is not
|
|
used because the changeover dates are hard-wired into the chip and
|
|
can't be changed. Current versions change on the first Sunday in April
|
|
and the last Sunday in October, but earlier versions used different
|
|
dates (and obviously this doesn't work in countries that use other
|
|
dates). Also, the RTC is often integrated into the motherboard's
|
|
"chipset" (rather than being a separate chip) and I don't know if they
|
|
all have this ability.
|
|
|
|
2.4. How Linux keeps Track of Time Zones
|
|
|
|
You probably set your time zone correctly when you installed Linux.
|
|
But if you have to change it for some reason, or if the local laws
|
|
regarding DST have changed (as they do frequently in some countries),
|
|
then you'll need to know how to change it. If your system time is off
|
|
by some exact number of hours, you may have a time zone problem (or a
|
|
DST problem).
|
|
|
|
Time zone and DST information is stored in /usr/share/zoneinfo (or
|
|
/usr/lib/zoneinfo on older systems). The local time zone is
|
|
determined by a symbolic link from /etc/localtime to one of these
|
|
files. The way to change your timezone is to change the link. If
|
|
your local DST dates have changed, you'll have to edit the file.
|
|
|
|
You can also use the TZ environment variable to change the current
|
|
time zone, which is handy of you're logged in remotely to a machine in
|
|
another time zone. Also see the man pages for tzset and tzfile.
|
|
This is nicely summarized at
|
|
<http://www.linuxsa.org.au/tips/time.html>
|
|
|
|
2.5. The Bottom Line
|
|
|
|
If you don't need sub-second accuracy, hwclock(8) and adjtimex(8) may
|
|
be all you need. It's easy to get enthused about time servers and
|
|
radio clocks and so on, but I ran the old clock(8) program for years
|
|
with excellent results. On the other hand, if you have several
|
|
machines on a LAN it can be handy (and sometimes essential) to have
|
|
them automatically sync their clocks to each other. And the other
|
|
stuff can be fun to play with even if you don't really need it.
|
|
|
|
On machines that only run Linux, set the RTC to UTC (or GMT). On
|
|
dual-boot systems that require local time in the RTC, be aware that if
|
|
you have to reboot Linux after the seasonal time change, the clock may
|
|
be temporarily off by one hour, until you have a chance to run the
|
|
other OS. If you run more than two OS's, be sure only one of them is
|
|
trying to adjust for DST.
|
|
|
|
3. Software
|
|
|
|
3.1. Clock(8) and Hwclock(8)
|
|
|
|
All linux distributions install either the old clock(8) or the newer
|
|
hwclock(8), but without a correction factor. Some may also install
|
|
adjtimex(8), or they may include it on the CD as optional (or you can
|
|
download it from the usual Linux archive sites). Some distributions
|
|
also include a graphical clock setting program that runs in an X-
|
|
window, but those are designed for interactive use, and the system
|
|
will still install clock(8) or hwclock(8) for use in the startup
|
|
scripts.
|
|
|
|
Clock(8) requires you to calculate the correction factor by hand, but
|
|
hwclock(8) calculates it automatically whenever you use it to reset
|
|
the RTC (using another program to set the RTC will interfere with the
|
|
drift correction, so always use the same program if you're using a
|
|
correction factor). If you have an older system that still uses
|
|
clock(8) and you want to upgrade, you can find hwclock(8) in the
|
|
"util-linux" package, version 2.7 or later. See the man page for more
|
|
information.
|
|
|
|
|
|
Note
|
|
The man page for hwclock(8) may be called "clock" for backward
|
|
compatibility, so try both names. Hwclock(8) will respond to
|
|
commands written for clock(8), but the result may not be the
|
|
same-- in particular, "hwclock -a" is not quite the same as
|
|
"clock -a", so if you're upgrading to hwclock I'd suggest
|
|
replacing all references to "clock" in your startup scripts to
|
|
use hwclock's native commands instead.
|
|
|
|
The startup scripts vary from one distribution to another, so you may
|
|
have to search a bit to find where it sets the clock. Typical
|
|
locations are /etc/rc.local, /etc/rc.d/rc.sysinit, /etc/rc.d/boot, or
|
|
some similar place.
|
|
|
|
The correction factor for the RTC is stored in /etc/adjtime. Red Hat
|
|
has a script in /etc/sysconfig/clock that controls the options to
|
|
hwclock.
|
|
|
|
When you're setting the clock to determine the drift rate, keep in
|
|
mind that your local telephone time announcement may or may not be
|
|
accurate. If you don't have a shortwave radio or GPS receiver, you can
|
|
hear the audio feed from WWV by calling (303)499-7111 (this is a toll
|
|
call to Boulder, Colorado). It will cut you off after three minutes,
|
|
but that should be long enough to set the clock. USNO and Canada's CHU
|
|
also have telephone time services, but I prefer WWV's because there is
|
|
more time between the announcement and the "beep". You can also get
|
|
the time from a network time server using the ntpdate program that
|
|
comes with ntpd, and there's a javaclock at <www.time.gov>.
|
|
|
|
In any case, what you're setting is the system clock, not the RTC (see
|
|
the man page for the date command for the formats to use). Then use
|
|
hwclock to set the RTC and calculate the drift rate. If you're doing
|
|
this by hand, you should be able to set it within a second or two, and
|
|
get a reasonable approximation of the drift rate after a few weeks.
|
|
Then you can run adjtimex(8) to fine-tune the system clock.
|
|
|
|
3.2. Adjtimex(8)
|
|
|
|
Adjtimex(8) allows the user to adjust the kernel's time variables, and
|
|
therefore change the speed of the system clock (you must be logged in
|
|
as "root" to do this). It is cleverly designed to compare the system
|
|
clock to the RTC using the same correction factor used by clock(8) or
|
|
hwclock(8), as stored in /etc/adjtime. So, once you've established
|
|
the drift rate of the RTC, it's fairly simple to correct the system
|
|
clock as well. Once you've got it running at the right speed, you can
|
|
add a line to your startup scripts to set the correct kernel variables
|
|
at boot time. Since adjtimex(8) was designed to work with clock(8) or
|
|
hwclock(8), it includes a work-around for the "every 11 minutes" bug.
|
|
|
|
After you've installed adjtimex(8) you can get more information on
|
|
setting it up by typing "man 8 adjtimex" (there is also an adjtimex(2)
|
|
man page, which is not what you want) and by reading the README file
|
|
in /usr/doc/adjtimex-1.3/README (where the version number in the path
|
|
will be the current version of adjtimex(8)).
|
|
|
|
3.3. Xntpd and ntpd: the Network Time Protocol
|
|
|
|
Xntpd (NTPv3) has been replaced by ntpd (NTPv4); the earlier version
|
|
is no longer being maintained.
|
|
|
|
Ntpd is the standard program for synchronizing clocks across a
|
|
network, and it comes with a list of public time servers you can
|
|
connect to. It can be a little more complicated to set up than the
|
|
other programs described here, but if you're interested in this kind
|
|
of thing I highly recommend that you take a look at it anyway.
|
|
|
|
The "home base" for information on ntpd is the NTP website at
|
|
<http://www.eecis.udel.edu/~ntp/> which also includes links to all
|
|
kinds of interesting time-related stuff (including software for other
|
|
OS's). Some linux distributions include ntpd on the CD. There is a
|
|
list of public time servers at
|
|
<http://www.eecis.udel.edu/~mills/ntp/clock2.html>.
|
|
|
|
A relatively new feature in ntpd is a "burst mode" which is designed
|
|
for machines that have only intermittent dial-up access to the
|
|
internet.
|
|
|
|
Ntpd includes drivers for quite a few radio clocks (although some
|
|
appear to be better supported than others). Most radio clocks are
|
|
designed for commercial use and cost thousands of dollars, but there
|
|
are some cheaper alternatives (discussed in later sections). In the
|
|
past most were WWV or WWVB receivers, but now most of them seem to be
|
|
GPS receivers. NIST has a PDF file that lists manufacturers of radio
|
|
clocks on their website at
|
|
<http://www.boulder.nist.gov/timefreq/links.htm> (near the bottom of
|
|
the page). The NTP website also includes many links to manufacturers
|
|
of radio clocks at <http://www.eecis.udel.edu/~ntp/hardware.htm> and
|
|
<http://www.eecis.udel.edu/~mills/ntp/refclock.htm>. Either list may
|
|
or may not be up to date at any given time :-). The list of drivers
|
|
for ntpd is at
|
|
<http://www.eecis.udel.edu/~ntp/ntp_spool/html/refclock.htm>.
|
|
|
|
Ntpd also includes drivers for several dial-up time services. These
|
|
are all long-distance (toll) calls, so be sure to calculate the effect
|
|
on your phone bill before using them.
|
|
|
|
3.4. Chrony
|
|
|
|
Xntpd was originally written for machines that have a full-time
|
|
connection to a network time server or radio clock. In theory it can
|
|
also be used with machines that are only connected intermittently, but
|
|
Richard Curnow couldn't get it to work the way he wanted it to, so he
|
|
wrote "chrony" as an alternative for those of us who only have network
|
|
access when we're dialed in to an ISP (this is the same problem that
|
|
ntpd's new "burst mode" was designed to solve). The current version
|
|
of chrony includes drift correction for the RTC, for machines that are
|
|
turned off for long periods of time.
|
|
|
|
You can get more information from Richard Curnow's website at
|
|
<http://www.rrbcurnow.freeuk.com/chrony> or <http://go.to/chrony>.
|
|
There are also two chrony mailing lists, one for announcements and one
|
|
for discussion by users. For information send email to chrony-users-
|
|
subscribe@egroups.com or chrony-announce-subscribe@egroups.com
|
|
|
|
Chrony is normally distributed as source code only, but Debian has
|
|
been including a binary in their "unstable" collection. The source
|
|
file is also available at the usual Linux archive sites.
|
|
|
|
3.5. Clockspeed
|
|
|
|
Another option is the clockspeed program by DJ Bernstein. It gets the
|
|
time from a network time server and simply resets the system clock
|
|
every three seconds. It can also be used to synchronize several
|
|
machines on a LAN.
|
|
|
|
I've sometimes had trouble reaching his website at
|
|
<http://Cr.yp.to/clockspeed.html>, so if you get a DNS error try again
|
|
on another day. I'll try to update this section if I get some better
|
|
information.
|
|
|
|
4. Radio Clocks
|
|
|
|
4.1. CHU and the "Gadget Box"
|
|
|
|
CHU, the Canadian shortwave time station near Ottawa, is similar to
|
|
WWV in the US but with one important difference: in addition to
|
|
announcing the time in both French and English, it also broadcasts the
|
|
current time once per minute using the old "Bell 103" (300 baud) modem
|
|
tones. These tones are very easy to decode, and Bill Rossi realised
|
|
that you don't even need a modem-- just a shortwave radio and a sound
|
|
card. If you're able to receive the signal from CHU, this may be the
|
|
cheapest radio clock available. Shortwave reception varies throughout
|
|
the day, but Bill claims that by changing frequencies twice a day
|
|
(morning and evening) he gets almost 24-hour coverage. CHU broadcasts
|
|
on 3.33, 7.335, and 14.670 MHz.
|
|
|
|
For more information see Bill Rossi's website at
|
|
<http://www.rossi.com/chu/>. The source file is also available at the
|
|
usual Linux archive sites. For information on CHU's time services see
|
|
<http://www.nrc.ca/inms/time/ctse.html>.
|
|
|
|
The NTP website has plans for a "gadget box" that decodes the CHU time
|
|
broadcast using an inexpensive 300 baud modem chip and any shortwave
|
|
radio, at <http://www.eecis.udel.edu/~ntp/ntp_spool/html/gadget.htm>.
|
|
The plans include a Postscript image of a 2-sided custom printed
|
|
circuit board, but you have to make the board yourself (or find
|
|
someone who can make it for you).
|
|
|
|
Ntpd includes a driver (type 7) for CHU receivers, which works either
|
|
with modems like the "gadget box", or by feeding the audio directly
|
|
into the mic input of a Sun SPARCstation (or any other machine with
|
|
"compatible audio drivers").
|
|
|
|
4.2. WWV and the "Most Accurate Clock"
|
|
|
|
You may have heard about Heathkit's "Most Accurate Clock", which
|
|
received and decoded the time signal from WWV and had an optional
|
|
serial port for connecting to a computer. Heathkit stopped selling
|
|
kits a long time ago, but they continued to sell the factory-built
|
|
version of the clock until 1995, when it was also discontinued. For
|
|
Heathkit nostalgia (not including the clock) see
|
|
<http://www.heathkit-museum.com>. The Heathkit company still exists,
|
|
selling educational materials. See <http://www.heathkit.com>.
|
|
|
|
According to Dave Mills, Heathkit's patent on the "Most Accurate
|
|
Clock" is due to expire soon, so maybe someone out there would like to
|
|
clone it as a single-chip IC.
|
|
|
|
The NTP website has a DSP program (and a PDF file describing it) at
|
|
<http://www.eecis.udel.edu/~mills/resource.htm> that decodes the WWV
|
|
time signal using a shortwave radio and the TAPR/AMSAT DSP-93, a DSP
|
|
kit which is no longer available. It was based on the Texas
|
|
Instruments TMS320C25 DSP chip. The TAPR website at
|
|
<http://www.tapr.org> includes a lot of information on homebrew DSP
|
|
programming.
|
|
|
|
Ntpd includes a driver (type 6) for the IRIG-B and IRIG-E time codes,
|
|
using /dev/audio on a Sun SPARCstation, with a note that it is "likely
|
|
portable to other systems". WWV uses the IRIG-H time code.
|
|
|
|
WWV is run by NIST, which has a website at
|
|
<http://www.boulder.nist.gov/timefreq/index.html>. This site includes
|
|
the text of "Special Publication 432", which describes their time and
|
|
frequency services, at
|
|
<http://www.boulder.nist.gov/timefreq/pubs/sp432/sp432.htm>. WWV
|
|
broadcasts on 2.5, 5, 10, 15, and 20 Mhz.
|
|
|
|
4.3. GPS and the "Totally Accurate Clock"
|
|
|
|
GPS signals include the correct time, and some GPS receivers have
|
|
serial ports. Ntpd includes drivers for several GPS receivers. The
|
|
1PPS feature ("One Pulse Per Second", required for high accuracy)
|
|
usually requires a separate interface to connect it to the computer.
|
|
|
|
TAPR (Tuscon Amateur Packet Radio) makes a kit for an interface called
|
|
"TAC-2" (for "Totally Accurate Clock") that plugs into a serial port
|
|
and works with any GPS receiver that can provide a 1PPS output--
|
|
including some "bare board" models that can be mounted directly to the
|
|
circuit board. For more information see their website at
|
|
<http://www.tapr.org>. The price (as of June 1999) is around $140, not
|
|
including the GPS receiver. The kit does not include any enclosure or
|
|
mounting hardware.
|
|
|
|
The CHU "gadget box" (described in another section) can also be used
|
|
as an interface for the 1PPS signal. The NTP website has a discussion
|
|
of this at <http://www.eecis.udel.edu/~ntp/ntp_spool/html/pps.htm>.
|
|
|
|
4.4. Low-frequency Time Signals: DCF77, MSF(Rugby), WWVB
|
|
|
|
These low-frequency stations broadcast a time code by simply switching
|
|
the carrier on and off. Each station uses its own coding scheme, and
|
|
summaries are available on the NTP website at
|
|
<http://www.eecis.udel.edu/~mills/ntp/index.htm> (near the bottom of
|
|
the page). DCF77 in Germany broadcasts on 77.5kHz. MSF in England
|
|
(also called "Rugby", which apparently refers to its location) and
|
|
WWVB in Colorado both broadcast on 60 kHz.
|
|
|
|
Reception of WWVB varies, but there are plans to increase its
|
|
broadcast power, in several stages. You can follow its progress on
|
|
NIST's website at
|
|
<http://www.boulder.nist.gov/timefreq/wwvstatus.html>.
|
|
|
|
Inexpensive receivers that can plug into a serial port are reported to
|
|
be available in Europe. Ntpd includes drivers for a couple of MSF
|
|
receivers.
|
|
|
|
A number of companies in the US sell relatively inexpensive clocks
|
|
that have built-in WWVB receivers (including several analog wall
|
|
clocks), but I'm only aware of two that can be connected to a
|
|
computer:
|
|
|
|
The Ultralink Model 320 sells for about $120 (as of June 1999) and has
|
|
a serial interface and a straightforward ASCII command set, so it
|
|
shouldn't be too hard to program. It draws 1mA from the serial port
|
|
for power. The antenna can be up to 100 feet away from the computer,
|
|
and the unit contains its own clock to maintain the time if it loses
|
|
the signal. They also sell a "bare board" version for about $80 that
|
|
is designed to work with the "BASIC Stamp" series of microcontrollers.
|
|
See <http://www.ulio.com/timepr.html>.
|
|
|
|
Arcron Technology sells a desk clock with an optional serial port for
|
|
about $130, including software for Windows. See
|
|
<http://www.arctime.com>
|
|
|
|
|
|
|