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 <[email protected]>, > Chris > Kuethe writes: >> On Tue, Jan 13, 2009 at 7:30 PM, Brooke Clarke <[email protected]> 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/ > _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
