-------- In message <a2b31a8c-147b-4d35-bdc2-8d64d3743...@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 p...@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. _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
