This has been well covered recently in this forum, almost to the point of becoming annoying.  Please take note and pass the word to your ham friends. 
1)  FCC RULES PART 97 DOES NOT REQUIRE OR EVEN MENTION THE IDEA OF MODIFYING YOUR ISSUED OPERATOR CALL SIGN WITH A /P, /M, OR /R SUFFIX.  It has been over 45 years since that ID method and the single licensed station location concept was abandoned by the FCC,
2)  Well meaning amateur "Elmers", PLEASE STOP teaching new hams those archaic cancelled ID rules which do not exist in Part 97. They are incompatible with the advanced digital QSO technologies available to us.  The ITU defines a reversed format for amateur DX operation outside the licensee's country which uses the host country's assigned prefix. 
3)  When operating WSJTx modes you enter your issued callsign (maximum 6 characters) and your grid square. Nothing else will fit into the highly compressed data protocols of these weak signal modes and be readable by your QSO partner at the other end.  Meanwhile, ARRL and others offering virtual QSL services have added multiple location capability into their packages, specifically to accomodate amateur operators with more than one station equipment location. 
- -

Karl  WA8NVW  OH
WA8NVW@...
in WSJTX@groups.io

 

On Jul 19, 2021, at 11:55 AM, Joe <joe@...> wrote:

Hi Jim,

"If one assumes the velocity factor of a USB cable is about 80%, that means about 250 microseconds of propagation delay per meter."

Let's see...  the speed of light is 3 x 10^8 m/s, so the delay in a 1 meter cable is 1.0/(0.8x3x10^8) = 4.2 x 10^-9.  I make it around 4 nanoseconds, not 250 microseconds.  But you're certainly right, the cable delay is well under a millisecond.  :-)

  -- 73, Joe, K1JT

In my testing I have tried various combinations of multiple receivers and I do NOT recommend attaching more than one reference clock, i.e. a GPS, to a machine.

NTP will work with more than one, but I have seen some strange things happen when both devices are of equal quality.

For devices of equal quality, it appears to take ntp longer to decide which one to select and occasionally marks both as false tickers. I am guessing that is because the developers of ntp never envisioned someone could actually afford having more than one high quality source and the selection algorithms are having difficulty deciding between them.

For devices of unequal quality, ntp will quickly pick the better device and the second device from then on serves no purpose, e.g. with a USB GPS and a PPS serial GPS, ntp quickly selects the PPS serial GPS.

I suggest moving one GPS to another machine or just keep it as back up in the remote case of failure.

As for delay times, the actual delay will depend on ALL the hardware involved. My value of 30 milliseconds is a rough average for all the systems I've tested and is just a starting point. Of all the devices I've tested, the VK-162 showed the least delay and the device with the largest delay was about 750 milliseconds, so yes, the delay can be quite large. If the delay pushes 1,000 milliseconds or goes over that (I have seen one that did which got binned), I would not trust the device for time keeping and use something else. Your numbers look reasonable to me.

A couple of other miscellaneous notes while I'm at it:

If one assumes the velocity factor of a USB cable is about 80%, that means about 250 microseconds of propagation delay per meter. As delay times are in the milliseconds, then a 4 meter USB extension cable should add about 1 millisecond of delay, which is down in the noise level of the jitter. Some quick testing of extension cables shows this to be true. I would, however, only use shielded cables in a RF environment least the cables become antennas.

During my career I often worked with clients that had a real need for accurate time and it was not unusual for a client to spend tens of thousands of dollars in today's money on hardware plus my fees to achieve this. In my retirement I became interested in how far the state of the art has progressed and wondered about the quality of time keeping hardware available for the arbitrary limit of $50 as well as what useful things can be done with a Raspberry Pi, thus all this testing.

I decided to up the game and have ordered a GNSS disciplined OCXO oscillator. While the oven controlled oscillator just guarantees an accuracy of a few nanoseconds, at $180 it is about $600 cheaper than a rubidium oscillator and there are limits to retirement hobby spending. As a bonus this will provide a 10 MHz reference that is +/- 0.0002 Hz for my frequency counter, or anything else with an external reference input.

If anyone is interested in either/or high accuracy time keeping or frequency measurement, I can write up the results after I have done testing of this device.

Jim WB6DKH

In my testing I have tried various combinations of multiple receivers and I do NOT recommend attaching more than one reference clock, i.e. a GPS, to a machine.

NTP will work with more than one, but I have seen some strange things happen when both devices are of equal quality.

For devices of equal quality, it appears to take ntp longer to decide which one to select and occasionally marks both as false tickers. I am guessing that is because the developers of ntp never envisioned someone could actually afford having more than one high quality source and the selection algorithms are having difficulty deciding between them.

For devices of unequal quality, ntp will quickly pick the better device and the second device from then on serves no purpose, e.g. with a USB GPS and a PPS serial GPS, ntp quickly selects the PPS serial GPS.

I suggest moving one GPS to another machine or just keep it as back up in the remote case of failure.

As for delay times, the actual delay will depend on ALL the hardware involved. My value of 30 milliseconds is a rough average for all the systems I've tested and is just a starting point. Of all the devices I've tested, the VK-162 showed the least delay and the device with the largest delay was about 750 milliseconds, so yes, the delay can be quite large. If the delay pushes 1,000 milliseconds or goes over that (I have seen one that did which got binned), I would not trust the device for time keeping and use something else. Your numbers look reasonable to me.

A couple of other miscellaneous notes while I'm at it:

If one assumes the velocity factor of a USB cable is about 80%, that means about 250 microseconds of propagation delay per meter. As delay times are in the milliseconds, then a 4 meter USB extension cable should add about 1 millisecond of delay, which is down in the noise level of the jitter. Some quick testing of extension cables shows this to be true. I would, however, only use shielded cables in a RF environment least the cables become antennas.

During my career I often worked with clients that had a real need for accurate time and it was not unusual for a client to spend tens of thousands of dollars in today's money on hardware plus my fees to achieve this. In my retirement I became interested in how far the state of the art has progressed and wondered about the quality of time keeping hardware available for the arbitrary limit of $50 as well as what useful things can be done with a Raspberry Pi, thus all this testing.

I decided to up the game and have ordered a GNSS disciplined OCXO oscillator. While the oven controlled oscillator just guarantees an accuracy of a few nanoseconds, at $180 it is about $600 cheaper than a rubidium oscillator and there are limits to retirement hobby spending. As a bonus this will provide a 10 MHz reference that is +/- 0.0002 Hz for my frequency counter, or anything else with an external reference input.

If anyone is interested in either/or high accuracy time keeping or frequency measurement, I can write up the results after I have done testing of this device.

Jim WB6DKH