Radio signals during a leap second

This web page documents what happened in the long, medium and shortwave radio spectrum during the leap second at the end of 2016. Many broadcasters transmit time pips (e.g., 6 pips at 1 second intervals, or 2 short pips followed by 1 long beep) at the top of the hour. These may sound very precise, with the hour starting precisely at the beginning of the last pip, but it turns out that many of them are actually quite inaccurate.

(For a similar set of measurements of the 2005 leap second, but limited to the longwave range, see here, and see here for observations in a few broadcast bands during the 2008 leap second.)

0 - 29 MHz spectrum view

The following diagram shows the radio spectrum between 0 and 29 MHz (horizontal axis, in kHz), during a bit more than 6 seconds between 23:59:57 and 00:00:02.2 UTC on 2016-12-31 / 2017-01-01. (vertical axis, top to bottom). The dotted lines are the UTC second markers, with the beginning of the next UTC day having more dots. The leap second is the one second duration above the extra dotted line. The receiver is my WebSDR receiver setup in Enschede, The Netherlands, using a vertically polarized E-field probe as the antenna.

Some notes and observations:

France's TDF time signal transmitter on 162 kHz

On 162 kHz, a transmitter in central France transmits a time code as phase-modulation on the carrier. Until 23:00 UTC 31 December 2016, midnight in France, this transmitter also was amplitude modulated with the France Inter radio program. This was switched off for cost-cutting, but the transmitter continues for the timecode (where's the savings?).

In the course of each minute, it transmits one bit per second, together composing the exact time of the start of the next minute. In the last second no bit is transmitted, but a marker. The following shows the data I received around the leap second; 0 and 1 denote bits, M denotes the end-of-minute marker (meaning of the bits taken from Wikipedia; I haven't found a more official source.):

0,1,0,0,0,0,1,0,0,0,0,0,0,0,1,0,0,0,1,0,1,1,1,1,0,1,0,1,1,0,0,0,0,0,0,0,1,0,0,0,0,0,1,1,1,1,0,0,0,0,1,1,1,0,1,0,0,0,1,M  ->  17-01-01 00:57
0,1,0,1,1,1,0,0,0,0,0,0,0,0,1,0,0,0,1,0,1,0,0,0,1,1,0,1,1,0,0,0,0,0,0,0,1,0,0,0,0,0,1,1,1,1,0,0,0,0,1,1,1,0,1,0,0,0,1,M  ->  17-01-01 00:58
0,0,0,0,1,1,1,0,0,0,0,0,0,0,0,1,0,0,0,1,0,1,1,0,0,1,1,0,1,0,0,0,0,0,0,0,0,1,0,0,0,0,0,1,1,1,1,0,0,0,0,1,1,1,0,1,0,0,0,1,M  ->  34-03-02 00:33
0,0,0,0,1,1,0,0,0,0,0,0,0,0,1,0,0,0,1,0,1,0,0,0,0,0,0,0,0,1,0,0,0,0,0,1,1,0,0,0,0,0,1,1,1,1,0,0,0,0,1,1,1,0,1,0,0,0,1,M  ->  17-01-01 01:00
0,0,0,1,1,1,0,0,0,0,0,0,0,0,1,0,0,0,1,0,1,1,0,0,0,0,0,0,1,1,0,0,0,0,0,1,1,0,0,0,0,0,1,1,1,1,0,0,0,0,1,1,1,0,1,0,0,0,1,M  ->  17-01-01 01:01
0,0,0,1,1,1,0,0,0,0,0,0,0,0,1,0,0,0,1,0,1,0,1,0,0,0,0,0,1,1,0,0,0,0,0,1,1,0,0,0,0,0,1,1,1,1,0,0,0,0,1,1,1,0,1,0,0,0,1,M  ->  17-01-01 01:02
                          | | | | | | |   -------------   -----------   ----------- ----- --------- ---------------
tomorrow public holiday --' | | | C C |      minutes         hours          day    weekday  month        year
     today public holiday --' | | E E |
 abnormal transm. operation --' | S T |
     summer time announcement---' T   |
       leap second announcement ------'

The third line has one bit too many. If we chop off the first bit, and decode the rest, it gives the expected 17-01-01 00:59. So apparently, the leap second was inserted in the minute in which it transmitted the 00:59 timestamp, i.e., the minute 00:58:xx, rather than the minute 00:59:xx (the leap second being 00:59:60 in this timezone).

I went back to my recordings from 2005 and 2008, and decoded the 162 kHz timesignal in those (I didn't look at this signal back then). In 2005 it transmitted:

0,0,0,1,1,1,0,0,0,0,0,0,0,0,1,0,0,0,1,0,1,1,1,1,0,1,0,1,1,0,0,0,0,0,0,0,1,0,0,0,0,0,1,1,1,1,0,0,0,0,0,1,1,0,0,0,0,0,1,M  ->  06-01-01 00:57
0,0,0,0,1,1,0,0,0,0,0,0,0,0,1,0,0,0,1,0,1,0,0,0,1,1,0,1,1,0,0,0,0,0,0,0,1,0,0,0,0,0,1,1,1,1,0,0,0,0,0,1,1,0,0,0,0,0,1,M  ->  06-01-01 00:58
0,0,0,0,1,1,0,0,0,0,0,0,0,0,1,0,0,0,1,0,1,1,0,0,1,1,0,1,0,0,0,0,0,0,0,0,1,0,0,0,0,0,1,1,1,1,0,0,0,0,0,1,1,0,0,0,0,0,1,M  ->  06-01-01 00:59
0,0,0,1,0,1,0,0,0,0,0,0,0,0,1,0,0,0,1,0,1,0,0,0,0,0,0,0,0,1,0,0,0,0,0,1,1,0,0,0,0,0,1,1,1,1,0,0,0,0,0,1,1,0,0,0,0,0,1,M  ->  06-01-01 01:00
0,0,0,0,1,1,0,0,0,0,0,0,0,0,1,0,0,0,1,0,1,1,0,0,0,0,0,0,1,1,0,0,0,0,0,1,1,0,0,0,0,0,1,1,1,1,0,0,0,0,0,1,1,0,0,0,0,0,1,M  ->  06-01-01 01:01
0,0,0,0,1,1,0,0,0,0,0,0,0,0,1,0,0,0,1,0,1,0,1,0,0,0,0,0,1,1,0,0,0,0,0,1,1,0,0,0,0,0,1,1,1,1,0,0,0,0,0,1,1,0,0,0,0,0,1,M  ->  06-01-01 01:02
0,0,0,0,1,1,0,0,0,0,0,0,0,0,1,0,0,0,1,0,1,1,1,0,0,0,0,0,0,1,0,0,0,0,0,1,1,0,0,0,0,0,1,1,1,1,0,0,0,0,0,1,1,0,0,0,0,0,1,M  ->  06-01-01 01:03
0,0,0,0,1,1,0,0,0,0,0,0,0,0,1,0,0,0,1,0,1,0,0,1,0,0,0,0,1,1,0,0,0,0,0,1,1,0,0,0,0,0,1,1,1,1,0,0,0,0,0,1,1,0,0,0,0,0,1,M  ->  06-01-01 01:04
0,0,0,0,1,1,0,0,0,0,0,0,0,0,1,0,0,0,1,0,1,1,0,1,0,0,0,0,0,1,0,0,0,0,0,1,1,0,0,0,0,0,1,1,1,1,0,0,0,0,0,1,1,0,0,0,0,0,1,M  ->  06-01-01 01:05
0,0,0,0,1,1,0,0,0,0,0,0,0,0,1,0,0,0,1,0,1,0,1,1,0,0,0,0,0,1,0,0,0,0,0,1,1,0,0,0,0,0,1,1,1,1,0,0,0,0,0,1,1,0,0,0,0,0,1,M  ->  06-01-01 01:06
0,0,0,1,1,1,0,0,0,0,0,0,0,0,1,0,0,0,1,0,1,1,1,1,0,0,0,0,1,1,0,0,0,0,0,1,1,0,0,0,0,0,1,1,1,1,0,0,0,0,0,1,1,0,0,0,0,0,1,M  ->  06-01-01 01:07
0,0,0,0,1,1,0,0,0,0,0,0,0,0,1,0,0,0,1,0,1,0,0,0,1,0,0,0,1,1,0,0,0,0,0,1,1,0,0,0,0,0,1,1,1,1,0,0,0,0,0,1,1,0,0,0,0,0,1,M  ->  06-01-01 01:08
0,0,0,0,1,1,0,0,0,0,0,0,0,0,1,0,0,0,1,0,1,1,0,0,1,0,0,0,0,1,0,0,0,0,0,1,1,0,0,0,0,0,1,1,1,1,0,0,0,0,0,1,1,0,0,0,0,0,1,M  ->  06-01-01 01:09
0,0,0,0,1,1,0,0,0,0,0,0,0,0,1,0,0,0,1,0,1,0,0,0,0,1,0,0,1,1,0,0,0,0,0,1,1,0,0,0,0,0,1,1,1,1,0,0,0,0,0,1,1,0,0,0,0,0,1,M  ->  06-01-01 01:10
0,0,0,0,1,1,0,0,0,0,0,0,0,0,1,0,0,0,1,0,1,1,0,0,0,1,0,0,0,1,0,0,0,0,0,1,1,0,0,0,0,0,1,1,1,1,0,0,0,0,0,1,1,0,0,0,0,0,1,M  ->  06-01-01 01:11

And in 2008:

        0,1,0,0,0,0,0,0,0,0,1,0,0,0,1,0,1,1,0,0,1,1,0,1,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,1,1,0,0,0,0,1,0,0,1,0,0,0,0,1,M  ->  09-01-01 00:59
0,0,0,0,0,1,0,0,0,0,0,0,0,0,1,0,0,0,1,0,1,0,0,0,0,0,0,0,0,1,0,0,0,0,0,1,1,0,0,0,0,0,0,0,1,1,0,0,0,0,1,0,0,1,0,0,0,0,1,M  ->  09-01-01 01:00
0,0,0,1,0,1,0,0,0,0,0,0,0,0,1,0,0,0,1,0,1,1,0,0,0,0,0,0,1,1,0,0,0,0,0,1,1,0,0,0,0,0,0,0,1,1,0,0,0,0,1,0,0,1,0,0,0,0,1,M  ->  09-01-01 01:01
0,0,0,1,0,1,0,0,0,0,0,0,0,0,1,0,0,0,1,0,1,0,1,0,0,0,0,0,1,1,0,0,0,0,0,1,1,0,0,0,0,0,0,0,1,1,0,0,0,0,1,0,0,1,0,0,0,0,1,M  ->  09-01-01 01:02
0,0,0,1,0,1,0,0,0,0,0,0,0,0,1,0,0,0,1,0,1,1,1,0,0,0,0,0,0,1,0,0,0,0,0,1,1,0,0,0,0,0,0,0,1,1,0,0,0,0,1,0,0,1,0,0,0,0,1,M  ->  09-01-01 01:03

In neither case was a leapsecond transmitted at the proper instance. In 2005, it was also not transmitted a minute early (as in 2016). My recording unfortunately started a bit too late to check this for 2008.

Also, note that the "leapsecond pending" bit was apparently not set in any of these years.

Update January 31 2017 about the 162 kHz timecode

Thanks to people at Agence Nationale des Fréquences (ANFR) and Chambre française de l'horlogerie et des microtechniques (CFHM) I got a copy of Norme Française NF C 90-002 from August 1988, describing the format of the TDF time signal.

The leap second announcement bits are in fact the 2nd (for positive leapsecond) and 3rd (for negative) bits in the minute. The positive leap second is to be inserted by inserting an extra 0 bit after the 3rd bit of the last minute of the hour.

Reinterpreting the 2016 data with this knowledge, we get:

0,1,0,  0,0,0,1,0,0,0,0,0,0,0,1,0,0,0,1,0,1,1,1,1,0,1,0,1,1,0,0,0,0,0,0,0,1,0,0,0,0,0,1,1,1,1,0,0,0,0,1,1,1,0,1,0,0,0,1,M  ->  17-01-01 00:57
0,1,0,  1,1,1,0,0,0,0,0,0,0,0,1,0,0,0,1,0,1,0,0,0,1,1,0,1,1,0,0,0,0,0,0,0,1,0,0,0,0,0,1,1,1,1,0,0,0,0,1,1,1,0,1,0,0,0,1,M  ->  17-01-01 00:58
0,0,0,0,1,1,1,0,0,0,0,0,0,0,0,1,0,0,0,1,0,1,1,0,0,1,1,0,1,0,0,0,0,0,0,0,0,1,0,0,0,0,0,1,1,1,1,0,0,0,0,1,1,1,0,1,0,0,0,1,M  ->  17-01-01 00:59
0,0,0,  0,1,1,0,0,0,0,0,0,0,0,1,0,0,0,1,0,1,0,0,0,0,0,0,0,0,1,0,0,0,0,0,1,1,0,0,0,0,0,1,1,1,1,0,0,0,0,1,1,1,0,1,0,0,0,1,M  ->  17-01-01 01:00
0,0,0,  1,1,1,0,0,0,0,0,0,0,0,1,0,0,0,1,0,1,1,0,0,0,0,0,0,1,1,0,0,0,0,0,1,1,0,0,0,0,0,1,1,1,1,0,0,0,0,1,1,1,0,1,0,0,0,1,M  ->  17-01-01 01:01
0,0,0,  1,1,1,0,0,0,0,0,0,0,0,1,0,0,0,1,0,1,0,1,0,0,0,0,0,1,1,0,0,0,0,0,1,1,0,0,0,0,0,1,1,1,1,0,0,0,0,1,1,1,0,1,0,0,0,1,M  ->  17-01-01 01:02
  | |                       | | | | | | | | -------------   -----------   ----------- ----- --------- ---------------
  | |  tomorrow publ.hol. --' | | | C C | |    minutes         hours          day    weekday  month        year
  | |  today public holiday --' | | E E | |
  | |         to be ignored ----' | S T | `--- unused, always 1
  | |  summer time announcement---' T   `----- unused, always 0
  | |
  | `---- negative leap second announcement
  `------ positive leap second announcement
So, indeed, the leap second announcement bit was set properly, and the leap second was indeed inserted as an extra 0 bit in the appropriate place. However, it still happened a minute too early, namely during the 58th minute rather than the 59th. (Recall that during minute n, the time code for the next minute n+1 is broadcast.)

One more illustration of TDF inserting the leap second a minute early, is by comparing the minute marker of TDF and its German (DCF77) and English (MSF) counterparts. TDF inserted the leap second into the 00:58 CET minute, the others into the 00:59 CET (= 23:59 UTC) minute, causing TDF's minute marker to be 1 second late at 00:59:00 CET:

(Horizontal axis is Central European Time, i.e., UTC+1; 00:59:60 is the leapsecond.)

Update October 2023, again about the 162 kHz timecode

Thanks to a reader of this page, I got a copy of an article about the France Inter timesignals that appeared in the French 'Bulletin BNM' in 1986. It explains the leap second procedure in more detail, showing that the leap second is indeed intentionally inserted one minute 'too soon'.

Fortunately, the document also explains why. The idea is that a receiving clock detects that the 58th minute has one second too many, therefore discards the received data and still shows correct time during the 59th minute based on its own internal clock. Then the receiver will re-synchronize during the 60th minute (which is transmitted as a normal 60-second minute), just in time to catch up with the leap second.

I must say I find this a rather odd procedure, as it makes quite some assumptions on how the receiving clock works. Then again, this 'trick' allows a receiver to correctly handle leap seconds without requiring any extra logic, thus simplifying receiver design.


Comments are welcome, at web@pa3fwm.nl.