[time-nuts] Receiving the MSF time signal on cheap radio modules

[Poul-Henning Kamp]

--------
In message <A2B31A8C-147B-4D35-BDC2-8D64D3743226 at n1k.org>, Bob kb8tq writes:

>If you want to get even more “nutty", look at the “seed” that you likely already have 
>for the computation. In this day and age, you probably know what day / month / year it is. 

So, some of us think of that as cheating :-)

>Since you might not (say) know the hour, you have a +/- 1 day sort of tolerance on that. It rolls 
>into month and year in some cases. The seed adds complexity, but probably makes
>things more robust. 

I tried it, and it gave surprisingly little benefit.

Unless very fast initial aquisition is your goal (why?!) you get a
more robust result by not "cheating", since in real life at some
point your RTC chip will contain bogus values.

If you go the SDR route and decode DCF77 and MSF (and 162kHz France,
WWV/B, the japanese signal at 40kHz and the russian at 200/3 kHz for
that matter) in parallel, it is perfectly fair to expect them all
to have the same date (modulus timezones).

And yes, I would really *love* to se a colaborative project that
produced an "all-world VLF timecode SDR-receiver"...

>One cute thing is that this stuff is (in general) not very compute intensive. If data past the 
>minute tick is being looked at, you probably can afford to run multiple parallel solutions (even 
>on a < $5 MCU). 

The NTPns ran on a Soekris4501 and I was never able to measure a
difference in power having the DCF77 blame code running or not.

After all, it's only sixty trival patterns to match once a second...

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.