MSF 60khz national timecode decryption.

I'm writing code for a pic micro to decode the msf timecode signal which has moved from rugby to anthorn.
The datasheet for the code says that every second the carrier is switched off for 0.1, 0.2 or 0.3 seconds depending whether the data is 0, 1 or parity, with the exception that second 0 has a 0.5s off time to mark the start of the minute.

All very well, but when I connected an led to the output of my msf receiver there is clearly 2 or 3 places where the carrier switches off and on for about 0.1s, these occur around second 10, which is the point where the difference between UTC and GMT is broadcast.

This is contradictory to my datasheet which says there is a minimum of 0.5s carrier every second.

I looked for other data on the encoding, couldnt find anything different, anyone shed any light on this?

It's nice to hear MSF back on the air, it was off for the past two weeks.
I agree with what you are saying, I'm listening to it on an LF radio receiver right now but I think you are mistaking the second marker for the other data bits. The carrier isn't switched off for 0.1, 0.2 or 0.3 seconds, these are the time slots for carrying data. It is always off for 0.1 seconds but it may be on for the 0.1 to 0.2 second period then off again for 0.2 to 0.3 seconds period, it sounds like a rapid beep on the radio but it is correct.

Brian.

Yep sussed it.
I can listen to it but my receiver wont do cw, so I have silence and noise rather than a beep.
I'm not so far from anthorn, so my ebay special regen msf receiver with a digital output picks it up no probs with the ferrite loopstick in any position (last time I tried this a couple of years back I hacked a wall clock movement, there are 4 tracks to a seperate blak blob on the board, 2 power, one data and the other is a power up signal for the rx (to save battery).
Your sposed to be able to get the signal anywhere is europe.
Anyways I relalised that there is 2 bits, as you say a 0.1s marker then bit a and bit b, the npl data doesnt make this too clear, or maybe I'm just a dumb farmhand.
Wikipedia suggest making the software receive 10 bits of data, the second and third containing the data wanted.
I'll try a variation on this, have a seperate routine that detects the minute marker and resets the second counter, and another that 'listens' at 0.15s and 0.25s the centre of the 2 a and b data bits.

When I did this I used a different technique. I timed the pulses to find the "minute marker" then using delays I sampled both the 'a' and 'b' bits 60 times so I had complete copies of the time/date and UTC information. At the 60th bit I rechecked for the long pulse again to be sure I was properly synchronized. The two 60-bit long binary numbers were then split into the component parts to recover the information. It worked well and always returned information in less than two minutes.

Brian.

Mines slightly diffo, I look for a carrier off signal, then start a counter at 100hz, then sample the first bit half way along its duration, and then the second in a similar matter, and then when the counter gets to 450 msec and I check for the start bit, and then reset the counter and go again, if the start bit is present the seconds counter is reset and the new data written to a 2 by 16 display.
When the carrier has been on for 600msec this increments the seconds counter.

Seems to work well except its one second behind all the time and second 00 is displayed for 2 secs, I just realised what it is, I look for a 600msec carrier on to increment the seconds, thinking there is allways 700msec of carrier on in a second, but there isnt, second 00 is only 500msec, thats why my counter isnt incrementing, gonna change that now and see.

I'm going to add this to an electronic long case clock I made, and maybe try and synchronize the pendulum to the msf, getting the pendulum in sync is gonna be tricky.

Thanks for the feedback.

Sometime we look at code so hard we miss the obvious flaws!
The long case clock sounds like something you should show in the "Show DIY" section when you get it working. - Good luck!

Brian.

I have a protoype longcase with a pendulum using G clamps as weights, still needs some work.
However I completed the section for decrypting msf, the software displays time, date, summer/winter time and checks the parity bits.
Rather than blank the 2*16 lcd display, it just says ok or bad depending whether the parity check passes or fails.
To free up the pic's time to control the pendulum only the seconds part of the display is updated every second, and the time updates every minute, the date when it changes.
Seems to work well so far, allthough I had to port the software from the pic16f676 I was using to a pic16f88 as I ran out of memory, its the first time I've used the '88, took me a while to suss out the oscillator business, complicated.
I rang the speaking clock and there is no discernable difference between the speaking clock and the display.