[time-nuts] WWV / WWVH / WWVB

Brooke Clarke brooke at pacific.net
Wed Jan 14 16:56:58 UTC 2009


Hi Poul:

Thanks for that info.  It's sort of what was done in the PST1020 WWV-WWVH 
receiver, although an improvement, see patent 4768178 High precision radio 
signal controlled continuously updated digital clock August 30, 1988
http://www.prc68.com/I/PST1020.shtml
http://patft.uspto.gov/netacgi/nph-Parser?patentnumber=4768178

This Google patent search on 4768178 has many hits for improvements on that idea:
http://www.google.com/patents?q=4768178&btnG=Search+Patents

My first problem is to hook the front end up to a couple of batteries and a LED 
to find a good place for the antenna.

Have Fun,

Brooke Clarke
http://www.prc68.com

Poul-Henning Kamp wrote:
> 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/
> 





More information about the Time-nuts_lists.febo.com mailing list