He/They are missing out on a very big S/N improvement for DCF and
similar signals.
In reality only a very small subset of possible 2**59 timegrams are
potentially valid. For instance day of month cannot be > 31.
Even fewer timegrams can follow each other, for instance the day of
month cannot change unless a lot of other fields also change,
or conversely, a lot of fields can only change if the hour
field changes to one specicfic value.
I used this in my old NTPNS dcf77 decode, with the result that it
can lock on to DCF77 in a matter of minutes, even when most of the
pulses are mangled.
Source code:
http://phk.freebsd.dk/phkrel/NTPns.20080902.tgz
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@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.
--------
In message <20170323041013.GA4678@panix.com>, Ron Bean writes:
>http://hackaday.com/2017/03/22/well-engineered-radio-clock-aces-form-and-function/
>
>https://create.arduino.cc/projecthub/edr1924/dcf77-analyzer-clock-v2-0-c25404
He/They are missing out on a very big S/N improvement for DCF and
similar signals.
In reality only a very small subset of possible 2**59 timegrams are
potentially valid. For instance day of month cannot be > 31.
Even fewer timegrams can follow each other, for instance the day of
month cannot change unless a lot of other fields also change,
or conversely, a lot of fields can only change if the hour
field changes to one specicfic value.
I used this in my old NTPNS dcf77 decode, with the result that it
can lock on to DCF77 in a matter of minutes, even when most of the
pulses are mangled.
Source code:
http://phk.freebsd.dk/phkrel/NTPns.20080902.tgz
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@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.
