Loading ...
Sorry, an error occurred while loading the content.

Re: [dxatlas] Re: Timing Question

Expand Messages
  • Peter
    Hi Philip, Great to hear from you. I much appreciate the views of someone with your experience. You are correct, I think the interesting characteristics of
    Message 1 of 29 , Nov 19, 2009
      Hi Philip,

      Great to hear from you. I much appreciate the views of someone with your

      You are correct, I think the "interesting characteristics" of my
      wireless broadband link is fundamentally where the problem lies. There
      are significant differences in the two directions in terms of delay,
      particularly as my link goes through a repeater before hitting the phone
      cell and onto the wired network. Also, my link is used by others on this
      local area network - I have at least 6 PCs using the link creating
      congestion. All but two are mine - so I have some control over the

      A college has a wired ADLS2+ Internet connection and has very good time
      for Faros - no problems at all. Interestingly, his "delay correction" in
      Faros is 10ms, mine is 60ms.

      No use is made of the time on the local PC by the Faros software. The
      beacons we are listening to, use a PPS, GPS based time reference. We
      need to be close to the beacon time, so we can know from which direction
      the signal came - the short way around the earth, or the long way around
      - and not too far off, or we miss the beacon completely. Exactly how
      accurate we need to be is difficult to work out as its a factor of many
      things including delays in the PC, the radio, the RF propagation, the
      beacons themselves. Faros has a "delay correction" to compensate for the
      actual delay we experience in the PC and other components. Most
      importantly we need stable time, and then use the "delay correction" in
      Faros to compensate for any offset. That way all the differences in the
      observation of the signal are due to the RF paths, and we can do RF
      propagation studies with the data.

      I'm not sure what "command" you used. Here is my output for one my NTP
      servers - on the same PC as Faros - for the command "peers", a few
      minutes ago.

      remote refid st t when poll reach delay offset jitter
      -mirror.dedicate 2 u 79 256 377 58.258 -10.218 4.514
      duffman.springf 3 u 98 256 377 98.802 -9.846 33.042
      *cachens1.onqnet 2 u 116 256 377 59.203 -12.518 3.518
      +ntp.bigcheese.o 2 u 127 256 377 109.652 -22.972 26.313
      hit-nxdomain.op .STEP. 16 u - 1024 0 0.000 0.000 0.000
      +toc.ntp.telstra 2 u 238 256 377 72.537 -21.892 6.308

      The above is the result of several weeks of experimentation with several
      lists of servers. I no longer use this local server, or several others,
      with Faros. Faros goes to the server list directly - I get a much better
      result from Faros going directly to the Internet servers rather than
      having the local servers included.

      When I included the local servers in the list of servers for Faros, I
      finished up with Faros giving too high a preference to the local servers
      - small symmetric delay and low dispersion - and "faros time" became a
      straight line following the offset of the local server(s) - a straight
      line with accumulative error as high as 50ms every 15 minutes, which
      then "corrected", sending Faros off in another direction. This sent the
      beacon observations on a roller coaster ride up and down for which the
      "delay correction" in "Faros" was unable to compensate.

      My conclusion was that I needed more "randomness" in the time
      observations made by Faros - to avoid skew in the input to its Kalman
      filter - that is more randomness in the "delay", and offset, so Faros
      would not weight one server over another, allow the Faros Kalman filter
      to do its job, better.

      This has proved correct, as I now have stable time and acceptable
      observations from Faros. Given I seem to be able to implement a GPS
      based solution, the same as the beacons, for around $100 US, and given
      this is my hobby, I choose to attempt the best result I can get - a PPS
      GPS time reference.

      But, fundamentally, I am happy with the NTP time service from the
      Internet - so far, touch wood!

      Peter VK4IU

      Philip Gladstone wrote:
      > This conversation is a bit puzzling to me. I'm not a Faros user, but I
      > am a timing person from way back (I did the original version of the
      > Linux timing code to support NTP).
      > In order for Faros to work, it seems that the time on the PC should be
      > correct to within a few hundred milliseconds. The normal errors in NTP
      > are over the order of a few milliseconds PLUS any latency differences
      > between upstream and downstream on the access link. 3G networks do have
      > "interesting" latency characteristics -- though I don't know whether the
      > upstream latency is significantly different to downstream latency. This
      > seems like an interesting experiment to try.
      > It would be interesting to see the ntpq output for systems where you
      > don't think that the timing accuracy is good enough. In the interests of
      > full disclosure, here is mine:
      > *tock.usno.navy. .USNO. 1 u 1005 1024 377 30.675 1.084
      > 0.882
      > +cs.columbia.edu clepsydra.dec.c 2 u 4 1024 377 14.186 1.416
      > 0.705
      > CDMA-2.MIT.EDU 16 u - 1024 0 0.000 0.000
      > 4000.00
      > +broadbandjam.co ntp.pbx.org 3 u 85 1024 377 104.393 2.772
      > 1.097
      > -14.1e.5546.stat ntp.tmc.edu 3 u 17 1024 377 71.560 -5.013
      > 2.797
      > - nist1-la.witime 2 u 524 1024 377 98.060 -4.563
      > 0.602
      > It seems likely that my clock is right to within a few milliseconds.
      > Because I am a timing geek, I'm intending to add some local clock
      > sources (including GPS PPS).
      > Getting time right to less than a millisecond is pretty difficult......
      > Philip
      > Peter wrote:
      > >
      > >
      > > G'Day all,
      > >
      > > It seems I am a bit wrong on the info on radio time signals below.
      > > There are six standard drivers in the NTP software to take a time feed
      > > via radio transmissions - mostly various implementations of WWV and
      > > different radios. You can read what you need to do to use them here
      > > <http://www.eecis.udel.edu/%7Emills/ntp/html/refclock.html#list
      > <http://www.eecis.udel.edu/%7Emills/ntp/html/refclock.html#list>
      > > <http://www.eecis.udel.edu/%7Emills/ntp/html/refclock.html#list
      > <http://www.eecis.udel.edu/%7Emills/ntp/html/refclock.html#list>>>. They
      > > would not be much use to me here in the Southern Hemisphere, because the
      > > signal is subject to fade and too much propagation delay. But, if you
      > > are relatively close to a transmitter, they could be worth a go.
      > >
      > > Most likely, a GPS with PPS output would be much cheaper to implement,
      > > and more reliable, than the appropriate radios and antennas in addition
      > > to those for Faros.
      > >
      > > Peter VK4IU
      > >
    Your message has been successfully submitted and would be delivered to recipients shortly.