[time-nuts] Need Time Help

Graham / KE9H ke9h.graham at gmail.com
Tue Oct 4 09:26:56 EDT 2016


Larry:

You have multiple problems, with the way you are trying to define
"time-error."

I think you are defining it as the time error of the signal coming out of
your receivers/decoders.

You are blending all the error/delay sources together, and you need to
break them apart, since each one will have a different solution, or method
of management

First, the reflector has already jumped in and helped you with the
definition of absolute time.  You can get single digit millisecond accuracy
(with some caviats and bewares) from NTP, for stations at different
locations.  You should be able to get single digit microsecond accuracy (or
better) with an appropriate GPS based timing systems. You can not get these
levels of accuracy out of the native time system on Windows. That is more
like single digit seconds.

Second, you have some serious signal processing latency delays in your
receivers/demodulators/decoders.  Depending on how the designer has dealt
with streaming and buffering, particularly with the (buffered) connections
between the stages, these processing latency delays may be constant or
variable, or perhaps adjustable.  The Windows Sound system is horrible from
a latency/stability standpoint. You are probably feeding your back-end
demodulators/decoders through it. You will need to break apart your system
(transmit and receive) into modules or stages, and characterize each one
for latency. Beware of (uncontrolled) buffers at the interfaces. You
generally need to pick a reference point, such as the antenna port, and
correct everything to that reference point.

Third, you seem to be running a portion of the (SDR) receivers and the
demodulators/decoders on computers with Operating Systems. (Like WIndows
OS, which is NOT a real-time operating system.)  That means that the
response time of the system to a request for computing resources can be
quite variable. (microseconds to tens of milliseconds typical, with rare
excursions into the single digit seconds.)  The solution to this problem is
to either run on a very lightly loaded computer, or switch to a real time
OS, such as Linux with a real-time kernel. This does not cure the problem,
but does put bounds on it.

--- Graham / KE9H

==

On Tue, Oct 4, 2016 at 7:03 AM, Bob Camp <kb8tq at n1k.org> wrote:

> Hi
>
> As others have mentioned, you have two strikes against you:
>
> 1) Modern laptops *love* power saving. That makes them poor time keepers
> at the millisecond level. It takes some well thought out software in the
> OS to
> keep track of all the strange things they do.
>
> 2) Windows XP is getting a bit old and tired. It’s internals were done
> long ago
> on hardware very different than what we have today. It has a lot of
> limitations.
>
> Between the two, you will always struggle. An RTOS would do much better
> than
> XP for timing. Virtually all of the more modern OS’s (some of them free)
> will
> handle timing better than XP does. That’s not to say the laptop will not
> ultimately
> limit what you can do.
>
> There are a few more strikes when you try do do NTP over a residential
> internet
> connection. Cable modems and the like are not designed for high accuracy
> timing.
>
> By far the best solution is to get timing from a GPS. Even a cheap on,
> running over
> a lousy cable will get you into the 1 us region if it’s a modern unit.
> That is way
> better than the 5 ms that you are after. Moving it around on a local LAN
> with
> good cabling isn’t going to degrade it by much over 1 ms, even using NTP.
>
> One alternative to the whole “computers are a mess” issue is to simply put
> the
> GPS into the same hardware that is receiving / transmitting the signals .
> There
> are a *lot* of GPS modules on the market that will put out an accurate PPS
> signal.
> Depending on how picky you are, they are in the $10 to $50 range. Let the
> local
> hardware do the job rather than network the whole thing. Local hardware
> running
> a reasonable OS is in the $30 to $100 range, again depending on features.
> Given
> that you probably already have the price of a small car tied up in antenna
> systems,
> this isn’t that crazy a cost.
>
> Bob
>
>
> > On Oct 4, 2016, at 12:41 AM, Larry Hower <hower at hower.net> wrote:
> >
> > Hello to the List:
> >
> > After a long and bitter struggle with XP and WIN 10, I am writing to ask
> > for some help in solving some problems we have been having in our attempt
> > to establish a very accurate time reference for use in EME activities.
> >
> > We are hoping to achieve less than 5ms deviation, although anything below
> > 15ms will be adequate for now.
> >
> > Specifically, we want to use a universal reference that will enable
> amateur
> > radio operators in different parts of the world to start and stop their
> > transmissions within a few milliseconds of a specific time. For example,
> I
> > transmit at 12:00:00 for 1.75 minutes and “Joe” listens. Then “Joe”
> > transmits at 12:02:00 for 1.75 minutes. Repeat until QSO happens.
> >
> > We are using WSJT-X software. We use standard receivers plus we have
> tried
> > a few SDRs.
> >
> > Sorry for the oversimplified example but I want to make sure we are all
> on
> > the same page.
> >
> > As background:
> >
> > 1. We are using desktops and laptops in separate locations running XP or
> > Win 10.
> >
> > 2. We have used MS clock tools, including use of Boulder time servers,
> > tried both host name and IP address, without reaching the goal.
> >
> > 3. We have set up some Serial GPS units with PPS and some USB GPS
> receivers
> > (no PPS) and can get to about 0.2 sec but it is not trusted or close
> enough.
> >
> > 4. We have set up a network time server with similar results.
> >
> > 5. Deviation is measured using WSJT-X
> >
> > -----
> >
> > *Standard Receivers*
> >
> > ICOMs (910/9100 and others – non-SDR). Locked to 10MHz external osc
> > reference. We have frequency accuracy of 1 to 2 Hertz at 10GHz.
> >
> >
> > *SDRs*
> >
> > We believe that SDR processing can insert a delay of varying length,
> > depending on the software, bandwidth, etc. Our SDR tests seem to have a
> > delay of as much as 0.5 sec. And with sometimes variable results. We will
> > see how SDRs can be used after we resolve the current issues.
> >
> >
> > *Some time related hardware details*
> >
> > *1. Global Star 4 USB and Serial Connections*
> >
> > http://usglobalsat.com/p-688-bu-353-s4.aspx#images/product/large/688.jpg
> >
> > We have 4 of these. Two are older models with serial connections. We have
> > serial ports on some computers (XP and a new high-end laptop running WIN
> > 10) so we are able to activate the PPS option. Two of the GStar are newer
> > models with USB connections which are not able to use the PPS option.
> >
> > We have tried NEMATime and NEMATime 2 software on this hardware without
> > reaching our goal of <15ms. Range of deviation is from 0.0 to about 0.3
> > sec. Drifts.  Deviation is measured using WSJT-X.
> >
> >
> > *2. TimeNet NTP Device*
> >
> > http://www.veracityglobal.com/products/networked-video-integ
> > ration-devices/timenet.aspx
> >
> > We have one of these TimNet units and it has been set up at 2 different
> > locations on differing computers according to user instructions. We are
> > using the TimNet software as DL'd recently from their web site. We get
> GPS
> > “lock” and Time “lock” shown in the user panel but we do not have faith
> > that this is carried into the system clock. Occasionally the "lock"
> > indicators go blank but the time seems to be updated when the software is
> > strted again (the updated is operation is show at the correct time.  We
> > think the app needs some work. Deviation is measured using WSJT-X.  See
> > later details.
> >
> >
> > *Setup*
> >
> > The G Star units have been installed at 2 separate locations, tested
> using
> > WSJT-X QRA 64 and WSPR-2 signals on 10.137MHz.
> >
> > Similar tests with a TimeNet unit at one end and G Stars at the other
> end.
> >
> > G Star units were installed on the XP laptops with the PPS option enabled
> > and running WSJT-X. These XP units seem to have their time “in sync”. See
> > following.
> >
> >
> > *WSJT-X*
> >
> > We are not sure what, if any, internal delays there are attributable to
> > this software. We have been using the same version/build at both ends for
> > the tests. The software displays in 0.1 sec increments but will show
> 0.0sec
> > when things appear to be working well. We do not know the actual level of
> > precision of the WSJT-X software time measurements. I undersand that
> WSJT-X
> > “reads” the system clock at the start of a period (TX or RX) and displays
> > what it finds as the time deviation from the local system clock.
> >
> >
> > *WIN XP*
> >
> > There are 2 laptops running XP. They seem to match each other re time
> using
> > WSJT-X, both are “out” usually by less than 0.1ms or 0.2ms. We are fairly
> > sure that they are working properly but they need to be more accurate
> > (<15ms).
> >
> >
> > *WIN 10*
> >
> > Installed on a number of desktop and laptop computers. Many efforts were
> > made to make these system clocks reference the GPS devices.
> >
> > We became aware that the WIN Time/Date GUI was not always driving the
> > setting down into the system clock. We became aware also that the
> Registry
> > entries needed to be confirmed as far as NTP or local reference and the
> > sync cycle needed definition because of the same unreliable GUI actions.
> >
> > We found that we needed to start the Time Services and deal with some
> other
> > factors.  We have found that in WIN 10 the time/date clock does not show
> > the update when it happens automatically according to the setting in the
> > directly.  It does how the correct time of sync when we do it manually or
> > restart the GUI.
> >
> > The end result is that we don't trust WIN 10 and and we are not sure how
> to
> > fix the problem. Linux not allowed for now.
> >
> >
> > *Status*
> >
> > Our conclusion is that the external gear should be able to provide a more
> > accurate reference than we are able to obtain presently.  We think "it is
> > in there somewhere" but we can't get it out.
> >
> > We have a feeling that the WIN system clocks are not being updated
> > correctly or at least in a repeatable manner.  We don't know if the
> problem
> > is hardwaare or software or our setup / configurations.
> >
> > I ask for advice on how we can use the above gear or other gear or other
> > software to have our setup deliver better than 15ms accuracy.
> >
> > Ultimately we want sub-millisecond accuracy.
> >
> > Any help will be very much appreciated.  Thanks in advance for anything
> you
> > can advise.
> >
> > 73,
> >
> > Larry Hower
> >
> > VK7WLH
> >
> > W0LH
> > _______________________________________________
> > time-nuts mailing list -- time-nuts at febo.com
> > To unsubscribe, go to https://www.febo.com/cgi-bin/
> mailman/listinfo/time-nuts
> > and follow the instructions there.
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/
> mailman/listinfo/time-nuts
> and follow the instructions there.
>


More information about the time-nuts mailing list