Need Time Help
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:
-
We are using desktops and laptops in separate locations running XP or
Win 10. -
We have used MS clock tools, including use of Boulder time servers,
tried both host name and IP address, without reaching the goal. -
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. -
We have set up a network time server with similar results.
-
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
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.
[]
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
---===
Larry,
You can use a GPS puck or equivalent with PPS output to get the sort of
accuracy you need. I've written up some notes here:
http://www.satsignal.eu/ntp/Sure-GPS.htm
and you can see the results here for Windows 2000 and Windows-10 systems (I
no longer have an XP system with GPS/PPS reference):
http://www.satsignal.eu/mrtg/performance_ntp.php#windows-stratum-1
0.5 ms is easily achieved, although it's desirable to keep the systems
running 24 x 7 (or started well in advance) and as constant a temperature as
you can reasonably achieve helps.
If you want, you could also build or buy an external NTP reference based on
GPS/PPS, such as a Raspberry Pi or the LeoNTP server, and then sync the PCs
over the LAN or Wi-Fi, but the results won't be as good as a PPS input
direct to the PC:
http://www.satsignal.eu/ntp/Raspberry-Pi-quickstart.html
https://store.uputronics.com/index.php?route=product/product&product_id=92
I haven't read your long post in detail, so I hope the above suits.
73,
David GM8ARV
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk
Twitter: @gm8arv
On Mon, Oct 3, 2016 at 9:41 PM, Larry Hower hower@hower.net wrote:
- We are using desktops and laptops in separate locations running XP or
Win 10.
Assuming you have decent GPS receivers with an un-obstructed view of the
sky with 1 pulse per second output and you have let the GPS run long enough
to track enough satellites then... The pulse typically has a standard
deviation on the order of some tens of nanoseconds. So that is not your
problem. It is software., well mostly. Also computers that manage power
like notebooks are not going to give good timing performance no matter what
you try.
MS Windows is not the best choice for running NTP. You can do it. and
many people have gotten results better then 1 millisecond. But
If you are willing to give up the use of MS Windows. Then tens of
microseconds is not hard.
Little $35 credit card sized computers (Raspberry Pi) running Linux and NTP
with a GPS input are easy to get an order of magnitude better than your
requirement.
So are you stuck with windows. f so it can work with some rather complex
setup. If you can select another OS then you get out of the box
sub-millisecond performance with little effort
--
Chris Albertson
Redondo Beach, California
You can find some information here :
https://www.meinberg.de/download/burnicki/time_synchronization_accuracy_with_ntp.pdf
Please note the resolution of the system time in Win XP is only about 16 ms. The NTP service tries to extrapolate the system time to yield better resolution, but applications suffer from 16 ms anyway.
Martin
Am 4. Oktober 2016 06:41:58 MESZ, schrieb Larry Hower hower@hower.net:
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:
-
We are using desktops and laptops in separate locations running XP
or
Win 10. -
We have used MS clock tools, including use of Boulder time servers,
tried both host name and IP address, without reaching the goal. -
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. -
We have set up a network time server with similar results.
-
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@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
What's being transmitted?
If it's a repetitive message would it be possible to inhibit transmission
using an external time source, perhaps a PIC or even a Pi inhibiting the
"PTT", leaving the windows box in control of what's transmitted or do the
Windows boxes have to communicate with each other via some back channel?
On 4 Oct 2016 08:30, "Chris Albertson" albertson.chris@gmail.com wrote:
On Mon, Oct 3, 2016 at 9:41 PM, Larry Hower hower@hower.net wrote:
- We are using desktops and laptops in separate locations running XP or
Win 10.
Assuming you have decent GPS receivers with an un-obstructed view of the
sky with 1 pulse per second output and you have let the GPS run long enough
to track enough satellites then... The pulse typically has a standard
deviation on the order of some tens of nanoseconds. So that is not your
problem. It is software., well mostly. Also computers that manage power
like notebooks are not going to give good timing performance no matter what
you try.
MS Windows is not the best choice for running NTP. You can do it. and
many people have gotten results better then 1 millisecond. But
If you are willing to give up the use of MS Windows. Then tens of
microseconds is not hard.
Little $35 credit card sized computers (Raspberry Pi) running Linux and NTP
with a GPS input are easy to get an order of magnitude better than your
requirement.
So are you stuck with windows. f so it can work with some rather complex
setup. If you can select another OS then you get out of the box
sub-millisecond performance with little effort
--
Chris Albertson
Redondo Beach, California
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/
mailman/listinfo/time-nuts
and follow the instructions there.
On 10/4/2016 6:41 AM, Larry Hower wrote:
Hello to the List:
Hi and welcome!
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.
You have a much higher budget for amateur radio gear than I do if you're
doing EME. I'm envious. :)
We are hoping to achieve less than 5ms deviation, although anything below
15ms will be adequate for now.
This should be quite feasible, even with Windows.
That said, is such precision really necessary? I know that JT65 and JT9
both require "good" time sync, but is millisecond-level precision
needed? I've had good results for terrestrial contacts with time
differences ranging from 0.0 to 1.0 seconds. EME might require tighter
sync, of course.
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.
GPS should be that "universal" (really, planetary) reference.
-
We are using desktops and laptops in separate locations running XP or
Win 10. -
We have used MS clock tools, including use of Boulder time servers,
tried both host name and IP address, without reaching the goal.
No surprise. The built in Microsoft timekeeping software is "good
enough" for typical computing purposes (within a second or two) but
isn't really sufficient for your purposes.
Desktops will be easy, assuming they have a serial port or a serial
header on the computer itself. If the desktop only has a serial header,
a cheap adapter like
https://www.amazon.com/StarTech-com-Serial-Motherboard-Header-PLATE9M16/dp/B001Y1F0HW/
will connect the header to a standard serial connector.
Laptops might be harder. Using NTP software to a good NTP server on the
internet should get you within a few milliseconds. Synced to a good NTP
server on the LAN with the server using GPS+PPS should get you within a
millisecond.
-
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. -
We have set up a network time server with similar results.
-
Deviation is measured using WSJT-X
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.
This isn't really surprising. If the SDRs are connected via USB, there's
additional delays and jitter inherent in that connection.
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.
The BU-353-S4 lacks a PPS line to precisely signal the start of each
second. (At least the specific one I have for mapping doesn't have that
option.) Although you may get somewhat better precision using the SiRF
binary stream, your deviation is about what I'd expect for a USB
receiver with NMEA output.
Simply put, without PPS you probably won't get closer than 250ms unless
you're quite lucky. Doubly so if you're using PPS-over-USB.
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.
I wonder if you'll get better results using Meinberg's Windows port of
NTPd: https://www.meinbergglobal.com/english/sw/ntp.htm -- you should
be able to configure it to query your TimNet device and get reasonably
good precision.
Meinberg's NTP software is explicitly recommended in the WSJT-X
documentation.
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.
According to the manual at
http://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main-1.6.0.html#TUT_EX2,
the DT column shows the offset between the time of the remote station
and your local system clock, not between your local system clock and UTC.
I'm not sure if the time difference displayed compensates for speed of
light delays.
I suspect the software is able to compensate for internal delays, else
it wouldn't be much use.
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).
I assume your "out" time is in seconds, not milliseconds.
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.
Try Meinberg's NTP software and GPS receivers with PPS outputs.
I've had good luck with the Garmin GPS 18x LVC
https://buy.garmin.com/en-US/US/oem/sensors-and-boards/gps-18x-oem/prod27594.html.
It's available for ~$70 USD from Amazon at
https://www.amazon.com/Garmin-18x-LVC-Navigator-Unit/dp/B0016O3T7A/ --
it comes with a bare wire connector and you'd need to solder the
appropriate connector for 5V power and serial connections.
Note: you need the LVC model, as this has PPS output. The USB and "PC"
(standard serial) do not do PPS output.
I added some extra bits to blink an LED with each PPS, and an LED for
power. The USB pigtail provides power while the serial connection goes
directly into a hardware serial port. Here's a pictures of my connector:
http://imgur.com/a/PEiBU
There's lots of other great GPS receivers with PPS output, including old
timing receivers like the Motorola Oncore, Trimble Resolution T, etc.
Those PPS outputs are typically within 20-100 nanoseconds. Oncore UT+'s
are about $20 on eBay --
http://www.ebay.com/itm/Motorola-UT-Plus-Oncore-Timing-GPS-1PPS-50-ns-/270467197172,
while the Resolution T is about $50
http://www.ebay.com/itm/Trimble-Resolution-T-Timing-GPS-module-12ns-1pps-/252474351979.
The only downside of the Resolution T is the pinout does not use the
common 2.54mm/0.1" spacing, but instead uses 2mm spacing.
I've had excellent luck with my GPS 18x LVC feeding my Windows 7 PC
running ToyNTP via a hardware serial port:
http://www.dxatlas.com/ToyNtp/. It steers the system clock using a
Kalman filter and is remarkably good. I typically see offsets <10
microseconds. The only caveat is that ToyNTP requires NMEA output at
4800bps. Other speeds and other formats won't work; keep this in mind if
you use older GPS receivers that might not output NMEA.
Cheers!
-Pete
Hi
As others have mentioned, you have two strikes against you:
-
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. -
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@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:
-
We are using desktops and laptops in separate locations running XP or
Win 10. -
We have used MS clock tools, including use of Boulder time servers,
tried both host name and IP address, without reaching the goal. -
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. -
We have set up a network time server with similar results.
-
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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
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@n1k.org wrote:
Hi
As others have mentioned, you have two strikes against you:
-
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. -
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@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:
-
We are using desktops and laptops in separate locations running XP or
Win 10. -
We have used MS clock tools, including use of Boulder time servers,
tried both host name and IP address, without reaching the goal. -
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.
-
We have set up a network time server with similar results.
-
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@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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/
mailman/listinfo/time-nuts
and follow the instructions there.
From: Graham / KE9H
Larry:
[]
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.
[]
--- Graham / KE9H
---=====
Graham,
I showed graphs of five Windows systems using a PPS feed this morning all
keeping time to within a millisecond, far better than "single digit
seconds".
http://www.satsignal.eu/mrtg/performance_ntp.php#windows-stratum-1
Note that PC Alta shows a transient following a reboot, and the PPS feed has
since been stolen from PC Bacchus around 13:00 UTC so that I can carry out
some tests comparing USB PPS with Wi-Fi network syncing.
Your other points are well taken.
73,
David GM8ARV
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk
Twitter: @gm8arv
On 10/4/16 6:26 AM, Graham / KE9H wrote:
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
One way that seems to work fairly well, as long as you can post process
(or your "turnaround latency" can be in the "seconds" bucket).. is to
record a time reference signal that is added to the original RF signal.
A pilot tone, or a modulated tone, somewhat away from your desired
signal, generated by a high quality time reference (maybe you have an
XO, and you phase modulate it with the 1pps from your GPS receiver).
Then, in your downconverted, digitized, and filtered data, you look for
the time reference and use that as what you need, rather than trying to
back out all the (non-deterministic) delays through the audio processing
chain.
By the way, Windows can be very good on synchronizing audio: otherwise
audio and video wouldn't play together in media, high performance gaming
wouldn't work, etc. The problem is that it is a royal, giant, pain to
get it to work. You need a lot of knowledge and experience with exactly
how Windows handles the media streams, all those countless APIs, etc.
And it is different for each version of Windows. (Realistically, Linux
and Mac OS X are no better: the nature of the difficulties is different,
but they're still there)
The typical amateur radio spectrogram program or demodulator probably
doesn't do that: they use a simple FIFO pipeline, and make no claim that
what's on the screen matches what's at the antenna at a particular
instant, as long as the order and duration is correct eventually. If
you're decoding CW with CW skimmer or decoding PSK31, you probably
aren't doing full break-in between the dots and dashes or characters: a
few tenths of a second random lag doesn't make any difference
(especially since the signal you're receiving is over a
non-deterministic delay skywave path)
My philosophy (and the one that wound up embedded in our design of a
Software Defined Radio framework for space radios) is that software
handles the management of timing critical processing implemented in a
FPGA. Sample accurate timing is done basically in hardware, and
software (running on whatever OS - we use RTEMS which is pretty good
Real Time, but...) talks to the hardware using a model which says, in
effect, don't try to synchronize across this interface at resolutions
finer than 1 millisecond. (For non Real Time OS, I'd try for 10s of
milliseconds)
For a simple instance, we latch a a free running counter driven from an
OCXO with the GPS 1pps. That's in hardware. The software just has to
guarantee that it reads the latch at least once a second and we can
collect the data we're interested in. If it can't guarantee that, that
it can figure out what happened if we miss a latch event (i.e. the count
looks like it increased by twice the expected increment) or we read too
often (the count didn't change).
Then, if we need an event to occur at a precise time, we can calculate
(in our own sweet non-deterministic time) what counter value that time
would correspond to. We load that into another register, which is
compared with the free running counter, and the equality triggers the event.
Obviously, we need to schedule the future event sufficiently far into
the future that we have time to do the calculations. But figuring out a
"worst case bounded maximum time" is a lot easier than "must calculate
everytime within 1 millisecond" hard real time kind of constraint.
We can also be very fancy in our model of "time vs counter reading". We
can, for instance, use the last 10,000 1pps tick latched values to
estimate the future clock rate and drift (essentially what GPSDO
algorithms do). Or, we can be simple: use the delta between two
successive ticks as the estimate of the clock rate, assume it's
unchanging, and go from there.
One of the fascinating problems that arises for us (and will arise for
you) is that you might need to synchronize a good clock against a bad
one. That is, in order to have events occur in multiple places at the
same "time", you essentially need to predict the behavior of the worst
clock in the system, and then have everyone else follow that.
I'd also comment that testing of such a system is challenging: you need
to generate a test signal that occurs at a precisely known time, and see
if your system captures it, and it shows up at the right sample time.
So the latency of your test equipment (hardware again) needs to be
understood and known.