I think to sum up what has been written 1) USB connection will not work well for timing 2) Notebook computers dont work well for timing 3) A good NTP server on your LAN can get you "close" to what you need even on PC notebooks 4) With effort and a real serial port and after downloading a copy of NTP and configuring it even Windows desktop system can do better than 1 milli second. But if your typical user is not really knowable about PCs he will have trouble with this 5) Any Linux system, even the tiny Pi. can perform very well (orders of magnitude better than your requirement) and serve a large number of computers on a LAN.
I think if you are stuck with running Windows on a notebook that lacks serial ports the best way to get timing information into that machine is via the Ethernet port (not WiFi, wired Ethernet) But;d a local NTP server. (cost under $100 including GPS and antenna) If you have a desktop Windows PC with a real serial port (not USB) and a user who can install software and edit text baed configuration files and make cables then you can connect a GPS directly to the computer and it will work as well as you need On Tue, Oct 4, 2016 at 1:51 AM, Pete Stephenson <p...@heypete.com> wrote: > 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. > > > 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. > > 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. > > > 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 > > > 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 > _______________________________________________ > 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. > -- 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.
