Inspired by jr computing, I decided to write a python script which would allow you to set (and meddle with...) your UK-bought radio controlled clock, simply using the soundcard on your PC!
The vast majority of radio controlled clocks bought in the UK synchronise their internal clocks with the MSF radio time signal transmitted by the NPL from Anthorn, Cumbria. The signal is transmitted at 60 kHz at a power of 15 kW, allowing it to be received easily throughout the UK. More information on the transmitted time code can be found here.
I have some previous experience with the radio controlled time signal from Anthorn and fancied writing a simulator firstly because it might be fun to do(!) and secondly, I wondered what the clocks would do with a malformed time code. Could I make them display dodgy dates and times?
In a similar fashion to jr computing, I am using the third harmonic of a 20 kHz output tone from a PC soundcard to generate the time signal. In order to get the third harmonic as high in amplitude as possible, I am overdriving a 20kHz sinewave such that what is effectively a square wave is generated.
I decided to write the code in Python for reasons of portability and that after C it's probably what I'm most familiar with. See links below to the code along with a guide on how you can run the code and meddle with radio controlled clocks yourself.
You want the audio signal to radiate as much as possible. It's the RF signal radiating from the cable that the clock will be picking up - not the noise from the earphones. If you plug some earphones into the headphone connector on your PC and wrap it round your clock that should be sufficient. Failing that, do what I did and coil up a large amount of wire, connecting one end to the red/white wires from the headphone socket and the other end to the screen. You can then place your clock in the middle of this coil.
The code to simulate the MSF time signal is written in Python. It was developed on macOS but also tested on Windows and it works fine. I've not tested it in Linux but it will work fine there too. You will need to install numpy and pyaudio (click for install guides), if you don't have them already.
A couple of different versions of the code are available - my original, and one written by Matt Hart. He lives outside of the transmitter range and contacted me after he wrote a version that would allow him to automatically set his watches from his PC clock.
Plug your headphones in, wrap them around your clock, open a command prompt and run python msf.py or python msf_real_clock.py.
| msf.py |
The original msf.py file, tested on python 2.7.10 and 3.5.2 (it'll work on anything later, too). You can set the date to anything you want it to be in the code, the timecode will then start transmitting at minute '0' and increment to minute '59' before quitting. Lets you meddle with your clocks by setting invalid dates, if you want to! |
| msf_real_clock.py |
This version of the code is by Matt Hart and has been tested in Python 3.6.8. It broadcasts either the system time and date or a (valid) time and date of your choosing. It's ideal for automatically setting your radio controlled clocks and watches from your PC, if you live out of the transmitter's range. |
Once I'd finished tearing my hair out for an hour wondering why my code wasn't working (a '0' is indicated with the carrier being on by the way. Not off. Don't make the mistake I did. You'll tear your hair out.), I decided to see how my collection (yes, collection) of radio controlled clocks would cope with a sneakily malformed time code.
Yes, 2015 wasn't a leap year so there wasn't a 29th February 2015. Presumably the clocks, especially from Oregon Scientific, won't accept that as a valid date if sent in a time signal?
Oh.
Turns out Oregon Scientific don't check that the date is valid! I wonder what else we can do? Perhaps they're just checking that the day is between 1 and 31?
Perhaps not then! I should point out that this model, the Oregon Scientific Millennium 2000, was the only one of my collection which accepted a date greater than 31. It seems they've upped their game since 2000!
I wonder what would happen if I transmitted a really silly date?
:)
At this point I decided that I should probably stop playing with clocks and open the curtains. 5 minutes later when I started playing with the clocks again I noticed that left to its own devices the Millennium 2000 had completely lost the plot.
The MSF time code guide from the NPL describes a number of parity bits. These are designed to allow clocks to run some basic error checking on the data they receive. If the parity bits don't match then the clock knows that the data is corrupt and to ditch it. My code generates these parity bits and transmits them correctly, telling the clock that my malformed dates and times are correct. I wonder if the clock actually uses these parity bits though?
It turns out that no, most of them don't. 3 of the 4 clocks I tested my code with do not care what the parity bits are set to, which seems odd. I can't think of any reason for the manufacturer to ignore the parity bits and not check the sanity of the data they've received, but obviously they've decided not to bother. I have added the option at the top of my code to disable or enable parity bits, so you can check for yourself whether your clock cares about them.
So, given that most clocks seem to ignore the parity bits, how do they make sure that they don't show a corrupt time? All it would take is a tiny bit of interference at the wrong moment and the time would be corrupted.
Based on my testing, it turns out that what the clock is doing is waiting to receive two minutes of data in a row. It will then look at the data it received and ensure that the only change to the time between the two minutes is that the 'minutes' field has incremented by 1. Only at this point does it declare the time valid. Obviously if we are currently at the top of an hour and are transitioning from '59' minutes to '0' minutes then this test will fail, but this isn't really an issue as as soon as the next minute comes in ('0' to '1') the test will pass. To be honest, that's a pretty robust way of ensuring the time is correct.
Some clocks also ensure that the date (including day of the week) actually exists in the calendar. For example, Sunday 20th November 2016 exists, but Monday 20th November 2016 doesn't. Clocks will ignore the latter date and not update their display.
If you find that this code is not working with your clock then make sure that it is actually an MSF clock. A fair number of clocks sold in the UK, (especially by Aldi I've found) are actually DCF clocks which get their time from the German time signal on 77 kHz, then remove one hour to make it 'UK' time. This works because the UK and Germany observe the same rules around Daylight Saving's Time. If we ever diverged then there'd be a problem!
I hope this code gives you some fun at home. I'd be interested to hear your findings!
Andy C
Nov 2016 (updated Jan 2019)
andy@burningimage.net