• Get involved.
    We want your input!
    Apply for Membership and join the conversations about everything related to broadcasting.

    After we receive your registration, a moderator will review it. After your registration is approved, you will be permitted to post.
    If you use a disposable or false email address, your registration will be rejected.

    After your membership is approved, please take a minute to tell us a little bit about yourself.
    https://www.radiodiscussions.com/forums/introduce-yourself.1088/

    Thanks in advance and have fun!
    RadioDiscussions Administrators

Canada’s CHU time station to close

In addition to WWVB, which conveys time data simultaneously via phase modulation and amplitude shift keying/pulse width modulation, WWV, WWVH, and CHU are still relevant in the modern era because they also each convey time as data in addition to by voice (WWV and WWVH transmit IRIG, and CHU transmits 300 bps 8N2 data bursts). So shutting any of these services down is utterly stupid, because there are unknowable numbers of clocks and other hardware devices still using them for time synchronization, and losing any of them would screw over innumerable users.

I do realize there are also GPS, cellular tower clock time, and NTP. But GPS is unavailable indoors, cellular towers can be vulnerable to power outages, and NTP requires internet and breaks under congestion. WWV, WWVH, CHU, and especially WWVB, in comparison, all penetrate into buildings often enough to make periodic clock synchronization possible without relying on any infrastructure middlemen.

Many have forgotten about these numbers, and those with cellular and VoIP lines may find their accuracy thwarted for them by the latency built into their services, but people with pure PSTN phone service on analog copper lines can still get very low latency time information via these numbers:

303-499-7111 - Voice - National Institute of Standards & Technology (WWV audio, Colorado)
808-335-4363 - Voice - National Institute of Standards & Technology (WWVH audio, Hawaii)
202-762-1069 - Voice - U.S. Naval Observatory Master Clock (Washington D.C.)
202-762-1401 - Voice - U.S. Naval Observatory Master Clock (Washington D.C.)
719-567-6743 - Voice - U.S. Naval Observatory Master Clock (Colorado Springs)
303-494-4774 - Modem - National Institute of Standards & Technology (ACTS 9600 bps 8N1, Colorado)
808-335-4721 - Modem - National Institute of Standards & Technology (ACTS 9600 bps 8N1, Hawaii)
202-762-1594 - Modem - U.S. Naval Observatory (1200 bps 8N1 - Washington D.C.)
719-567-6743 - Modem - U.S. Naval Observatory (1200 bps 8N1 - Colorado Springs)

The operator of CHU in Canada (NRC) also offers its time service by phone, though I don't know whether this will continue after CHU itself leaves the air:

613-745-1576 (English)
613-745-9426 (French)

Sources for more information:
https://nrc.canada.ca/en/certificat...canadas-official-time/telephone-talking-clock
https://www.cnmoc.usff.navy.mil/Our...atory/Precise-Time-Department/Telephone-Time/
https://www.nist.gov/pml/time-and-f...ribution/automated-computer-time-service-acts
https://www.nist.gov/pml/time-and-f.../radio-station-wwv/telephone-time-day-service
https://www.ntp.org/documentation/drivers/driver18/
https://en.wikipedia.org/wiki/Time_synchronization_in_North_America
 
Last edited:
yeoldeschool said:
In addition to WWVB, which conveys time data simultaneously via phase modulation and amplitude shift keying/pulse width modulation, WWV, WWVH, and CHU are still relevant in the modern era because they also each convey time as data in addition to by voice (WWV and WWVH transmit IRIG, and CHU transmits 300 bps 8N2 data bursts). So shutting any of these services down is utterly stupid, because there are unknowable numbers of clocks and other hardware devices still using them for time synchronization, and losing any of them would screw over innumerable users.

I do realize there are also GPS, cellular tower clock time, and NTP. But GPS is unavailable indoors, cellular towers can be vulnerable to power outages, and NTP requires internet and breaks under congestion. WWV, WWVH, CHU, and especially WWVB, in comparison, all penetrate into buildings often enough to make periodic clock synchronization possible without relying on any infrastructure middlemen.

Many have forgotten about these numbers, and those with cellular and VoIP lines may find their accuracy thwarted for them by the latency built into their services, but people with pure PSTN phone service on analog copper lines can still get very low latency time information via these numbers:

303-499-7111 - Voice - National Institute of Standards & Technology (WWV audio, Colorado)
808-335-4363 - Voice - National Institute of Standards & Technology (WWVH audio, Hawaii)
202-762-1069 - Voice - U.S. Naval Observatory Master Clock (Washington D.C.)
202-762-1401 - Voice - U.S. Naval Observatory Master Clock (Washington D.C.)
719-567-6743 - Voice - U.S. Naval Observatory Master Clock (Colorado Springs)
303-494-4774 - Modem - National Institute of Standards & Technology (ACTS 9600 bps 8N1, Colorado)
808-335-4721 - Modem - National Institute of Standards & Technology (ACTS 9600 bps 8N1, Hawaii)
202-762-1594 - Modem - U.S. Naval Observatory (1200 bps 8N1 - Washington D.C.)
719-567-6743 - Modem - U.S. Naval Observatory (1200 bps 8N1 - Colorado Springs)

The operator of CHU in Canada (NRC) also offers its time service by phone, though I don't know whether this will continue after CHU itself leaves the air:

613-745-1576 (English)
613-745-9426 (French)

Sources for more information:
https://nrc.canada.ca/en/certificat...canadas-official-time/telephone-talking-clock
https://www.cnmoc.usff.navy.mil/Our...atory/Precise-Time-Department/Telephone-Time/
https://www.nist.gov/pml/time-and-f...ribution/automated-computer-time-service-acts
https://www.nist.gov/pml/time-and-f.../radio-station-wwv/telephone-time-day-service
https://www.ntp.org/documentation/drivers/driver18/
https://en.wikipedia.org/wiki/Time_synchronization_in_North_America
Click to expand...


Wow, thanks for the info.
 
yeoldeschool said:
Many have forgotten about these numbers, and those with cellular and VoIP lines may find their accuracy thwarted for them by the latency built into their services, but people with pure PSTN phone service on analog copper lines can still get very low latency time information via these numbers:
Click to expand...
People are also restoring old Leitch master clock units and putting them back in service:
The one in the video can be called at 506-408-0067.
 
kevtronics said:
People are also restoring old Leitch master clock units and putting them back in service:
Click to expand...
I bristled at the mere mention of that name, without immediately recognizing why. Then the memories all flooded back. Leitch made the unholy encryption scheme that shut millions out of the affiliate feeds for ABC, CBS, FOX, and Global in the glory days of C-band.

In any case, the time required to watch that entire video was a bit much for me, but I caught the full sections on dialing out and using the terminal interface. Both were satisfyingly retro. (I was also thinking earlier that the NRC must have had a time modem number of its own, and ... now I know.)

P.S. European time numbers for all your retro modem nerdmaxxing needs can be found at https://www.ntp.org/documentation/drivers/tf582_4/, for anyone reading this thread from across the pond.
 
mimo said:
They do plan to keep those going.
Click to expand...

Do they have some way of compensating for the latency involved when transmitting the time over a phone or internet connection? It seems to me like it would defeat the purpose of setting time to a laboratory-standard atomic clock if the delay in receiving it is unknown.

Of course with a radio transmission the delay can be calculated based on distance to within a very small, acceptable margin of error, which makes the SW broadcast reliably accurate.

Following internationally accepted recommendations, Canada and other countries have official time scales in agreement within 10µs. Since CHU's transmissions are well within 100µs of official Canadian time, for all distant users of CHU, the dominant source of time error comes from the radio wave path reflecting off the ionosphere as the radio signal travels from the transmitter (in Ottawa, Ontario, Canada) to the user. The time delay is 3.3µs per km of path, and generally varies by less than 1ms due to uncertainties in path including the uncertainty in the number of skips made by the radio wave (reflections down from the ionosphere and back up from the surface of the Earth). For a fixed receiver when the number of skips does not change, the variation in the path delay will usually be less than 100µs. A small additional delay comes from the radio receiver, and may be significant.
Click to expand...
 
Last edited:
Theater of My Mind said:
Do they have some way of compensating for the latency involved when transmitting the time over a phone or internet connection? It seems to me like it would defeat the purpose of setting time to a laboratory-standard atomic clock if the delay in receiving it is unknown.
Click to expand...
The Network Time Protocol (NTP), which is the primary method for doing time synchronization over the internet, includes mechanisms for discovering and factoring in the path latency of a time server connection. You can read about how it works in the Wikipedia article. (I believe the Simple Network Time Protocol (SNTP), which is sometimes used as an easier-to-implement NTP alternative, also supports path latency discovery. But don't quote me on it.)

The Automated Computer Time Service (ACTS), which is the protocol created by NIST for analog dial-up modem connections, also has mechanisms to eliminate baud rate and PSTN path latency offsets. ACTS works by sending several lines of ASCII, one per second, which look approximately like this:

48662 2026-02-10 01:32:32 00 0 -.2 045.0 UTC(NIST) *
48662 2026-02-10 01:32:33 00 0 -.2 045.0 UTC(NIST) *
48662 2026-02-10 01:32:34 00 0 -.2 045.0 UTC(NIST) *
48662 2026-02-10 01:32:35 00 0 -.2 045.0 UTC(NIST) *
48662 2026-02-10 01:32:36 00 0 -.2 045.0 UTC(NIST) *
etc.

Each line is sent slightly in advance of the time indicated upon it, up to but not including the asterisk. Then, when that indicated time actually arrives, the asterisk alone is sent, followed by CRLF, completing the line. This is done for the same reason talking clocks say "at the sound of the tone" -- only in this case, it's the arrival of the asterisk that marks the arrival of the precise moment in time pre-indicated. So whether you call in at 300 baud, or at 14400 bps, the ASCII line is sent sufficiently far in advance that, even if you're using a very slow speed, the asterisk will still reach you right when it is sent, with no lag except for the PSTN's own copper/fiber optic latency.

That said, the ACTS protocol offers a simple way for factoring that in as well. A properly designed software program for calling ACTS numbers will send each asterisk it receives right back to the other end, the instant it arrives. After a few cycles of that, the other end will be able to calculate the PSTN-level latency for the current call. The "045.0" millisecond value you see in each of the demonstration ASCII lines above (which starts out as 045.0 to indicate a default presumed path delay) will change to the actual path delay calculated for the current call; the far end will additionally begin terminating each line with a # instead of a * so that the calling software knows it can now trust the millisecond parameter to be accurate enough for perfectly setting the host machine's clock. (You can see the Leitch unit in @kevtronics' video link utilizing "loopback" functionality to cancel out the line latency of its owner's VoIP service while calling the Canadian time number. I'm pretty sure that function is using this kind of simple character echo-back mechanism as well.)

As for the voice-only numbers, it's like I said when posting them: they're only going to be accurate these days if you're calling from a real copper line with true PSTN (TDM) service on it. (Some telephone companies that still allow new copper line installations internally connect you to VoIP soft switches in their central offices, rather than to their legacy TDM ones. So, crazy though it sounds, VoIP on copper can now be a thing. Frontier in California is one such example, since the California Public Utilities Commission won't let them stop offering copper, even to new subscribers.)

More information on the ACTS protocol is available in https://dsp-book.narod.ru/MISH/CH18.PDF -- start reading from the bottom of PDF page 14.
 
Last edited:


Back
Top Bottom