Something a little bit special happened at the end of 2016. Most people won’t really care about this sort of thing, but to as a contributor to an OpenSource library for decoding broadcast time standards, this sort of thing slightly plays on your mind.
Over the past year I contributed to Udo Klein’s https://github.com/udoklein/dcf77 library which provides Arduinos and similar with a library resilient to noise. My contribution was to extend this library to support the UK time signal (used to be broadcast from Rugby hence known as the “Rugby time signal”, now known as https://en.wikipedia.org/wiki/Time_from_NPL) .
DCF originates from Germany on 77kHz, MSF from somewhere up north on 60kHz. Actually both signals work pretty well as long as you have a directional antenna not pointing in the wrong direction and are reasonably far away from computer monitors and switching power supplies.
At the end of 2016 there was a leap second! https://en.wikipedia.org/wiki/Leap_second
Now a second might not be a big deal to many but for developers of noise resilient radio decoding software it becomes quite interesting. Udo’s library uses some signal processing concepts to lock onto the phase of the time signal, essentially there is a convolution between the received signal and the predicted signal and this result is used to keep everything in step even in the presence of noise and local oscillator drift. A leap second causes a discontinuity in that phase so is of interest…
So as I charged my glass, nipped outside for first footing (https://en.wikipedia.org/wiki/First-foot) whilst leaving a MSF receiver and Arduino running with samples taken every 10ms, subsequently reconstituted the data into a readable signal. My receiver is nicely positioned away from computer equipment so this was a mostly noise free set of data.
Here’s what happened in the minute before the leap second, the minute of the leap second and the minute following the leap second…
MM is the minute marker (500ms carrier off, 500ms carrier on), A and B show if the A or B bits are set.
Everything went nicely according to the MSF specification, the extra second was inserted at second +16. The time signal gives the time that will prevail at the NEXT minute marker so we see the long minute encoding 00:00 1st Jan 2017 even though it was being transmitted towards the end of 2016.
For a leap second there is no indicator prior to its occurrence (not in MSF anyway, the clever DCF people have a leap second announcement at :19) so this all happens with a bit of a surprise however looking at the data it’s quite interesting to observe that given the leap second the DUT1 Code also has to change and change very significantly since time has just moved 1000ms.
DUT1 you say? Never heard of it! https://en.wikipedia.org/wiki/DUT1
So the MSF implementation could probably benefit from a bit of an enhancement such that if you are processing the last minute of the year then expect a leap second and if you see DUT1 change then it most likely has happened.
Not a big deal since phase is quickly regained but interesting nevertheless.
Happy New Year!