Date   

locked Re: Clock Sync #Timesync

Jim Pennino
 

Yeah, sometimes there is a disconnect between the brain and the fingers...

What it should have said is the propagation VELOCITY is about 250 meters per microsecond or 4 nanoseconds per meter.

For those interested, the device I ordered is: https://www.ebay.com/itm/174136333219

Note that one needs to specify which GNSS system(s) (max of two) you want to use. As I am in the US, I chose GPS+GLONASS.

Re the Adafruit GPS HAT: I recently upgraded my old GPS HAT to the current GNSS HAT. It is too soon to have precise numbers, but it appears that the accuracy of this HAT, to a 95% confidence level, is a bit under 200 microseconds.

Jim WB6DKH


locked Re: #FT8 How to restore grid to 'needed' status for alerts #FT8

Pietro Molina
 

It's a simple text file (XML formatted), so notepad is good to edit.
My suggest is to use notepad+ with XML plugin, It helps to show a friendly view.

Pietro

Pietro (mobile)


Il lun 19 lug 2021, 15:45 Bob Wolters <bobw5xc@...> ha scritto:

I have not tried to edit an .ADI file, can someone tell me what additional software to use to edit one ?

 

Thanks again,

 

Bob                    W5XC

 

From: main@WSJTX.groups.io [mailto:main@WSJTX.groups.io] On Behalf Of Pietro Molina
Sent: Monday, July 19, 2021 6:42 AM
To: main@wsjtx.groups.io
Subject: Re: [WSJTX] #FT8 How to restore grid to 'needed' status for alerts

 

Well, the solution by Reino is more elegant.. you won't loose the qso, but only restore the grid as unworked.

 

73

 

I2OIM

Pietro (via Tablet)

 

Il lun 19 lug 2021, 13:10 Reino Talarmo <reino.talarmo@...> ha scritto:

Bob, look at that call in the wsjtx_log.adi file and delete it.

Pietro I2OIM

Hi,

There are two more sensible or logical solutions as well.

If the actual grid is known, replace the current by it, otherwise change gridsquare length to “0” and delete the current one.
In Both solutions the grid is “not worked” on the WSJT-X point of view. Well, a Rescan or WSJT-X closing and opening is needed to update PC knowledge.

73, Reino OH3mA



 

Virus-free. www.avg.com

 





locked Re: Clock Sync #Timesync

Joe
 

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


locked Re: Clock Sync #Timesync

 

Thanks Jim.  As I suspected, there was much I didn’t understand.  One good point is that the new USB3 cable is much better quality than the old one.

 

As part of my military service I was a calibration team chief.  Our time/frequency reference was via a VLF time signal supplied by NBS and broadcast courtesy of the Navy.  That was 1975 time frame.  How far have we come.

 

I will remove the older GPS puck.  It has been concerning me anyway. 

 

I am in the middle of a rebuilding a Raspberry Pi 2 and I have the Adafruit GPS hat.  If I can get that working, I will discontinue using the pucks.  Prices do change and the Adafruit hat ran $62 with shipping, but it will be an interesting project.  Thankfully there is an abundance of help from those who have already accomplished this project to guide me.

 

__________

Dan – K4SHQ

CFI/II

 

From: main@WSJTX.groups.io <main@WSJTX.groups.io> On Behalf Of Jim Pennino via groups.io
Sent: Monday, July 19, 2021 10:55 AM
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] Clock Sync #Timesync

 

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


locked Re: Clock Sync #Timesync

Robert Lorenzini
 

Which GPSDO did you settle on Jim? I have a BG9 clone and a Bodnar. The BG9 osc has drifted
beyond where it can be corrected but I'm still using the NMEA for position only.

Bob - wd6dod

On 7/19/2021 8:55 AM, Jim Pennino via groups.io wrote:
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




locked Re: Clock Sync #Timesync

Jim Pennino
 

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


locked Re: Contest mode? #ContestMode

George J Molnar, KF2T
 

One enhancement that might help in this situation is to build a call queue that allows multiple callers to be stacked and worked either sequentially or from a pick list by the operator. The progress of each contact could be maintained so that in QSB or scatter situations, contacts could “interleave” a little bit to improve rate.  Rare grid rovers, expeditions, and other popular stations could benefit. 


Having a blast on the radio. Thanks to all!

George/KF2T


locked Re: #WSJTX_config - Rigblaster HRD WSJTX No Audio Device Configured #WSJTX_config

Bill Somerville
 

On 19/07/2021 15:51, Paul St John wrote:
I am using a Lenovo Core i3 10 Gen running HRD and WSJT-X to a Rigblaster Advanced and a KX3. It works perfectly with an old HP Laptop.  However, using the same settings on my Lenovo Laptop the HRD CAD seems to work and I can start WSJT-X. However, I see no sound coming into the program from the KX3. There are no decodes and when I hit tune, I get the error message “No audio output device configured.” The only difference in settings between the two laptops - that I can see - is that the HP Laptop connects through COM 13, whereas the Lenovo is using COM4.  I have used the Rigblaster software on the Lenovo to create a COM 13 and then used HRD to find it, but that hasn’t helped.  I checked the Rigblaster function using the General Tab on both the Microphone and the Speakers tab in the Control Panel. Both reported the Location as RIGblaster Advantage Audio, and under Device Status said, “This device is working properly.” Yet it doesn’t work on the Lenovo.   I got normal output into the Lenovo’s speakers when I brought up a Youtube video, so I think the Lenovo soundcard is working ok. Any suggestions would be greatly appreciated.

Tnx, Paul, N6DNM
Paul,

you need to set up the audio input and output for WSJT-X in "Settings->Audio". If you are on Windows 10 then you may need to allow WSJT-X to use microphone devices in teh Camera and Microphone Privacy settings of Windows.

73
Bill
G4WJS.


locked #WSJTX_config - Rigblaster HRD WSJTX No Audio Device Configured #WSJTX_config

Paul St John
 

I am using a Lenovo Core i3 10 Gen running HRD and WSJT-X to a Rigblaster Advanced and a KX3. It works perfectly with an old HP Laptop.  However, using the same settings on my Lenovo Laptop the HRD CAD seems to work and I can start WSJT-X. However, I see no sound coming into the program from the KX3. There are no decodes and when I hit tune, I get the error message “No audio output device configured.” The only difference in settings between the two laptops - that I can see - is that the HP Laptop connects through COM 13, whereas the Lenovo is using COM4.  I have used the Rigblaster software on the Lenovo to create a COM 13 and then used HRD to find it, but that hasn’t helped.  I checked the Rigblaster function using the General Tab on both the Microphone and the Speakers tab in the Control Panel. Both reported the Location as RIGblaster Advantage Audio, and under Device Status said, “This device is working properly.” Yet it doesn’t work on the Lenovo.   I got normal output into the Lenovo’s speakers when I brought up a Youtube video, so I think the Lenovo soundcard is working ok. Any suggestions would be greatly appreciated.

Tnx, Paul, N6DNM

--
Paul St. John, N6DN


locked Re: #Transmit #K4 - Split Operation -> DATA-R Mode on Elecraft K4 #transmit #Elecraft

Rick Tavan
 

Yes, on W9MDB's recommendation I tried V. 2.5.0 and it fixed the problem. "Split Operation | Rig" works fine on K4 now. Thanks!

/Rick N6XI

On Mon, Jul 19, 2021 at 2:52 AM Bill Somerville <g4wjs@...> wrote:
On 19/07/2021 02:38, Rick Tavan wrote:
> I'm running WSJT-X 2.4.0 on a Dell XPS-13 laptop, running Windows 10
> Home 19.09 connected to an Elecraft K4 in DATA mode. Settings | Radio
> | Split Operation = Rig in order to position the transmit tone in the
> passband. I believe SPLIT was working a few WSJT-X releases ago. Now,
> when I double-click a CQ in the left-hand window, it puts the K4 VFO B
> into DATA-R mode ("reverse") and the K4 complains on its screen that
> that type of split mode isn't allowed. I suppose it also returns an
> error to WSJT-X because it then refrains from using SPLIT mode.
> Instead, it transmits on VFO A which remains at the bottom of the
> band. I'm pretty sure this was introduced in a recent release of
> WSJT-X. Any thoughts?
>
> Thanks & 73,
>
> /Rick N6XI

Hi Rick,

give WSJT-X V2.5.0 RC3 a try and let us know how it goes please?

73
Bill
G4WJS.






--
--

Rick Tavan
Truckee and Saratoga, CA


locked Re: #FT8 How to restore grid to 'needed' status for alerts #FT8

Brad, K8ZM
 

These are just text files so any text editor will work, notepad works fine.

73, Brad N8GLS

Sent from my Samsung Galaxy S10 "not so" Smartphone


-------- Original message --------
From: Bob Wolters <bobw5xc@...>
Date: 7/19/21 9:45 AM (GMT-05:00)
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] #FT8 How to restore grid to 'needed' status for alerts

I have not tried to edit an .ADI file, can someone tell me what additional software to use to edit one ?

 

Thanks again,

 

Bob                    W5XC

 

From: main@WSJTX.groups.io [mailto:main@WSJTX.groups.io] On Behalf Of Pietro Molina
Sent: Monday, July 19, 2021 6:42 AM
To: main@wsjtx.groups.io
Subject: Re: [WSJTX] #FT8 How to restore grid to 'needed' status for alerts

 

Well, the solution by Reino is more elegant.. you won't loose the qso, but only restore the grid as unworked.

 

73

 

I2OIM

Pietro (via Tablet)

 

Il lun 19 lug 2021, 13:10 Reino Talarmo <reino.talarmo@...> ha scritto:

Bob, look at that call in the wsjtx_log.adi file and delete it.

Pietro I2OIM

Hi,

There are two more sensible or logical solutions as well.

If the actual grid is known, replace the current by it, otherwise change gridsquare length to “0” and delete the current one.
In Both solutions the grid is “not worked” on the WSJT-X point of view. Well, a Rescan or WSJT-X closing and opening is needed to update PC knowledge.

73, Reino OH3mA



 

Virus-free. www.avg.com

 


locked Re: #BugReport #logging Failure to log contact correctly #IssueReport #logging

 

Bill,

I tried that previously, but because of the use I make of these fields in the status UDP, I want them cleared after logging. I use them to display current contact location in DxAtlas. I'll try and see if I can log then start the new contact. failing that, log as soon as I send the RR73 as Jim K9YC's suggestion.

--
73 Phil GM3ZZA


locked Re: #FT8 How to restore grid to 'needed' status for alerts #FT8

Bob Wolters <bobw5xc@...>
 

I have not tried to edit an .ADI file, can someone tell me what additional software to use to edit one ?

 

Thanks again,

 

Bob                    W5XC

 

From: main@WSJTX.groups.io [mailto:main@WSJTX.groups.io] On Behalf Of Pietro Molina
Sent: Monday, July 19, 2021 6:42 AM
To: main@wsjtx.groups.io
Subject: Re: [WSJTX] #FT8 How to restore grid to 'needed' status for alerts

 

Well, the solution by Reino is more elegant.. you won't loose the qso, but only restore the grid as unworked.

 

73

 

I2OIM

Pietro (via Tablet)

 

Il lun 19 lug 2021, 13:10 Reino Talarmo <reino.talarmo@...> ha scritto:

Bob, look at that call in the wsjtx_log.adi file and delete it.

Pietro I2OIM

Hi,

There are two more sensible or logical solutions as well.

If the actual grid is known, replace the current by it, otherwise change gridsquare length to “0” and delete the current one.
In Both solutions the grid is “not worked” on the WSJT-X point of view. Well, a Rescan or WSJT-X closing and opening is needed to update PC knowledge.

73, Reino OH3mA



 

Virus-free. www.avg.com

 


locked Re: #FT8 How to restore grid to 'needed' status for alerts #FT8

Pietro Molina
 

Well, the solution by Reino is more elegant.. you won't loose the qso, but only restore the grid as unworked.

73

I2OIM

Pietro (via Tablet)


Il lun 19 lug 2021, 13:10 Reino Talarmo <reino.talarmo@...> ha scritto:

Bob, look at that call in the wsjtx_log.adi file and delete it.

Pietro I2OIM

Hi,

There are two more sensible or logical solutions as well.

If the actual grid is known, replace the current by it, otherwise change gridsquare length to “0” and delete the current one.
In Both solutions the grid is “not worked” on the WSJT-X point of view. Well, a Rescan or WSJT-X closing and opening is needed to update PC knowledge.

73, Reino OH3mA





locked Re: #FT8 How to restore grid to 'needed' status for alerts #FT8

Reino Talarmo
 

Bob, look at that call in the wsjtx_log.adi file and delete it.

Pietro I2OIM

Hi,

There are two more sensible or logical solutions as well.

If the actual grid is known, replace the current by it, otherwise change gridsquare length to “0” and delete the current one.
In Both solutions the grid is “not worked” on the WSJT-X point of view. Well, a Rescan or WSJT-X closing and opening is needed to update PC knowledge.

73, Reino OH3mA


locked Re: WSJT-X rev 2.4.0 Split Operation Issue #Cat_RigControl

Stephen Malyszka
 

Thanks to all who have responded. It looks like WSJT-X ver 2.5.0-rc3 has solved the problem. I appreciate your help in resolving this issue.

Steve
AG2J
Frankford Radio Club


locked Re: #Transmit #K4 - Split Operation -> DATA-R Mode on Elecraft K4 #transmit #Elecraft

Bill Somerville
 

On 19/07/2021 02:38, Rick Tavan wrote:
I'm running WSJT-X 2.4.0 on a Dell XPS-13 laptop, running Windows 10 Home 19.09 connected to an Elecraft K4 in DATA mode. Settings | Radio | Split Operation = Rig in order to position the transmit tone in the passband. I believe SPLIT was working a few WSJT-X releases ago. Now, when I double-click a CQ in the left-hand window, it puts the K4 VFO B into DATA-R mode ("reverse") and the K4 complains on its screen that that type of split mode isn't allowed. I suppose it also returns an error to WSJT-X because it then refrains from using SPLIT mode. Instead, it transmits on VFO A which remains at the bottom of the band. I'm pretty sure this was introduced in a recent release of WSJT-X. Any thoughts?

Thanks & 73,

/Rick N6XI
Hi Rick,

give WSJT-X V2.5.0 RC3 a try and let us know how it goes please?

73
Bill
G4WJS.


locked Re: #JT9+JT65 combined menu option

Reino Talarmo
 

Karza and Panos,

I do not see what else can be said, the reasons were stated clearly in the release notes for the version when Dual JT9+JT65 mode was removed.

73
Bill
G4WJS.

Bill,
Just an observation for same reason the current release notes no more state the removal. JT9 is mentioned last time in V2.3.0.
Reino


locked Re: #Transmit #K4 - Split Operation -> DATA-R Mode on Elecraft K4 #transmit #Elecraft

ve3ki
 

Two possible work-arounds:

1. In the WSJT-X settings, set Mode to None so WSJT-X won't try to change the rig's mode.

2. In the WSJT-X settings, for Split Operation use Fake It instead of Rig, so WSJT-X won't try to use VFO B.

73,
Rich VE3KI


On Sun, Jul 18, 2021 at 11:02 PM, Rick Tavan wrote:
I'm running WSJT-X 2.4.0 on a Dell XPS-13 laptop, running Windows 10 Home 19.09 connected to an Elecraft K4 in DATA mode. Settings | Radio | Split Operation = Rig in order to position the transmit tone in the passband. I believe SPLIT was working a few WSJT-X releases ago. Now, when I double-click a CQ in the left-hand window, it puts the K4 VFO B into DATA-R mode ("reverse") and the K4 complains on its screen that that type of split mode isn't allowed. I suppose it also returns an error to WSJT-X because it then refrains from using SPLIT mode. Instead, it transmits on VFO A which remains at the bottom of the band. I'm pretty sure this was introduced in a recent release of WSJT-X. Any thoughts?
 
Thanks & 73,
 
/Rick N6XI
 
--
--

Rick Tavan
Truckee and Saratoga, CA


locked Re: #FT8 How to restore grid to 'needed' status for alerts #FT8

Pietro Molina
 

Bob, look at that call in the wsjtx_log.adi file and delete it.

Pietro I2OIM

10261 - 10280 of 36948