[ntp:questions] Re: CHU prop delay

David L. Mills mills at udel.edu
Wed Oct 6 00:34:25 UTC 2004


Steve,

You need to include the receiver and modem delays to the fudge budget. 
Also,  the ray path might bounce off the E layer, height 110 km, at some 
frequencies during the day. Best to calibrate from other sources known 
to be accurate and fudge what you judge. The first fudge is correct (34 
milliseconds), but the second is not (34 microseconds).

However, 34 milliseconds is like to Hawaii from Ottawa. If you are 34 ms 
away and can still hear CHU, you should write and ask for a QSL card.

Dave

Steve Kostecke wrote:

> Here's what propdelay says I should use for CHU:
> 
> CHU summer propagation, height 350 km, hops 3, delay 0.034592 seconds
> CHU winter propagation, height 250 km, hops 3, delay 0.033985 seconds
> 
> If I 'fudge 127.127.7.1 time1 0.034592':
> 
> $ ntpq -c cl my_chu_box
> assID=0 status=0101 clk_noreply, last_clk_noreply,
> device="CHU Audio/Modem Receiver",
> timecode=" 0 2004 279 21:29:48  4 -5 1 255 CHU1 90 49", poll=0,
> noreply=2162, badformat=144, baddata=1, fudgetime1=34.592, stratum=0,
> refid=, flags=8
> 
> If I leave time1 set to 0.034592 the other remote time servers
> configured on my CHU box eventually show an approximate offset of 35.xxx
> (this takes a while, so I won't be pasting it here.)
> 
> If I 'fudge 127.127.7.1 time1 0.000034592':
> 
> $ ntpq -c cl my_chu_box
> assID=0 status=0101 clk_noreply, last_clk_noreply,
> device="CHU Audio/Modem Receiver",
> timecode=" 0 2004 279 21:29:48  4 -5 1 255 CHU1 90 49", poll=0,
> noreply=2162, badformat=144, baddata=1, fudgetime1=0.035, stratum=0,
> refid=, flags=8
> 
> Which is correct?
> 




More information about the questions mailing list