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:

The longwave time stations MSF (United Kingdom) on 60 kHz and DCF77 (Germany) on 77.5 kHz nicely transmit their minute marker at the end of the leap second, as does RWU (Russia) on 4996 kHz (and vaguely on 9996 kHz?), and seemingly also whatever station we receive on 10000 kHz.
RBU on 66.66 kHz (Russian time station) missed the leap second: its minute marker (0.3 seconds of 312 Hz modulation just before the start of the minute) was transmitted just before the leap second, rather that at its end.
In the longwave (150-280 kHz) and mediumwave (530-1600 kHz) broadcast bands, there don't seem to be many stations transmitting time pips (fewer than in my 2008 recording). Those that do, don't seem to bother aligning them to UTC seconds (e.g., 576, 1071, 1593 kHz) at all, or getting the leap second right (918 kHz).
Same story in the shortwave broadcast bands. One typical pattern there is starting the new hour halfway the leap second, e.g. 6075, 6190, 7230, 7470, 7560, 9685, 9900 kHz. Checking transmission schedules, many of these frequencies seem to be associated with China Radio 1 and/or Firedrake jamming.
In the amateur radio bands (e.g. 3500 - 3800 kHz and 7000 - 7200 kHz), the QSOs (radio contacts) in morse code and single-sideband speech just continue across the leap second, as is to be expected. Some weak-signal amateur radio modes start their transmissions at exact pre-determined times, so those might be affected by the leap seconds. Indeed, around 3578 and 7078 kHz we see some signals starting at or shortly after the start of the new minute. Presumably, these are JT9 and/or JT65 signals, which normally start 1 second after the start of the minute, so it looks like the computers transmitting them did not observe the leap second.
As pointed out by a reader of this page, on 198 kHz live audio from the Big Ben in London was broadcast by the BBC. We can clearly see that Big Ben struck midnight without observing the leap second. (And as a consequence the 100000 or so people celebrating the new year in the area did so a second early...)
The 198 kHz signal also carries a time code in phase modulation. Decoding this, no leap second is immediately apparent, except that after midnight UTC, the once-per-minute time data frames arrive at 60.03 seconds intervals, rather than 60.00 seconds. Presumably, the leap second is taken into acount by slewing at a rate of 30 ms per minute. Due to the framing used, a faster slew might upset decoders; in fact, the documentation explicitly mentions a maximum allowed shift of 1 ms per at least 2 seconds, which equals the observed 30 ms per minute.
Since it was night at my location around this time, the higher shortwave bands are not open. Signals above 12 MHz are mostly local noise, and mixing products of the local pager transmitter on 26950 kHz.

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 pa3fwm@amsat.org.