[ntp:questions] refclock_wwv development version

wa6zvp wa6zvp at gmail.com
Sat Jan 14 03:08:57 UTC 2006


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