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

[dxatlas] Re: Timing Question

Expand Messages
  • vk4iu
    ... one other thing. Dave, I think you have your time scales for things at the wrong order of magnitude. We need time to millisecond accuracy. Keep in mind
    Message 1 of 29 , Nov 18, 2009
    • 0 Attachment
      ... one other thing.

      Dave, I think you have your time scales for things at the wrong order of magnitude. We need time to millisecond accuracy.

      Keep in mind that we have already noted that a "consumer" GPS - which in reality is what you are asking for - a timing module with a PIC microprocessor - cannot do the job using a serial interface.

      A little PIC timer we built from parts would never be able to keep time to anything like the accuracy we need. Let alone the problem of interfacing it back into the PC to "control things" as the performance levels we need to achieve millisecond accuracy.

      What you have described is fundamentally what we need to do, but the accuracy we need cannot be achieved with your suggestion.

      Peter VK4IU


      --- In dxatlas_group@yahoogroups.com, "Dave" <dave@...> wrote:
      >
      > Hi Peter and Dave Baxter-
      >
      > The comments are wonderfully clear and pertinent. I think we have
      > circumscribed the issue while a single solution doesn't present itself
      > clearly.
      >
      > I would like to suggest a solution and see if it can be a starting point for
      > discussion:
      >
      > 1. A GPS unit
      > 2. A PIC-based timing module with intelligence to establish predictable
      > time pulses (we don't need minutes or seconds, just a pulse, from a single
      > reference time point).
      > 3. An interface
      > 4. Software to provide Faros a pulse train.
      >
      > That is, once a timing mark, composed of a minute and second sourced from
      > the GPS, is established for Faros, then thereafter all that's needed is a
      > pulse. The PC timing pulse wouldn't matter. A really inexpensive PIC timer
      > isn't expensive, is it?
      >
      > Is this an additional burden on Alex? I don't know. But if the hook where
      > timing is identified and that point is opened, this solution would work. We
      > wouldn't have to worry about PC time at all.
      >
      > What say ye all?
      >
      >
      > Dave
      > DM78qg // KA0SWT
      > /++++++++++++++++++++++++++++++++/
      >
      >
      >
      >
      >
      > -----Original Message-----
      > From: dxatlas_group@yahoogroups.com [mailto:dxatlas_group@yahoogroups.com]
      > On Behalf Of vk4iu
      > Sent: Wednesday, November 18, 2009 16:48
      > To: dxatlas_group@yahoogroups.com
      > Subject: [dxatlas] Re: Timing Question
      >
      > Morning Dave,
      >
      > ... it is 5am here. I'm enjoying the sun rise after 48 hours of storms and
      > hot weather.
      >
      > It looks like our journeys with Faros have a very similar feel to them.
      > But, I am a bit puzzled. While our Internet connections have similar figures
      > for "latency", you are not getting a good result, whereas, here, I have got
      > Faros giving acceptable results.
      >
      > All this discussion that Alex should put more "stuff" into Faros to solve
      > our problems, is missing the point about getting accurate time. The task of
      > Faros is to listen to the sound stream, analyse it, and make a report. Alex
      > has implemented a good solution for time, we just have to deliver to his
      > algorithm time data that is good enough, and his Kalman filter will sort out
      > the variations.
      >
      > Time on the Internet has always been a difficult thing - witness the size of
      > the information on ntp at the SatSignal site. Variability is the order of
      > the day, and the ntpd implementation does a fantastic job of delivery of
      > time under difficult circumstances. The "radio based time services" only
      > exist in the USA and Europe. There are none here - only GPS, which is
      > universal. The world wide radio based time services are just not suitable
      > for what we want to do. The Internet, or GPS, are the only real
      > alternatives for amateur radio. There will never be an RF feed of any sort
      > into an NTP server - its fundamentally not a useful technique - they used an
      > atomic clock to time the broadcast - at the other end it has to be too
      > grossly degraded for use by ntpd - and, with the Internet so wide spread few
      > will be bothered to attempt it.
      >
      > Ones own "time reference" is clearly the solution - if the Internet fails to
      > deliver with sufficient accuracy. The most appropriate is GPS. For around
      > $600 US http://www.beaglesoft.com/stsyhome.htm will provide a complete
      > solution - just as Dave has attempted, and I want to implement, right out of
      > the box. Its down side, apart from the price, is the use of a Windows PC.
      > But, I would not be surprised to find one could get a good enough result
      > with it and Faros on the ONE PC.
      >
      > I find the $600 US too expensive, when I can buy the same GPS 18x LVS for
      > about $90 US, and implement my own system using ntpd. I am lucky that I
      > have 30 years experience in IT Technical Support from old mainframes to
      > multiple PC servers and large PC networks. But, Dave's experience with the
      > Garmin 16 LVS has given me plenty of reason to tread carefully. My first
      > look at the sites referenced in my previous messages got me very excited.
      > The devil may be in the serial port of the PC.
      >
      > Dave is correct, in that most of us simply want to know that we can hear the
      > beacons. I want to do a lot more than that. Let me state the problem we
      > are trying to solve as I see it.
      >
      > We want Faros to record observations of beacons, with sufficient accuracy
      > that we: 1) don't miss any observations, and 2) can easily tell short path
      > from long path. Faros time needs continuous time data randomly distributed
      > within about 60ms of the correct time.
      >
      > Using the data we can then: Analyse band openings over time to improve our
      > DX - find/create matching holes in our busy schedules to work DX; Use
      > different antennas and work out the actual radiation patterns - help us tune
      > the antenna; Compare antennas; Study RF propagation; Plan contest operation
      > to maximise our score; Listen in real time during a contest for band
      > openings; Compare QTHs; and lots more I have not thought of yet.
      >
      > Note that I said "we" can tell short path from long path. Let me describe
      > what I do with Faros to help sort out signals, and compensate for minor time
      > variation.
      >
      > I have an ICOM IC-706IIG, and a muli-band vertical antenna, disconnect the
      > antenna when storms are about, but otherwise the system runs continuously.
      > Faros creates a GIF image to a schedule. I personally make little use of
      > them. The Details Panel, and the History panel, are created from, and can
      > be re-created from the beacon logs. So I simply let Faros do its thing day
      > after day. I use a "scheduled task" at 00:01 UTC in Windows, and a free
      > Windows SDK tool, called ROBOCOPY to copy the logs from the Faros directory
      > to a "holding directory" which is "shared" to my network - I carefully avoid
      > the "current" beacon log created at 00:00. When time permits, on anther PC,
      > I start TWO copies of Faros, click on pause, arrange the windows side by
      > side, and on each Details panel, load a beacon log from the month/day I want
      > to analyse/compare from the "holding directory". The "delay correction" on
      > the second PC could be anything - I adjust it to put the signals where I
      > want them - the SP line probably, then make the analysis. If I need to, I
      > save a GIF image of the period for reference in my notes - mainly I use
      > GreenShot or Snagit or MS OneNote to take snapshots of the screen.
      >
      > Clearly if time is all over the place, this technique becomes less useful.
      > But, even with a high, and variable, latency Internet connection I have
      > found acceptable results - that is signals that follow the SP line 90% of
      > the time intra-day, with only small variation over days, small enough that I
      > can compensate with the technique described. The results are good enough
      > one can see the Ionosphere's "path time" changing for some beacons. I would
      > provide images, but the "black hats" on the Internet have caused that to be
      > off limits.
      >
      > As you seem to have discovered with the Garmin 16lvs, the devil is in the
      > detail, in getting any system of anything to work correctly. I am headed in
      > the same direction, I am sure I will need a lot of luck.
      >
      > How can I help you find a "configuration of time servers" that will give you
      > better results. Over time I may be able to help with the Garmin 16 LVS and
      > the Linux software. My Garmin 18x LVS is on back order - I expect delivery
      > in a few weeks, and will implement it over the coming months. These days, I
      > am a "house husband" and I have a new found appreciation for the effort of
      > house wives and mothers and carers. Time to make the troops breakfast!
      >
      > Peter VK4IU
      >
      > Dave Baxter wrote:
      > >
      > >
      > > Hi Peter (David)
      > >
      > > Just got back from a frustrating on site service visit.
      > >
      > > Yes, I know the Satsignal site, and have had a good exchange with the
      > > David Taylor there and have successfully got a FreeBSD machine
      > > suposedly configured to work as needed, from the same distro and
      > > version as he used, but I've yet to get it to successfully see and
      > > work with a Garmin GPS16LVC, that has a PPS output (yes, I buffered it
      > > to RS232 levels.) The problem I have with all that, is I know next to
      > > nothing about that level of tweakage at the kernel level of any 'nix,
      > > that and the 'nix community seems intent on flaming anyone who asks
      > > questions that they do not see as relavant to their latest and
      > > greatest distro. (or more relevantly, they do not themselves
      > > understand.)
      > >
      > > You also it seems found out the hard way what I was told, that the
      > > timing accuracy of the NMEA sentence delivery from any GPS receiver
      > > currently available, is not good enough for time keeping to the level
      > > we need. The eTrex (I have one of the "Yellow" ones too) is otherwise
      > > a good bit of kit, but useless for any accurate timekeeping.
      > >
      > > Also, like you, I've found that protocols like NTP don't play well
      > > with mobile internet services. 3G or otherwise.
      > >
      > > VLF Radio time keeping broadcasts could be another way to go, but
      > > again, the hardware to do the job is prohibitivey expensive, and none
      > > of the PC software I've found so far that can decode signals like MSF,
      > > DCF, WWV etc, provide a true full NTP server function. (Some do SNTP,
      > > that's about the best it gets, and Faros doesnt do SNTP, only NTP it
      > > seems.)
      > >
      > > My ISP issues. Well, (long story short) during the business day, there
      > > seems to be a drastic increase in the network latency getting to
      > > anything, evne in their own domain/network! If that is not bad enough,
      > > it's variable one ping to the next, by a wide margin (10's to 100's of
      > > mS variation, but no packet loss, that is their goal it seems.)
      > > Evenings, early mornings and weekends, Latency is down to typicaly 25mS.
      > > During the day, it can go to as much as 500mS, but routinely stretches
      > > out to 150 to 300mS, depending on the exact time of day, day of week
      > > etc. Some days are better, some worse. Watching the time accuracy plot
      > > in Faros, at certain times of day, you can see what looks like the
      > > effect of someone throwing a switch somewhere. I did some checks, and
      > > it's not just me, other users of the same ISP are experiencing similar
      > > effects, though they don't use NTP as we do. It is however messing
      > > with lots of other systems it seems too.
      > >
      > > As a result, it totaly screws up NTP for any sort of accurate time
      > > synching, like Faros needs. Hence why I was messing with FreeBSD
      > > trying to setup a local Stratum 1 server etc. It's getting to the
      > > state at home now, where I am going to take another serious stab at
      > > it, and see if I can get it going on an old early pentium laptop, as
      > > that is much smaller, quieter, and uses less power, than the current
      > > desktop I have sort of working.
      > >
      > > I'd idealy like to have a "Time Appliance", but commercial units are
      > > way outside my pocket money range, and like hen's teeth to find too.
      > > The people who port 'nix etc onto old router hardware are also
      > > uninterested in helping, from the few exchanges I've had on other
      > > forums, and I don't know enough to do it myself.
      > >
      > > I did find this... http://scss.com.au/family/andrew/gps/ntp/ But...
      > >
      > > When I asked if he would release a copy of the BINARY (not the
      > > propriatry TCP stack 'C' code from the compiler) he's gone all silent
      > > (like no reply, ever!) Pity, as that seems to be what we need. Maybe
      > > someone else could persuade him to if not release the BINARY, then
      > > perhaps sell pre-programed (and copy protected) PIC's for such use?
      > >
      > > For now, Faros bumbles along otherwise OK, but when you look at the
      > > plots, the path charts in the UK afternoon, are often showing a snow
      > > storm of white "unknown" spots. http://g8kbv.homeip.net:8008/
      > >
      > > As a reception report, most people are interested in the fact that a
      > > beacon has been realiably heard, not what path it was heard by, I think.
      > >
      > > What I'd like to see long term, is GPS PPS support built into Faros
      > > itself, that's where it's needed, NTP could still be used if GPS
      > > reception is not posible, or as a fall back. That alone would make
      > > Faros most valuable when out portable, or for DXpeditions etc. But of
      > > course, only Alex can implement that.
      > >
      > > Another option, but would also no doubt be a major undertaking on
      > > Alex's part, would be to use one channel of the soundcard for the
      > > beacons, and one channel for a radio code input (WWV, MSF etc) No GPS
      > > needed, just two RX's, and one of them could be a realy simple SDR like
      > thing.
      > > (Keeping the audio tones very different, so any crosstalk would be
      > > ignored.
      > >
      > > Or, take a pulse train from any of the commonly available miniature
      > > VLF clock receiver modules, into a com port line somewhere, and use
      > > that to set Faros's time.
      > >
      > > That's enough from me I suspect. Oh, one more thing. The Javascript I
      > > use, is more or less that, that is cited as an example to use, if you
      > > look on the main NCDXF IBP site links. http://faros.ve3sun.com/ is
      > > where you need to go to start that learning exersize! I make no claims
      > > for originality on that subject.
      > >
      > > Cheers All.
      > >
      > > Dave Baxter
      > > G0WBX.
      > >
      > > --- Original Message ---
      > >
      > > My current plan.
      > >
      > > I initially dismissed creating a stratum 0 reference time server - the
      > > Meinberg PCI card is priced at $3500 in Australia. But ...
      > >
      > > Alex VE3NEA alerted me to the following web site http://time.qnan.org
      > > I have ordered a Garmin 18x LVS, $100 n Australia, and I will proceed
      > > to integrate it into my Linux server. On that site there is a
      > > reference to http://www.satsignal.eu/ntp/index.html which is a
      > > fantastic source of information relevant to getting Faros a good time
      > > signal. I have high hopes of having a fantastic Faros installation for
      > > propagation study, site and antenna comparisons.
      > >
      > > Peter VK4IU
      > >
      >
      >
      >
      >
      > ------------------------------------
      >
      > Yahoo! Groups Links
      >
      >
      >
      >
      > ----------
      >
      >
      > No virus found in this outgoing message.
      > Checked by AVG - www.avg.com
      > Version: 8.5.425 / Virus Database: 270.14.72/2511 - Release Date: 11/18/09 07:50:00
      >
      >
      > [Non-text portions of this message have been removed]
      >
    • Dave
      Well, I guess I was on the wrong road. Dave DM78qg // KA0SWT /++++++++++++++++++++++++++++++++/ ... From: dxatlas_group@yahoogroups.com
      Message 2 of 29 , Nov 18, 2009
      • 0 Attachment
        Well, I guess I was on the wrong road.

        Dave
        DM78qg // KA0SWT
        /++++++++++++++++++++++++++++++++/





        -----Original Message-----
        From: dxatlas_group@yahoogroups.com [mailto:dxatlas_group@yahoogroups.com]
        On Behalf Of vk4iu
        Sent: Wednesday, November 18, 2009 19:08
        To: dxatlas_group@yahoogroups.com
        Subject: [dxatlas] Re: Timing Question

        ... one other thing.

        Dave, I think you have your time scales for things at the wrong order of
        magnitude. We need time to millisecond accuracy.

        Keep in mind that we have already noted that a "consumer" GPS - which in
        reality is what you are asking for - a timing module with a PIC
        microprocessor - cannot do the job using a serial interface.

        A little PIC timer we built from parts would never be able to keep time to
        anything like the accuracy we need. Let alone the problem of interfacing it
        back into the PC to "control things" as the performance levels we need to
        achieve millisecond accuracy.

        What you have described is fundamentally what we need to do, but the
        accuracy we need cannot be achieved with your suggestion.

        Peter VK4IU


        --- In dxatlas_group@yahoogroups.com, "Dave" <dave@...> wrote:
        >
        > Hi Peter and Dave Baxter-
        >
        > The comments are wonderfully clear and pertinent. I think we have
        > circumscribed the issue while a single solution doesn't present itself
        > clearly.
        >
        > I would like to suggest a solution and see if it can be a starting
        > point for
        > discussion:
        >
        > 1. A GPS unit
        > 2. A PIC-based timing module with intelligence to establish
        > predictable time pulses (we don't need minutes or seconds, just a
        > pulse, from a single reference time point).
        > 3. An interface
        > 4. Software to provide Faros a pulse train.
        >
        > That is, once a timing mark, composed of a minute and second sourced
        > from the GPS, is established for Faros, then thereafter all that's
        > needed is a pulse. The PC timing pulse wouldn't matter. A really
        > inexpensive PIC timer isn't expensive, is it?
        >
        > Is this an additional burden on Alex? I don't know. But if the hook
        > where timing is identified and that point is opened, this solution
        > would work. We wouldn't have to worry about PC time at all.
        >
        > What say ye all?
        >
        >
        > Dave
        > DM78qg // KA0SWT
        > /++++++++++++++++++++++++++++++++/
        >
        >
        >
        >
        >
        > -----Original Message-----
        > From: dxatlas_group@yahoogroups.com
        > [mailto:dxatlas_group@yahoogroups.com]
        > On Behalf Of vk4iu
        > Sent: Wednesday, November 18, 2009 16:48
        > To: dxatlas_group@yahoogroups.com
        > Subject: [dxatlas] Re: Timing Question
        >
        > Morning Dave,
        >
        > ... it is 5am here. I'm enjoying the sun rise after 48 hours of
        > storms and hot weather.
        >
        > It looks like our journeys with Faros have a very similar feel to them.
        > But, I am a bit puzzled. While our Internet connections have similar
        > figures for "latency", you are not getting a good result, whereas,
        > here, I have got Faros giving acceptable results.
        >
        > All this discussion that Alex should put more "stuff" into Faros to
        > solve our problems, is missing the point about getting accurate time.
        > The task of Faros is to listen to the sound stream, analyse it, and
        > make a report. Alex has implemented a good solution for time, we just
        > have to deliver to his algorithm time data that is good enough, and
        > his Kalman filter will sort out the variations.
        >
        > Time on the Internet has always been a difficult thing - witness the
        > size of the information on ntp at the SatSignal site. Variability is
        > the order of the day, and the ntpd implementation does a fantastic job
        > of delivery of time under difficult circumstances. The "radio based
        > time services" only exist in the USA and Europe. There are none here
        > - only GPS, which is universal. The world wide radio based time
        > services are just not suitable for what we want to do. The Internet, or
        GPS, are the only real
        > alternatives for amateur radio. There will never be an RF feed of any
        sort
        > into an NTP server - its fundamentally not a useful technique - they
        > used an atomic clock to time the broadcast - at the other end it has
        > to be too grossly degraded for use by ntpd - and, with the Internet so
        > wide spread few will be bothered to attempt it.
        >
        > Ones own "time reference" is clearly the solution - if the Internet
        > fails to deliver with sufficient accuracy. The most appropriate is
        > GPS. For around $600 US http://www.beaglesoft.com/stsyhome.htm will
        > provide a complete solution - just as Dave has attempted, and I want
        > to implement, right out of the box. Its down side, apart from the price,
        is the use of a Windows PC.
        > But, I would not be surprised to find one could get a good enough
        > result with it and Faros on the ONE PC.
        >
        > I find the $600 US too expensive, when I can buy the same GPS 18x LVS
        > for about $90 US, and implement my own system using ntpd. I am lucky
        > that I have 30 years experience in IT Technical Support from old
        > mainframes to multiple PC servers and large PC networks. But, Dave's
        > experience with the Garmin 16 LVS has given me plenty of reason to
        > tread carefully. My first look at the sites referenced in my previous
        messages got me very excited.
        > The devil may be in the serial port of the PC.
        >
        > Dave is correct, in that most of us simply want to know that we can
        > hear the beacons. I want to do a lot more than that. Let me state
        > the problem we are trying to solve as I see it.
        >
        > We want Faros to record observations of beacons, with sufficient
        > accuracy that we: 1) don't miss any observations, and 2) can easily
        > tell short path from long path. Faros time needs continuous time data
        > randomly distributed within about 60ms of the correct time.
        >
        > Using the data we can then: Analyse band openings over time to
        > improve our DX - find/create matching holes in our busy schedules to
        > work DX; Use different antennas and work out the actual radiation
        > patterns - help us tune the antenna; Compare antennas; Study RF
        > propagation; Plan contest operation to maximise our score; Listen in
        > real time during a contest for band openings; Compare QTHs; and lots more
        I have not thought of yet.
        >
        > Note that I said "we" can tell short path from long path. Let me
        > describe what I do with Faros to help sort out signals, and compensate
        > for minor time variation.
        >
        > I have an ICOM IC-706IIG, and a muli-band vertical antenna, disconnect
        > the antenna when storms are about, but otherwise the system runs
        continuously.
        > Faros creates a GIF image to a schedule. I personally make little use
        > of them. The Details Panel, and the History panel, are created from,
        > and can be re-created from the beacon logs. So I simply let Faros do
        > its thing day after day. I use a "scheduled task" at 00:01 UTC in
        > Windows, and a free Windows SDK tool, called ROBOCOPY to copy the logs
        > from the Faros directory to a "holding directory" which is "shared" to
        > my network - I carefully avoid the "current" beacon log created at
        > 00:00. When time permits, on anther PC, I start TWO copies of Faros,
        > click on pause, arrange the windows side by side, and on each Details
        panel, load a beacon log from the month/day I want
        > to analyse/compare from the "holding directory". The "delay correction"
        on
        > the second PC could be anything - I adjust it to put the signals where
        > I want them - the SP line probably, then make the analysis. If I need
        > to, I save a GIF image of the period for reference in my notes -
        > mainly I use GreenShot or Snagit or MS OneNote to take snapshots of the
        screen.
        >
        > Clearly if time is all over the place, this technique becomes less useful.
        > But, even with a high, and variable, latency Internet connection I
        > have found acceptable results - that is signals that follow the SP
        > line 90% of the time intra-day, with only small variation over days,
        > small enough that I can compensate with the technique described. The
        > results are good enough one can see the Ionosphere's "path time"
        > changing for some beacons. I would provide images, but the "black
        > hats" on the Internet have caused that to be off limits.
        >
        > As you seem to have discovered with the Garmin 16lvs, the devil is in
        > the detail, in getting any system of anything to work correctly. I am
        > headed in the same direction, I am sure I will need a lot of luck.
        >
        > How can I help you find a "configuration of time servers" that will
        > give you better results. Over time I may be able to help with the
        > Garmin 16 LVS and the Linux software. My Garmin 18x LVS is on back
        > order - I expect delivery in a few weeks, and will implement it over
        > the coming months. These days, I am a "house husband" and I have a
        > new found appreciation for the effort of house wives and mothers and
        carers. Time to make the troops breakfast!
        >
        > Peter VK4IU
        >
        > Dave Baxter wrote:
        > >
        > >
        > > Hi Peter (David)
        > >
        > > Just got back from a frustrating on site service visit.
        > >
        > > Yes, I know the Satsignal site, and have had a good exchange with
        > > the David Taylor there and have successfully got a FreeBSD machine
        > > suposedly configured to work as needed, from the same distro and
        > > version as he used, but I've yet to get it to successfully see and
        > > work with a Garmin GPS16LVC, that has a PPS output (yes, I buffered
        > > it to RS232 levels.) The problem I have with all that, is I know
        > > next to nothing about that level of tweakage at the kernel level of
        > > any 'nix, that and the 'nix community seems intent on flaming anyone
        > > who asks questions that they do not see as relavant to their latest
        > > and greatest distro. (or more relevantly, they do not themselves
        > > understand.)
        > >
        > > You also it seems found out the hard way what I was told, that the
        > > timing accuracy of the NMEA sentence delivery from any GPS receiver
        > > currently available, is not good enough for time keeping to the
        > > level we need. The eTrex (I have one of the "Yellow" ones too) is
        > > otherwise a good bit of kit, but useless for any accurate timekeeping.
        > >
        > > Also, like you, I've found that protocols like NTP don't play well
        > > with mobile internet services. 3G or otherwise.
        > >
        > > VLF Radio time keeping broadcasts could be another way to go, but
        > > again, the hardware to do the job is prohibitivey expensive, and
        > > none of the PC software I've found so far that can decode signals
        > > like MSF, DCF, WWV etc, provide a true full NTP server function.
        > > (Some do SNTP, that's about the best it gets, and Faros doesnt do
        > > SNTP, only NTP it
        > > seems.)
        > >
        > > My ISP issues. Well, (long story short) during the business day,
        > > there seems to be a drastic increase in the network latency getting
        > > to anything, evne in their own domain/network! If that is not bad
        > > enough, it's variable one ping to the next, by a wide margin (10's
        > > to 100's of mS variation, but no packet loss, that is their goal it
        > > seems.) Evenings, early mornings and weekends, Latency is down to
        typicaly 25mS.
        > > During the day, it can go to as much as 500mS, but routinely
        > > stretches out to 150 to 300mS, depending on the exact time of day,
        > > day of week etc. Some days are better, some worse. Watching the time
        > > accuracy plot in Faros, at certain times of day, you can see what
        > > looks like the effect of someone throwing a switch somewhere. I did
        > > some checks, and it's not just me, other users of the same ISP are
        > > experiencing similar effects, though they don't use NTP as we do. It
        > > is however messing with lots of other systems it seems too.
        > >
        > > As a result, it totaly screws up NTP for any sort of accurate time
        > > synching, like Faros needs. Hence why I was messing with FreeBSD
        > > trying to setup a local Stratum 1 server etc. It's getting to the
        > > state at home now, where I am going to take another serious stab at
        > > it, and see if I can get it going on an old early pentium laptop, as
        > > that is much smaller, quieter, and uses less power, than the current
        > > desktop I have sort of working.
        > >
        > > I'd idealy like to have a "Time Appliance", but commercial units are
        > > way outside my pocket money range, and like hen's teeth to find too.
        > > The people who port 'nix etc onto old router hardware are also
        > > uninterested in helping, from the few exchanges I've had on other
        > > forums, and I don't know enough to do it myself.
        > >
        > > I did find this... http://scss.com.au/family/andrew/gps/ntp/ But...
        > >
        > > When I asked if he would release a copy of the BINARY (not the
        > > propriatry TCP stack 'C' code from the compiler) he's gone all
        > > silent (like no reply, ever!) Pity, as that seems to be what we
        > > need. Maybe someone else could persuade him to if not release the
        > > BINARY, then perhaps sell pre-programed (and copy protected) PIC's for
        such use?
        > >
        > > For now, Faros bumbles along otherwise OK, but when you look at the
        > > plots, the path charts in the UK afternoon, are often showing a snow
        > > storm of white "unknown" spots. http://g8kbv.homeip.net:8008/
        > >
        > > As a reception report, most people are interested in the fact that a
        > > beacon has been realiably heard, not what path it was heard by, I think.
        > >
        > > What I'd like to see long term, is GPS PPS support built into Faros
        > > itself, that's where it's needed, NTP could still be used if GPS
        > > reception is not posible, or as a fall back. That alone would make
        > > Faros most valuable when out portable, or for DXpeditions etc. But
        > > of course, only Alex can implement that.
        > >
        > > Another option, but would also no doubt be a major undertaking on
        > > Alex's part, would be to use one channel of the soundcard for the
        > > beacons, and one channel for a radio code input (WWV, MSF etc) No
        > > GPS needed, just two RX's, and one of them could be a realy simple
        > > SDR like
        > thing.
        > > (Keeping the audio tones very different, so any crosstalk would be
        > > ignored.
        > >
        > > Or, take a pulse train from any of the commonly available miniature
        > > VLF clock receiver modules, into a com port line somewhere, and use
        > > that to set Faros's time.
        > >
        > > That's enough from me I suspect. Oh, one more thing. The Javascript
        > > I use, is more or less that, that is cited as an example to use, if
        > > you look on the main NCDXF IBP site links. http://faros.ve3sun.com/
        > > is where you need to go to start that learning exersize! I make no
        > > claims for originality on that subject.
        > >
        > > Cheers All.
        > >
        > > Dave Baxter
        > > G0WBX.
        > >
        > > --- Original Message ---
        > >
        > > My current plan.
        > >
        > > I initially dismissed creating a stratum 0 reference time server -
        > > the Meinberg PCI card is priced at $3500 in Australia. But ...
        > >
        > > Alex VE3NEA alerted me to the following web site http://time.qnan.org
        > > I have ordered a Garmin 18x LVS, $100 n Australia, and I will
        > > proceed to integrate it into my Linux server. On that site there is
        > > a reference to http://www.satsignal.eu/ntp/index.html which is a
        > > fantastic source of information relevant to getting Faros a good
        > > time signal. I have high hopes of having a fantastic Faros
        > > installation for propagation study, site and antenna comparisons.
        > >
        > > Peter VK4IU
        > >
        >
        >
        >
        >
        > ------------------------------------
        >
        > Yahoo! Groups Links
        >
        >
        >
        >
        > ----------
        >
        >
        > No virus found in this outgoing message.
        > Checked by AVG - www.avg.com
        > Version: 8.5.425 / Virus Database: 270.14.72/2511 - Release Date:
        > 11/18/09 07:50:00
        >
        >
        > [Non-text portions of this message have been removed]
        >




        ------------------------------------

        Yahoo! Groups Links




        ----------


        No virus found in this outgoing message.
        Checked by AVG - www.avg.com
        Version: 8.5.425 / Virus Database: 270.14.72/2511 - Release Date: 11/18/09 07:50:00


        [Non-text portions of this message have been removed]
      • Peter
        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
        Message 3 of 29 , Nov 19, 2009
        • 0 Attachment
          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>. 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

          vk4iu wrote:
          >
          >
          > Morning Dave,
          >
          > ... it is 5am here. I'm enjoying the sun rise after 48 hours of storms
          > and hot weather.
          >
          > It looks like our journeys with Faros have a very similar feel to
          > them. But, I am a bit puzzled. While our Internet connections have
          > similar figures for "latency", you are not getting a good result,
          > whereas, here, I have got Faros giving acceptable results.
          >
          > All this discussion that Alex should put more "stuff" into Faros to
          > solve our problems, is missing the point about getting accurate time.
          > The task of Faros is to listen to the sound stream, analyse it, and
          > make a report. Alex has implemented a good solution for time, we just
          > have to deliver to his algorithm time data that is good enough, and
          > his Kalman filter will sort out the variations.
          >
          > Time on the Internet has always been a difficult thing - witness the
          > size of the information on ntp at the SatSignal site. Variability is
          > the order of the day, and the ntpd implementation does a fantastic job
          > of delivery of time under difficult circumstances. The "radio based
          > time services" only exist in the USA and Europe. There are none here -
          > only GPS, which is universal. The world wide radio based time services
          > are just not suitable for what we want to do. The Internet, or GPS,
          > are the only real alternatives for amateur radio. There will never be
          > an RF feed of any sort into an NTP server - its fundamentally not a
          > useful technique - they used an atomic clock to time the broadcast -
          > at the other end it has to be too grossly degraded for use by ntpd -
          > and, with the Internet so wide spread few will be bothered to attempt it.
          >
          > Ones own "time reference" is clearly the solution - if the Internet
          > fails to deliver with sufficient accuracy. The most appropriate is
          > GPS. For around $600 US http://www.beaglesoft.com/stsyhome.htm
          > <http://www.beaglesoft.com/stsyhome.htm> will provide a complete
          > solution - just as Dave has attempted, and I want to implement, right
          > out of the box. Its down side, apart from the price, is the use of a
          > Windows PC. But, I would not be surprised to find one could get a good
          > enough result with it and Faros on the ONE PC.
          >
          > I find the $600 US too expensive, when I can buy the same GPS 18x LVS
          > for about $90 US, and implement my own system using ntpd. I am lucky
          > that I have 30 years experience in IT Technical Support from old
          > mainframes to multiple PC servers and large PC networks. But, Dave's
          > experience with the Garmin 16 LVS has given me plenty of reason to
          > tread carefully. My first look at the sites referenced in my previous
          > messages got me very excited. The devil may be in the serial port of
          > the PC.
          >
          > Dave is correct, in that most of us simply want to know that we can
          > hear the beacons. I want to do a lot more than that. Let me state the
          > problem we are trying to solve as I see it.
          >
          > We want Faros to record observations of beacons, with sufficient
          > accuracy that we: 1) don't miss any observations, and 2) can easily
          > tell short path from long path. Faros time needs continuous time data
          > randomly distributed within about 60ms of the correct time.
          >
          > Using the data we can then: Analyse band openings over time to improve
          > our DX - find/create matching holes in our busy schedules to work DX;
          > Use different antennas and work out the actual radiation patterns -
          > help us tune the antenna; Compare antennas; Study RF propagation; Plan
          > contest operation to maximise our score; Listen in real time during a
          > contest for band openings; Compare QTHs; and lots more I have not
          > thought of yet.
          >
          > Note that I said "we" can tell short path from long path. Let me
          > describe what I do with Faros to help sort out signals, and compensate
          > for minor time variation.
          >
          > I have an ICOM IC-706IIG, and a muli-band vertical antenna, disconnect
          > the antenna when storms are about, but otherwise the system runs
          > continuously. Faros creates a GIF image to a schedule. I personally
          > make little use of them. The Details Panel, and the History panel, are
          > created from, and can be re-created from the beacon logs. So I simply
          > let Faros do its thing day after day. I use a "scheduled task" at
          > 00:01 UTC in Windows, and a free Windows SDK tool, called ROBOCOPY to
          > copy the logs from the Faros directory to a "holding directory" which
          > is "shared" to my network - I carefully avoid the "current" beacon log
          > created at 00:00. When time permits, on anther PC, I start TWO copies
          > of Faros, click on pause, arrange the windows side by side, and on
          > each Details panel, load a beacon log from the month/day I want to
          > analyse/compare from the "holding directory". The "delay correction"
          > on the second PC could be anything - I adjust it to put the signals
          > where I want them - the SP line probably, then make the analysis. If I
          > need to, I save a GIF image of the period for reference in my notes -
          > mainly I use GreenShot or Snagit or MS OneNote to take snapshots of
          > the screen.
          >
          > Clearly if time is all over the place, this technique becomes less
          > useful. But, even with a high, and variable, latency Internet
          > connection I have found acceptable results - that is signals that
          > follow the SP line 90% of the time intra-day, with only small
          > variation over days, small enough that I can compensate with the
          > technique described. The results are good enough one can see the
          > Ionosphere's "path time" changing for some beacons. I would provide
          > images, but the "black hats" on the Internet have caused that to be
          > off limits.
          >
          > As you seem to have discovered with the Garmin 16lvs, the devil is in
          > the detail, in getting any system of anything to work correctly. I am
          > headed in the same direction, I am sure I will need a lot of luck.
          >
          > How can I help you find a "configuration of time servers" that will
          > give you better results. Over time I may be able to help with the
          > Garmin 16 LVS and the Linux software. My Garmin 18x LVS is on back
          > order - I expect delivery in a few weeks, and will implement it over
          > the coming months. These days, I am a "house husband" and I have a new
          > found appreciation for the effort of house wives and mothers and
          > carers. Time to make the troops breakfast!
          >
          > Peter VK4IU
          >
          > Dave Baxter wrote:
          > >
          > >
          > > Hi Peter (David)
          > >
          > > Just got back from a frustrating on site service visit.
          > >
          > > Yes, I know the Satsignal site, and have had a good exchange with the
          > > David Taylor there and have successfully got a FreeBSD machine suposedly
          > > configured to work as needed, from the same distro and version as he
          > > used, but I've yet to get it to successfully see and work with a Garmin
          > > GPS16LVC, that has a PPS output (yes, I buffered it to RS232 levels.)
          > > The problem I have with all that, is I know next to nothing about that
          > > level of tweakage at the kernel level of any 'nix, that and the 'nix
          > > community seems intent on flaming anyone who asks questions that they do
          > > not see as relavant to their latest and greatest distro. (or more
          > > relevantly, they do not themselves understand.)
          > >
          > > You also it seems found out the hard way what I was told, that the
          > > timing accuracy of the NMEA sentence delivery from any GPS receiver
          > > currently available, is not good enough for time keeping to the level we
          > > need. The eTrex (I have one of the "Yellow" ones too) is otherwise a
          > > good bit of kit, but useless for any accurate timekeeping.
          > >
          > > Also, like you, I've found that protocols like NTP don't play well with
          > > mobile internet services. 3G or otherwise.
          > >
          > > VLF Radio time keeping broadcasts could be another way to go, but again,
          > > the hardware to do the job is prohibitivey expensive, and none of the PC
          > > software I've found so far that can decode signals like MSF, DCF, WWV
          > > etc, provide a true full NTP server function. (Some do SNTP, that's
          > > about the best it gets, and Faros doesnt do SNTP, only NTP it seems.)
          > >
          > > My ISP issues. Well, (long story short) during the business day, there
          > > seems to be a drastic increase in the network latency getting to
          > > anything, evne in their own domain/network! If that is not bad enough,
          > > it's variable one ping to the next, by a wide margin (10's to 100's of
          > > mS variation, but no packet loss, that is their goal it seems.)
          > > Evenings, early mornings and weekends, Latency is down to typicaly 25mS.
          > > During the day, it can go to as much as 500mS, but routinely stretches
          > > out to 150 to 300mS, depending on the exact time of day, day of week
          > > etc. Some days are better, some worse. Watching the time accuracy
          > > plot in Faros, at certain times of day, you can see what looks like the
          > > effect of someone throwing a switch somewhere. I did some checks, and
          > > it's not just me, other users of the same ISP are experiencing similar
          > > effects, though they don't use NTP as we do. It is however messing with
          > > lots of other systems it seems too.
          > >
          > > As a result, it totaly screws up NTP for any sort of accurate time
          > > synching, like Faros needs. Hence why I was messing with FreeBSD
          > > trying to setup a local Stratum 1 server etc. It's getting to the
          > > state at home now, where I am going to take another serious stab at it,
          > > and see if I can get it going on an old early pentium laptop, as that is
          > > much smaller, quieter, and uses less power, than the current desktop I
          > > have sort of working.
          > >
          > > I'd idealy like to have a "Time Appliance", but commercial units are way
          > > outside my pocket money range, and like hen's teeth to find too. The
          > > people who port 'nix etc onto old router hardware are also uninterested
          > > in helping, from the few exchanges I've had on other forums, and I don't
          > > know enough to do it myself.
          > >
          > > I did find this... http://scss.com.au/family/andrew/gps/ntp/
          > <http://scss.com.au/family/andrew/gps/ntp/> But...
          > >
          > > When I asked if he would release a copy of the BINARY (not the
          > > propriatry TCP stack 'C' code from the compiler) he's gone all silent
          > > (like no reply, ever!) Pity, as that seems to be what we need. Maybe
          > > someone else could persuade him to if not release the BINARY, then
          > > perhaps sell pre-programed (and copy protected) PIC's for such use?
          > >
          > > For now, Faros bumbles along otherwise OK, but when you look at the
          > > plots, the path charts in the UK afternoon, are often showing a snow
          > > storm of white "unknown" spots. http://g8kbv.homeip.net:8008/
          > <http://g8kbv.homeip.net:8008/>
          > >
          > > As a reception report, most people are interested in the fact that a
          > > beacon has been realiably heard, not what path it was heard by, I think.
          > >
          > > What I'd like to see long term, is GPS PPS support built into Faros
          > > itself, that's where it's needed, NTP could still be used if GPS
          > > reception is not posible, or as a fall back. That alone would make
          > > Faros most valuable when out portable, or for DXpeditions etc. But of
          > > course, only Alex can implement that.
          > >
          > > Another option, but would also no doubt be a major undertaking on Alex's
          > > part, would be to use one channel of the soundcard for the beacons, and
          > > one channel for a radio code input (WWV, MSF etc) No GPS needed, just
          > > two RX's, and one of them could be a realy simple SDR like thing.
          > > (Keeping the audio tones very different, so any crosstalk would be
          > > ignored.
          > >
          > > Or, take a pulse train from any of the commonly available miniature VLF
          > > clock receiver modules, into a com port line somewhere, and use that to
          > > set Faros's time.
          > >
          > > That's enough from me I suspect. Oh, one more thing. The Javascript I
          > > use, is more or less that, that is cited as an example to use, if you
          > > look on the main NCDXF IBP site links. http://faros.ve3sun.com/
          > <http://faros.ve3sun.com/> is
          > > where you need to go to start that learning exersize! I make no claims
          > > for originality on that subject.
          > >
          > > Cheers All.
          > >
          > > Dave Baxter
          > > G0WBX.
          > >
          > > --- Original Message ---
          > >
          > > My current plan.
          > >
          > > I initially dismissed creating a stratum 0 reference time server - the
          > > Meinberg PCI card is priced at $3500 in Australia. But ...
          > >
          > > Alex VE3NEA alerted me to the following web site
          > http://time.qnan.org <http://time.qnan.org> I
          > > have ordered a Garmin 18x LVS, $100 n Australia, and I will proceed to
          > > integrate it into my Linux server. On that site there is a reference to
          > > http://www.satsignal.eu/ntp/index.html
          > <http://www.satsignal.eu/ntp/index.html> which is a fantastic source of
          > > information relevant to getting Faros a good time signal. I have high
          > > hopes of having a fantastic Faros installation for propagation study,
          > > site and antenna comparisons.
          > >
          > > Peter VK4IU
          > >
          >
          >


          [Non-text portions of this message have been removed]
        • Philip Gladstone
          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
          Message 4 of 29 , Nov 19, 2009
          • 0 Attachment
            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 0.0.0.0 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
            -198.186.191.229 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>>. 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
            >
          • Dave
            Okay, Peter, great start, let s focus on GPS with PPS signals. What do we need to do to make that work? Will my Earthmate USB do the trick? Earthmate GPS
            Message 5 of 29 , Nov 19, 2009
            • 0 Attachment
              Okay, Peter, great start, let's focus on GPS with PPS signals.

              What do we need to do to make that work? Will my Earthmate USB do the
              trick?

              Earthmate GPS LT-40 Specs:
              » NMEA-compliant 16-channel receiver
              » WAAS-enabled
              » STMicroelectronics new high-sensitivity Teseo chipset featuring DeLorme
              ConstantLocktm technologies for outstanding time-to-first-fix and signal
              retention
              » Cold start: < 39 seconds
              » Warm start: < 34 seconds
              » Hot start: < 3 seconds
              » Supply requirements: 90mA (through USB connector)
              » Maximum Velocity: 1000 knots
              » Advanced high-sensitivity algorithms for superior tracking in urban
              environments
              » Initial acquisition sensitivity down to -149dBm
              » Weak signal tracking down to -159dBm
              » Proprietary Kalman filter for enhanced position accuracy
              » Superior noise rejection for high EMI environments
              » Environmental Characterisitics:
              › Operating temperature range -40 ºC to +85 ºC
              › Storage temperature range -55 ºC to +100 ºC


              I see nothing here for timing pulse outputs except the NMEA-compliant
              reference.

              I also found this:
              http://wildcard.pctel.com/images_product_overview/pdf_docs/5012D_CE.pdf

              And

              http://wildcard.pctel.com/images_announcements/files/PCTEL_Pricelist_100509.
              xls

              I'm sure there's plenty of others, so what direction do we now go?


              Dave
              /++++++++++++++++++++++++++++++++/





              -----Original Message-----
              From: dxatlas_group@yahoogroups.com [mailto:dxatlas_group@yahoogroups.com]
              On Behalf Of Peter
              Sent: Thursday, November 19, 2009 05:09
              To: dxatlas_group@yahoogroups.com
              Subject: Re: [dxatlas] Re: Timing Question

              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>. 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

              vk4iu wrote:
              >
              >
              > Morning Dave,
              >
              > ... it is 5am here. I'm enjoying the sun rise after 48 hours of storms
              > and hot weather.
              >
              > It looks like our journeys with Faros have a very similar feel to
              > them. But, I am a bit puzzled. While our Internet connections have
              > similar figures for "latency", you are not getting a good result,
              > whereas, here, I have got Faros giving acceptable results.
              >
              > All this discussion that Alex should put more "stuff" into Faros to
              > solve our problems, is missing the point about getting accurate time.
              > The task of Faros is to listen to the sound stream, analyse it, and
              > make a report. Alex has implemented a good solution for time, we just
              > have to deliver to his algorithm time data that is good enough, and
              > his Kalman filter will sort out the variations.
              >
              > Time on the Internet has always been a difficult thing - witness the
              > size of the information on ntp at the SatSignal site. Variability is
              > the order of the day, and the ntpd implementation does a fantastic job
              > of delivery of time under difficult circumstances. The "radio based
              > time services" only exist in the USA and Europe. There are none here -
              > only GPS, which is universal. The world wide radio based time services
              > are just not suitable for what we want to do. The Internet, or GPS,
              > are the only real alternatives for amateur radio. There will never be
              > an RF feed of any sort into an NTP server - its fundamentally not a
              > useful technique - they used an atomic clock to time the broadcast -
              > at the other end it has to be too grossly degraded for use by ntpd -
              > and, with the Internet so wide spread few will be bothered to attempt it.
              >
              > Ones own "time reference" is clearly the solution - if the Internet
              > fails to deliver with sufficient accuracy. The most appropriate is
              > GPS. For around $600 US http://www.beaglesoft.com/stsyhome.htm
              > <http://www.beaglesoft.com/stsyhome.htm> will provide a complete
              > solution - just as Dave has attempted, and I want to implement, right
              > out of the box. Its down side, apart from the price, is the use of a
              > Windows PC. But, I would not be surprised to find one could get a good
              > enough result with it and Faros on the ONE PC.
              >
              > I find the $600 US too expensive, when I can buy the same GPS 18x LVS
              > for about $90 US, and implement my own system using ntpd. I am lucky
              > that I have 30 years experience in IT Technical Support from old
              > mainframes to multiple PC servers and large PC networks. But, Dave's
              > experience with the Garmin 16 LVS has given me plenty of reason to
              > tread carefully. My first look at the sites referenced in my previous
              > messages got me very excited. The devil may be in the serial port of
              > the PC.
              >
              > Dave is correct, in that most of us simply want to know that we can
              > hear the beacons. I want to do a lot more than that. Let me state the
              > problem we are trying to solve as I see it.
              >
              > We want Faros to record observations of beacons, with sufficient
              > accuracy that we: 1) don't miss any observations, and 2) can easily
              > tell short path from long path. Faros time needs continuous time data
              > randomly distributed within about 60ms of the correct time.
              >
              > Using the data we can then: Analyse band openings over time to improve
              > our DX - find/create matching holes in our busy schedules to work DX;
              > Use different antennas and work out the actual radiation patterns -
              > help us tune the antenna; Compare antennas; Study RF propagation; Plan
              > contest operation to maximise our score; Listen in real time during a
              > contest for band openings; Compare QTHs; and lots more I have not
              > thought of yet.
              >
              > Note that I said "we" can tell short path from long path. Let me
              > describe what I do with Faros to help sort out signals, and compensate
              > for minor time variation.
              >
              > I have an ICOM IC-706IIG, and a muli-band vertical antenna, disconnect
              > the antenna when storms are about, but otherwise the system runs
              > continuously. Faros creates a GIF image to a schedule. I personally
              > make little use of them. The Details Panel, and the History panel, are
              > created from, and can be re-created from the beacon logs. So I simply
              > let Faros do its thing day after day. I use a "scheduled task" at
              > 00:01 UTC in Windows, and a free Windows SDK tool, called ROBOCOPY to
              > copy the logs from the Faros directory to a "holding directory" which
              > is "shared" to my network - I carefully avoid the "current" beacon log
              > created at 00:00. When time permits, on anther PC, I start TWO copies
              > of Faros, click on pause, arrange the windows side by side, and on
              > each Details panel, load a beacon log from the month/day I want to
              > analyse/compare from the "holding directory". The "delay correction"
              > on the second PC could be anything - I adjust it to put the signals
              > where I want them - the SP line probably, then make the analysis. If I
              > need to, I save a GIF image of the period for reference in my notes -
              > mainly I use GreenShot or Snagit or MS OneNote to take snapshots of
              > the screen.
              >
              > Clearly if time is all over the place, this technique becomes less
              > useful. But, even with a high, and variable, latency Internet
              > connection I have found acceptable results - that is signals that
              > follow the SP line 90% of the time intra-day, with only small
              > variation over days, small enough that I can compensate with the
              > technique described. The results are good enough one can see the
              > Ionosphere's "path time" changing for some beacons. I would provide
              > images, but the "black hats" on the Internet have caused that to be
              > off limits.
              >
              > As you seem to have discovered with the Garmin 16lvs, the devil is in
              > the detail, in getting any system of anything to work correctly. I am
              > headed in the same direction, I am sure I will need a lot of luck.
              >
              > How can I help you find a "configuration of time servers" that will
              > give you better results. Over time I may be able to help with the
              > Garmin 16 LVS and the Linux software. My Garmin 18x LVS is on back
              > order - I expect delivery in a few weeks, and will implement it over
              > the coming months. These days, I am a "house husband" and I have a new
              > found appreciation for the effort of house wives and mothers and
              > carers. Time to make the troops breakfast!
              >
              > Peter VK4IU
              >
              > Dave Baxter wrote:
              > >
              > >
              > > Hi Peter (David)
              > >
              > > Just got back from a frustrating on site service visit.
              > >
              > > Yes, I know the Satsignal site, and have had a good exchange with
              > > the David Taylor there and have successfully got a FreeBSD machine
              > > suposedly configured to work as needed, from the same distro and
              > > version as he used, but I've yet to get it to successfully see and
              > > work with a Garmin GPS16LVC, that has a PPS output (yes, I buffered
              > > it to RS232 levels.) The problem I have with all that, is I know
              > > next to nothing about that level of tweakage at the kernel level of
              > > any 'nix, that and the 'nix community seems intent on flaming anyone
              > > who asks questions that they do not see as relavant to their latest
              > > and greatest distro. (or more relevantly, they do not themselves
              > > understand.)
              > >
              > > You also it seems found out the hard way what I was told, that the
              > > timing accuracy of the NMEA sentence delivery from any GPS receiver
              > > currently available, is not good enough for time keeping to the
              > > level we need. The eTrex (I have one of the "Yellow" ones too) is
              > > otherwise a good bit of kit, but useless for any accurate timekeeping.
              > >
              > > Also, like you, I've found that protocols like NTP don't play well
              > > with mobile internet services. 3G or otherwise.
              > >
              > > VLF Radio time keeping broadcasts could be another way to go, but
              > > again, the hardware to do the job is prohibitivey expensive, and
              > > none of the PC software I've found so far that can decode signals
              > > like MSF, DCF, WWV etc, provide a true full NTP server function.
              > > (Some do SNTP, that's about the best it gets, and Faros doesnt do
              > > SNTP, only NTP it seems.)
              > >
              > > My ISP issues. Well, (long story short) during the business day,
              > > there seems to be a drastic increase in the network latency getting
              > > to anything, evne in their own domain/network! If that is not bad
              > > enough, it's variable one ping to the next, by a wide margin (10's
              > > to 100's of mS variation, but no packet loss, that is their goal it
              > > seems.) Evenings, early mornings and weekends, Latency is down to
              typicaly 25mS.
              > > During the day, it can go to as much as 500mS, but routinely
              > > stretches out to 150 to 300mS, depending on the exact time of day,
              > > day of week etc. Some days are better, some worse. Watching the time
              > > accuracy plot in Faros, at certain times of day, you can see what
              > > looks like the effect of someone throwing a switch somewhere. I did
              > > some checks, and it's not just me, other users of the same ISP are
              > > experiencing similar effects, though they don't use NTP as we do. It
              > > is however messing with lots of other systems it seems too.
              > >
              > > As a result, it totaly screws up NTP for any sort of accurate time
              > > synching, like Faros needs. Hence why I was messing with FreeBSD
              > > trying to setup a local Stratum 1 server etc. It's getting to the
              > > state at home now, where I am going to take another serious stab at
              > > it, and see if I can get it going on an old early pentium laptop, as
              > > that is much smaller, quieter, and uses less power, than the current
              > > desktop I have sort of working.
              > >
              > > I'd idealy like to have a "Time Appliance", but commercial units are
              > > way outside my pocket money range, and like hen's teeth to find too.
              > > The people who port 'nix etc onto old router hardware are also
              > > uninterested in helping, from the few exchanges I've had on other
              > > forums, and I don't know enough to do it myself.
              > >
              > > I did find this... http://scss.com.au/family/andrew/gps/ntp/
              > <http://scss.com.au/family/andrew/gps/ntp/> But...
              > >
              > > When I asked if he would release a copy of the BINARY (not the
              > > propriatry TCP stack 'C' code from the compiler) he's gone all
              > > silent (like no reply, ever!) Pity, as that seems to be what we
              > > need. Maybe someone else could persuade him to if not release the
              > > BINARY, then perhaps sell pre-programed (and copy protected) PIC's for
              such use?
              > >
              > > For now, Faros bumbles along otherwise OK, but when you look at the
              > > plots, the path charts in the UK afternoon, are often showing a snow
              > > storm of white "unknown" spots. http://g8kbv.homeip.net:8008/
              > <http://g8kbv.homeip.net:8008/>
              > >
              > > As a reception report, most people are interested in the fact that a
              > > beacon has been realiably heard, not what path it was heard by, I think.
              > >
              > > What I'd like to see long term, is GPS PPS support built into Faros
              > > itself, that's where it's needed, NTP could still be used if GPS
              > > reception is not posible, or as a fall back. That alone would make
              > > Faros most valuable when out portable, or for DXpeditions etc. But
              > > of course, only Alex can implement that.
              > >
              > > Another option, but would also no doubt be a major undertaking on
              > > Alex's part, would be to use one channel of the soundcard for the
              > > beacons, and one channel for a radio code input (WWV, MSF etc) No
              > > GPS needed, just two RX's, and one of them could be a realy simple SDR
              like thing.
              > > (Keeping the audio tones very different, so any crosstalk would be
              > > ignored.
              > >
              > > Or, take a pulse train from any of the commonly available miniature
              > > VLF clock receiver modules, into a com port line somewhere, and use
              > > that to set Faros's time.
              > >
              > > That's enough from me I suspect. Oh, one more thing. The Javascript
              > > I use, is more or less that, that is cited as an example to use, if
              > > you look on the main NCDXF IBP site links. http://faros.ve3sun.com/
              > <http://faros.ve3sun.com/> is
              > > where you need to go to start that learning exersize! I make no
              > > claims for originality on that subject.
              > >
              > > Cheers All.
              > >
              > > Dave Baxter
              > > G0WBX.
              > >
              > > --- Original Message ---
              > >
              > > My current plan.
              > >
              > > I initially dismissed creating a stratum 0 reference time server -
              > > the Meinberg PCI card is priced at $3500 in Australia. But ...
              > >
              > > Alex VE3NEA alerted me to the following web site
              > http://time.qnan.org <http://time.qnan.org> I
              > > have ordered a Garmin 18x LVS, $100 n Australia, and I will proceed
              > > to integrate it into my Linux server. On that site there is a
              > > reference to http://www.satsignal.eu/ntp/index.html
              > <http://www.satsignal.eu/ntp/index.html> which is a fantastic source
              > of
              > > information relevant to getting Faros a good time signal. I have
              > > high hopes of having a fantastic Faros installation for propagation
              > > study, site and antenna comparisons.
              > >
              > > Peter VK4IU
              > >
              >
              >


              [Non-text portions of this message have been removed]



              ------------------------------------

              Yahoo! Groups Links




              ----------


              No virus found in this outgoing message.
              Checked by AVG - www.avg.com
              Version: 8.5.425 / Virus Database: 270.14.72/2511 - Release Date: 11/18/09 07:50:00


              [Non-text portions of this message have been removed]
            • 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 6 of 29 , Nov 19, 2009
              • 0 Attachment
                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 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
                congestion.

                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 128.250.36.2 2 u 79 256 377 58.258 -10.218 4.514
                duffman.springf 210.23.158.201 3 u 98 256 377 98.802 -9.846 33.042
                *cachens1.onqnet 128.250.36.3 2 u 116 256 377 59.203 -12.518 3.518
                +ntp.bigcheese.o 128.250.36.2 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 203.35.83.242 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 0.0.0.0 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
                > -198.186.191.229 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.