Pragotron Slave Clock – Part 3 – Software

My previous experiments around decoding long wave radio time signals primarily involved using the UK’s time signal MSF60 ( previously known as the Rugby time signal. This transmission no longer originates from Rugby, it moved north to cumbria and seems to have reduced power during the move, combined with the fact the the 60kHz signal seems to be drowned out by RF interference from my computer equipment made me look at alternatives.

Whilst looking around I stumbled across some work by Udo Klein ( Udo recognised the fact that interference to these signals was a big problem and wrote a library that would effectively use some digital signal processing techniques to improve the receivers immunity to noise.  Clearly where the signal is drowned out by computer RF interference all bets will be off but in locations where there is mostly a good chance of reception the algorithm does allow much noise to be ignored and lead to time recovery.

I extended this library for MSF and Udo has since merged these changes into the repository so you can try it out for yourself and see how you get on.  The performance seems a lot better than just using averaging and copes well with transients of noise.  Be aware however that correct positioning and orientation of the radio clock module is still vital, you need to experiment and should get flashes around 1 or 2Hz, crazy flashing probably means you are picking up your computer RFI rather than the time signal.

I have a collection of MSF and DCF modules now, either would work but for this project I decided to go with the last one I had connected so I am receiving the time signal from DCF77 (

It seems that summer time for DCF77 now occurs at the same time that UK time changes it’s daylight savings (EU good for standard harmonisation, not so good for uncontrolled migration, un-democratic super-state etc, bring on June 23rd!) so the clock simply has to maintain a fixed offset and the daylight savings should work OK.

Most of the hardwork is done by Udo’s library but the extra code and a copy of the DCF77 decoder is here (

And it works!

Posted in Uncategorized | Leave a comment

Pragotron Slave Clock – Part 2 – High level design

So with my clock sitting idle on the wall it is time to come up with a design that will send it periodic pulses, once per minute, with +24V and then -24V on alternate minutes…

I really want this to be pretty stand-alone and I don’t want to faff about with WiFi so that eliminates NTP, I do not want to be near a window so that eliminates GPS so that leaves me with either a free-running clock or radio frequency receiver.  My recent experiments with the MSF radio signal, which is really hard to receive around computer equipment in London, led me to DCF77 which has similar problems but has better signal strength.  The MSF signal moved further up north a few years back and the transmission power was also reduced during the move so surprisingly DCF seems to work better here.

I plan to use some off-the-shelf parts so I’m not going to be clever in the first iteration at least… I need a controller, a radio clock module, a 24V supply, an H-bridge to send 24V (and reverse the direction each minute) and for fun an LCD display and a couple of buttons to change modes etc.  Modules are cheap as chips from China so I’m just going to attach a few things together and maybe later reduce the design and make a PCB.


Here’s the Radio Module I bought from PV Electronics ( (who also make nice NIXIE kits)…


I put it in a cardboard box for now, at the end of a bit of cable so I can move it away from my computer monitor.  RF Interference from computer equipment completely prevents reception using these receivers, the MSF 60kHz or 77kHz DCF signal being too close to the timebase in monitors etc.



For the display I have a 16×2 LCD display with Hitachi controller in the junk box, for the controller a cheap chinese UNO clone and then a H-Bridge module and DC-DC converter (5V to 24V) from EBAY.  Three chunky buttons complete the hardware.


and inside the box…


The LCD display wires straight into the Arduino UNO, with just a small 10k potentiometer to allow the contrast to be varied, it is a 5V display so compatible with the 5V Uno clone. The DC-DC converter is just a quick and dirty way to turn 5V into 24V and the H-Bridge a simple (rather over the top way) of being able to reverse polarity to the clock.  (The radio module is located in the cardboard box for present a metre or so away).

It’s almost unbelievable how cheap some of these parts have become.  The L298N H-Bridge can be had for around £1.50 from HK on Ebay, the XL6009 DC-DC converter for around £1 and with a bit of shopping around the Uno clone is about £2.50.  So hardware cost is around £10 plus the radio module.

When choosing a Arduino Uno clone take time to try and find one with a crystal oscillator (shiny metal can next to processor) since the DCF decoding software needs a reasonably accurate local clock and some of the ceramic resonators in the Uno clones are terrible (2000 ppm).  If you are unlucky enough to get one with a ceramic resonator then with a bit of careful soldering you can easily replace the resonator with a crystal.

Posted in Uncategorized | Leave a comment

Pragotron Slave Clock

Whenever I am really busy it seems I get distracted, maybe a failing, I guess, but it always makes life interesting.  Recently I came across a number of articles on electrically driven clocks, slave clocks, which are mechanical devices that are driven from a central point by periodic electric pulses.  These clocks previously found in schools, factories, railway stations etc. are obsolete now, or at least the original electric ones are, and appear every now again on EBAY.


I first bid on a couple of large old clocks made by English manufactures of the past but always got outbid since these seem to be highly collectable despite many of the examples being in very poor shape.  But eventually I found a listing for a large Pragotron ( clock.


What a beauty!  It has only an hour and minute hand but that works well for my room as I do not want noise from a continuously moving second hand. The wire for the timing input enters from the bottom.


It’s large!  Roughly 47cm in diameter on the front and a bit bigger on the back with flat glass pane above a concave shaped face which has raised detail for the hour and minute markers.  (There are also smaller versions which are more common, those being around 33cm diameter)

On the back is a plaque showing it to be a PV42 requiring a 60 volt pulse once per minute. I think it’s made of Bakelite, not sure of date.


A little research reveals that the slave clock mechanism inside can have two settings: 60V or 24V.  I clearly wanted to use 24V as this was easier for me to generate so I tested the clock by applying +24V and the hands moved on one minute so I guess this modification had already been made by the previous owner (thanks!).  The mechanism requires that the polarity of the applied pulse should reverse for each pulse so I reversed the wires and it moved on again with a satisfying station clock clunk noise.  Awesome! We have a project!

I would like this clock to keep accurate time (i.e. must be radio, GPS or NTP controlled), be self-setting, automatically adjust for daylight savings and to be tolerant of power outages, fixing itself when power is restored.

It seems many of these clocks have been retro-fitted with new quartz movements some with radio clock receivers however I want to keep the clock as original as possible and in particular I want to retain the satisfying clunk sound that probably was heard across the platform in some East German train station counting down the minutes to  whisk the agent away from the Stasi…

Now this is will be interesting….



Posted in Uncategorized | 3 Comments

MSF Clock Synchronisation for Microcontrollers – Part 6 – Decoding the signal

Decoding the signal

The specification for the NPL time signal (previously Rugby Time signal) is described at with each second of transmission encoding two bits (A&B) except for the minute marker which encodes zero bits but instead marks the epoch.

Time information when transmitted normally comprises 59 sets of two bits except for minutes that include an extra leap second (60 sets of 2 bits) or a absent leap second (58 sets of 2 bits).   My interpretation is that during an additional leap second minute the Year code starts in the 18th second and an extra second is inserted after the DUT code; during a negative leap second minute the 16th second (containing 16B of the DUT code) is omitted and the year code starts in the 16th second.  Detection of the length of each minute is not-obvious but can be detected by inspecting the 01111110 pattern that occurs in the last eight seconds of each minute.

Below is an example of a decoding of the sample captured at the end of previous post.


the protocol includes parity bits for the year, month/day, day of week and hour portions but is only resilient to a single bit error; in this example it indicates that all is intact.

The decoded time is 00:10 on Friday 19th June 2015 with BST in effect, no DST change imminent and DUT -700mS.  The message pertains to the following minute so the following minute marker indicates the epoch.

Posted in Uncategorized | Leave a comment

MSF Clock Synchronisation for Microcontrollers – Part 5 – A closer look at the noise

Comparing samples from clean and noisy environment

I have a highly accurate time source in the form of a Motorola VP Oncore GPS which emits a short pulse every second which is within microseconds of UTC and hence can use this pulse as a reliable indicator of phase.

I set up a small program that synchronises to the GPS 1PPS pulse and then records samples every 1mS for the following second.  Each sample is then placed in a bucket of 11mS and the majority high or low is used to produce a 1 or a 0.  (11 is a good number as it is odd, i.e. there is never any doubt about whether high or low is in the majority, and it divides the second into a good number of samples).

Below is a sample shown for just the initial second, the minute marker, for several minutes in a ‘medium’ real-world noisy environment on the edge of my desk (where I would like my clock to reside) and then lastly two samples from a ‘quieter’ environment near the window.


The numbers of the right hand side are, total samples, number of hi in first 50 buckets (555 samples), number of hi in last 50 buckets (555 samples), and three numbers indicating the population of 3 buckets in each of the estimated mid-points for the 0-100mS, 100-200mS and 200-300mS pulses.

It is noteworthy that at the start of each sample is a quiet period of around 17mS.  My distance from the transmitter translates into only a couple of mS so this delay must be due to the lock-up time on the phase locked loop of the receiver.  I think it is fair to say that observations so far suggest the PLL takes around 20mS to lock and around 50mS to unlock.

Analysis of the mean and deviation of the sample suggests that the minute mark may be recoverable with very limited confidence level.

A closer look at second 59

Continuing on our investigation with the second that precedes the minute marker which we always know will be A=0,B=0


Here we really see the effect of the noise with the external RF interference knocking the PLL out of sync and producing spurious streams of erroneous data.

Statistical analysis here shows that averaging across signals would not produce the correct result, the noise has overwhelmed the receiver.

Final reflections on noise

The receiver module I am using does the majority of the work for us, it receives the 60kHz CW signal and using a tone decoder/phase lock loop of some kind translates this to a logic output (and helpful inverts it).  The receiver works very well in ‘quiet’ environments but in realistic noise environments around my computer (the location I would like my clock) it cannot cope with the PLL losing lock and producing highly spurious outputs.

Once you know the accurate time (slightly against the spirit of trying to decode the signal in the first place) it is possible to generate the local signal prediction (especially if you gloss over the details of leap seconds and day light saving changes) in which case the problem would reduce to one of calculating phase only but even this seems to be challenging in the RFI environments I was considering.

Spectral analysis suggests a noise peak at 144.5Hz so a low pass filter might help but statistically from the samples I have taken it would still not give a good level of confidence with the signal.

Therefore it seems that rather than any further signal processing in the noisy environment I need to relocate my receiver to a quieter location or seek an alternative time source.  It should be noted that even in a quiet location there will be some spurious noise but this should be easily eliminated by averaging… more of that later.

And finally a look at what we get when we do find a quiet spot

It’s a bit disappointing to conclude that signal processing won’t really help us recover a signal in the presence of real-world noise but if you accept that fact and relocate the receiver a metre or so away to a quieter spot the receiver module (here) does a great job on its own.

fullMinNext we will look at recovery of the time/date from a relatively noise free sample.

Posted in Uncategorized | Leave a comment

MSF Clock Synchronisation for Microcontrollers – Part 4 – Noise

Comparing signals from two receivers

I have two receivers so thought it would be interesting to put one in a good reception position, approx 2 metres away from any electrical equipment, and another on my lab desk and compare the signals from each.  As has been observed previously receivers near my computer monitor shows rapid flickering and loss of lock whereas the ones near the lab window shows a contented pulsing as it receives the time signal.

Control configuration – Two receivers, both away from noise

By way of a control I first put both receivers away from PC equipment and compare output from each receiver.


Here we see two nicely correlated traces.  The amplitude differs because each has an independent supply, one being powered from the 5v USB supply of the PC and the other by 2 AA-cells but otherwise these signals are clean of noise and illustrate that when well sited the receivers can produce a clean, easily decoded output.

Moving one receiver closer to the computer – Feel the noise!


Here we see the clean signal at the bottom whilst at the top the signal is blown away by the computer induced noise.  No chance of decoding the top receiver!

A closer inspection shows that the two peaks in the lower trace, this is an A=0,B=1 second are not easily visible in the top trace. There is some information in the top trace but recovery looks challenging.


Looking at some other examples and differencing the traces, see middle line, shows that in the upper trace some features have been completely erased by the noise.  No amount of signal processing will recover those!


Again, here we see the top trace showing no sign of the 100mS pulse in the lower, the trace has effectively flat-lined for the first half of the measurement missing the 100mS entirely, we can assume that both A and B bits would be unrecoverable in this scenario.


Moving the roving receiver to a position that is mid-way between the computer and the lab window, i.e. middle noise levels, shows a different situation.  Here we see noise on the top trace but the information is clearly present and some form of integration/low pass filter may be able to recover it.  However the width of the pulses is not consistent, the bottom trace might be A=1, B=0, whereas the top trace looks more like A=0,B=0.  Looks like these pulses really aren’t able to cope with much real-world interference before they become unrecoverable.



When a clear signal is present the receiver does a good job of filtering the input and presenting a precise representation, near sources of significant interference, (computer power supply, computer monitors, computer keyboards?) the noise can be significant enough to make recovery of the signal impossible, implementation of clever digital filtering techniques seems pointless.  However, when the receivers are adjacent but not too close to noise sources creates a mode where the MSF signal may be recoverable with a degree of signal conditioning.

To start with I think I will go for the simple case where noise has been effectively discriminated by the receiver, the aerial having been located in a favourable position, later I may look at averaging to increase reliability in the presence of moderate noise.  Tricky stuff!

Posted in Uncategorized | Leave a comment

MSF Clock Synchronisation for Microcontrollers – Part 3 – MSF Minute Marker

At the start of every minute

Each  minute starts with a minute marker comprising 500mS carrier off and 500mS carrier on with the details of this minute having been encoded in the 58 (negative leap second), 59 (normal), or 60 (positive leap second) seconds preceeding.

The signal is shown below (inverted).


Personally I don’t find the official specification at very clear on exactly where the minute transition is relative to the two 500mS sections so I have been doing some investigation and came across an interesting page at which shows a waterfall plot of two time signals during a leap second transition.


And if you zoom in very closely you can see the waterfall for just one second of MSF signal timestamped against a locally NTP synchronized PC clock, my interpretation of this is that the start of carrier off is the minute transition. i.e. the carrier is off for the first 500mS of the new minute and then on for the next 500mS.  (Note: Signal in my oscilloscope screenshot above is inverted).

As an aside it is very interesting to discover which allows you to listen to signals around the world over a huge range of frequencies. For my purposes WebSDR in Peterborough, England (IO92VO) at yielded a nice waterfall of the MSF signal although I’m not sure of the latency of these feeds so won’t rely on them for determining the minute transition.


I’m pretty happy to have concluded that the minute starts with the carrier turning off for the minute boundary. i.e. a positive edge for my inverted signal.  However clearly the minute marker is yet to arrive at this point so my software implementation will use the initial transition but combine this with receiving the preceding of A-bits 01111110, once these two conditions are met I will consider a good minute mark.

Posted in Uncategorized | Leave a comment