[time-nuts] WWV / WWVH / WWVB

[Poul-Henning Kamp]

In message <91981b3e0901131942x68117af5wbf96191c4f766f00 at mail.gmail.com>, Chris
 Kuethe writes:
>On Tue, Jan 13, 2009 at 7:30 PM, Brooke Clarke <brooke at pacific.net> wrote:
>> Hi Scott:
>>
>> Press F5 at:
>> http://www.prc68.com/I/Loop.shtml#CMMR6P60
>> and scroll down to see a scope image.  Not sure if the dots are caused by the
>> sampling scope or by noise?
>
>I'm going to guess your reception sucks. I hooked up an LED to the
>output to of mine... during the day, I get a lot of short blinks.
>Later in the evening or at night the 200, 500 and 800ms pulses are
>solid and clearly identifiable. They look that way on a scope, too.

Some advice on decoding these signals:

There are two dominant forms of noise:

	Missing pulses.

	Stray pulses, mostly very narrow.

Even when blanketet by stray pulses, there is a strong correlation with
pulses starting at the time where the "real" pulses should be.

Therefore, once you have established the second epoch, only pulses
that start close to it should be considered, anything more than
about 10-20 msec off the epoch can be ignored.

Here is a relevant comment from NTPns' DCF77 code:

/*
 * This is slightly complicated, but there is a good reason:  In order to 
 * minimize the effects of noise which mostly take the form of spurious extra
 * pulses, we want to poll the PPS-API as soon as possible after the likely
 * end of the pulse.
 *
 * Once we have a pulse of valid length, we poll again 1.135 second after
 * the start time of that pulse, to look for a following short pulse.
 *
 * If we find a valid pulse at that time, we start over from above, if no 
 * valid pulse is found, we look for a long pulse .1 second later.
 *
 * If we find a valid pulse at that time, we start over from above, if none
 * is found we look for a short pulse .9 second later.
 *
 * A slight complication here is that our pulses are timestamped on
 * CLOCK_REALTIME, but eventlib may run on CLOCK_MONOTONIC and the fact
 * that we can only fiddle the interval setting on recurring timers.
 *
 * All the magic numbers are tweakable.
 *
 *
 *     A     B  C  D  E                                 a     b  c  d  e
 *     v     v  v  v  v                                 v     v  v  v  v
 *
 * ----       ----- ------------------------------------       ----- -------
 *     |     |     |                                    |     |     |
 *     |     |     |                                    |     |     |
 *      ----- -----                                      ----- -----
 *
 *
 */

The other thing is, once you have elminated noise pulses, how do you
interpret the timecode when some pulses are missing ?

The robust way is to try out each of the possible 60 locations for the
start of the minute, and see if the data content proves it wrong:

/*
 * This receiver use the reverse principle of all other DCF77 receivers I have
 * seen implemented, instead of relying on the S/N to be good enough for the
 * correct minute-synchronization to trivially stand out (ie: by the absense
 * of the 59th second pulse), I instead start out with 60 possible hypothesis
 * for where the minute starts, and disprove them as I collect bits.
 *
 * There are many features of the DCF77 timegram which can be checked even
 * though we do not know what time/date it actually is.  For instance a minute
 * reading of 71 would obviously be wrong, as would illegal BCD digits, wrong
 * parity or the two timezone bits being identical.
 *
 * It is possible to also check that the first 14 bits follow a particular
 * pattern, they have been zero every single time I have looked but the
 * PTB reserves the right to play with them.
 *
 * The principle behind this is based on the observation that noise almost
 * always consist of missing pulses, and that '0' and '1' bit pulses very
 * rarely gets confused.
 *
 * This method allows us to tighten the frontend filters much more than
 * other receivers because we can tolerate a high ratio of missing pulses.
 *
 * It is interesting to note that this method does not even require a full
 * minute worth of pulses before the top of the minute is uniquely determined:
 * even though we only have one or two bits actually supporting it, all other
 * possibilities have two or more bits rejecting them as possibilities.
 *
 */


NTPns can be downloaded from here:
	http://phk.freebsd.dk/NTPns/phkrel/

-- 
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.