[ntp:questions] Re: refclock_wwv development version

David L. Mills mills at udel.edu
Sat Jan 14 16:49:48 UTC 2006


Sigh. Fudge time2 was intended as the propagation delay for WWVH. For a 
short time I forgot that and changed it as the codec clock frequency 
compensation, as in the IRIG driver. Then I remembered the folks on the 
left coast might have a nasty time as the ions shift east and west and 
changed it back. Once the driver has found the station and increased the 
time constant to 1024 seconds or so, the codec frequency offset should 
not matter. I've had it running here with 140 PPM offset, but I had to 
change the max offset MAXFREQ define to 1.5. It should be okay as-is to 
125 PPM.


wa6zvp wrote:
> Code mungers:
> I grabbed the latest devel release mainly to get the new utility for
> generating wwv audio test signals (thanks, Dave) and I noted some
> changes to refclock_wwv.c
> In one of the whitepapers by Dave about audio decoding of wwv signals,
> he mentions that there may be issues with codec clocks with frequency
> errors in excess of 64ppm.  On the only two audio cards that I got
> working, the codecs settled in the 80-90 ppm area, and I always
> wondered if thats why they did not perform very well.  Particularly
> when the signal disappeared for sometime and then reappeared.  In fact,
> they never recover.
> That said, the current refclock_wwv.c development code contains this
> statement:
> "Fudgetime2 is used as a frequency vernier for broken codec sample
> frequency."
>  Humm, that's strange since further down in the source it has the
> original explanation of the fudgetime variables, being for the
> different delays from WWV and WWVH.
> Is this possibly an upcoming enhancement?  The only place that these
> fudgetime values are used in the source appear to support the two
> different delays.
> Should I not worry about a codec clock at 80ppm and look elsewhere for
> troubles?
>  Roger
> (roger(at)hmc(dot)edu)

More information about the questions mailing list