Diagram of CHU Leap-Second Recording and Atomic Clock
I recorded the audio of the 3330 kHz signal of the National Research Council of Canada's time signal station CHU from a few minutes before, until a couple of minutes after, midnight UTC on New Years' Eve. A PDF of the annotated sampled-signal time series between 23:59:00 and 0:00:01 can be found here: http://gge.unb.ca/Resources/CHU.31Dec05.leapsecond.pdf. The leap second was correctly inserted. However, starting one minute after UTC midnight, DUT1 became +0.4 seconds rather than +0.3 seconds as prescribed by IERS. The +0.4 second value continued to be transmitted until some time on 3 January 2006. According to an NRC staff member, the problem arose because the IERS Bulletin D announcing the +0.3 second value was not sent out until 28 December and was not seen until people returned to work on 3 January after the holidays. This problem seems to have occurred with some other time signal stations too. Simultaneous with the audio recording of CHU, I videotaped the display of a SkyScan atomic clock, model 31981, marketed by Equity Time U.S.A., which receives the WWVB signal. It did not account for the leap second at UTC midnight. Likely it continued that way until it next tried to receive the WWVB signal. === Richard B. LangleyE-mail: [EMAIL PROTECTED] Geodetic Research Laboratory Web: http://www.unb.ca/GGE/ Dept. of Geodesy and Geomatics EngineeringPhone:+1 506 453-5142 University of New Brunswick Fax: +1 506 453-4943 Fredericton, N.B., Canada E3B 5A3 Fredericton? Where's that? See: http://www.city.fredericton.nb.ca/ ===
Re: Diagram of CHU Leap-Second Recording and Atomic Clock
It is correct that DUT1 changes by +1.0 across a positive leap second; going from a negative value (e.g., -0.6) to a positive value (e.g., +0.4). You would see the inverse in the case of a negative leap second (DUT1 will, by definition, be positive before the negative leap second and go negative after the leap). As for the delay in implementing IERS bulletin D 92; I was always under the impression that national time institutions could implement this at their convenience and, unlike leap seconds, did not have to change the DUT1 bits at the precise day and hour that IERS dictated. Perhaps someone on the list from NIST or USNO can clarify how this has been done in the past? When you think of it; with DUT1 being broadcast with a low precision of 0.1 seconds; there doesn't seem to be any reason to expect every national or local IRIG broadcast of DUT1 to make the change with 1 minute, or 1 day, or even 1 month precision. As for your Skyscan clock, I have several dozen similar consumer RC clocks here and none has ever adjusted itself for a leap second in real-time (also try displaying :59:60 on an analog clock!). They all get back in sync eventually, though. That's a nice CHU capture. Thanks for sharing it. /tvb http://www.LeapSecond.com - Original Message - From: Richard Langley [EMAIL PROTECTED] To: LEAPSECS@ROM.USNO.NAVY.MIL Sent: Wednesday, January 04, 2006 08:04 Subject: [LEAPSECS] Diagram of CHU Leap-Second Recording and Atomic Clock I recorded the audio of the 3330 kHz signal of the National Research Council of Canada's time signal station CHU from a few minutes before, until a couple of minutes after, midnight UTC on New Years' Eve. A PDF of the annotated sampled-signal time series between 23:59:00 and 0:00:01 can be found here: http://gge.unb.ca/Resources/CHU.31Dec05.leapsecond.pdf. The leap second was correctly inserted. However, starting one minute after UTC midnight, DUT1 became +0.4 seconds rather than +0.3 seconds as prescribed by IERS. The +0.4 second value continued to be transmitted until some time on 3 January 2006. According to an NRC staff member, the problem arose because the IERS Bulletin D announcing the +0.3 second value was not sent out until 28 December and was not seen until people returned to work on 3 January after the holidays. This problem seems to have occurred with some other time signal stations too. Simultaneous with the audio recording of CHU, I videotaped the display of a SkyScan atomic clock, model 31981, marketed by Equity Time U.S.A., which receives the WWVB signal. It did not account for the leap second at UTC midnight. Likely it continued that way until it next tried to receive the WWVB signal. === Richard B. LangleyE-mail: [EMAIL PROTECTED] Geodetic Research Laboratory Web: http://www.unb.ca/GGE/ Dept. of Geodesy and Geomatics EngineeringPhone:+1 506 453-5142 University of New Brunswick Fax: +1 506 453-4943 Fredericton, N.B., Canada E3B 5A3 Fredericton? Where's that? See: http://www.city.fredericton.nb.ca/ ===
Re: Diagram of CHU Leap-Second Recording and Atomic Clock
In message [EMAIL PROTECTED], Tom Van Baak writes: As for your Skyscan clock, I have several dozen similar consumer RC clocks here and none has ever adjusted itself for a leap second in real-time The majority of such clocks only run the receiver for some part of the day to save power. One particular kind I examined ran the receiver until it had sync, then powered the receiver down for 23 hours and repeated the cycle. My local clockaholic told me that some of the more modern ones sleep based on battery voltage: As the voltage drops, the chance of slips in the mechanism increases and the receiver will turn on more often to make sure it is still in sync. In the case of DCF77, that means that you'd have to be rather lucky for your clock to do the leapsecond in real time. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Diagram of CHU Leap-Second Recording and Atomic Clock
The majority of such clocks only run the receiver for some part of the day to save power. One particular kind I examined ran the receiver until it had sync, then powered the receiver down for 23 hours and repeated the cycle. Yes, but the LS bit stays lit for the entire month (at least for WWVB) so the RC clock has plenty of notice to insert a leap second at the end of the month if it wanted to, regardless of reception quality the day of the leap second. Unfortunately, this is not the case with the DST bits. Users routinely complain that WWVB RC clocks do not handle DST correctly. This is because there is less than one day advance notice of a DST change. Given that most RC clocks only tune in late at night (e.g., 11 PM), unless one has perfect reception in the few hour window between 11 PM and 2 AM, a WWVB RC clock won't make the DST switch in time. To me this is a broken design, but I can't see it being fixed anytime soon. The right way is something like a DST count-down field (perhaps at least 3 bits wide). Are there some LF broadcasts that announce DST far enough (many days or weeks) in advance that the time change can be done reliably? /tvb
