Rig forced to VFO A by WSJT-X #Windows 10 #WSJTX_config #Cat_RigControl #Windows10


Ricky Gilliland
 

Currently using WSJT-X version 2.3.0 oc42df. After upgrading to 2.5.0 the software pre-selects VFO-A at start up instead of VFO-B which the rig is set to. Previous versions always read the rig correctly. When I press Test Cat in settings the software switches back to VFO-A. Is there a setting I need to change in this new version or is this a glitch?


Bill Somerville
 

On 03/10/2021 16:32, Ricky Gilliland via groups.io wrote:
Currently using WSJT-X version 2.3.0 oc42df. After upgrading to 2.5.0 the software pre-selects VFO-A at start up instead of VFO-B which the rig is set to. Previous versions always read the rig correctly. When I press Test Cat in settings the software switches back to VFO-A. Is there a setting I need to change in this new version or is this a glitch?
Hi Ricky,

the Hamlib developers have decided that to use their library the rig must be on VFO A. I understand that this is a new restriction but I doubt that it will change. Is there any particular reason why selecting VFO B is important with your rig?

73
Bill
G4WJS.


Gilbert Baron
 

What a stupid restriction for a general use module. Unbelievable.

Outlook Laptop Gil W0MN
Hierro candente, batir de repente
44.08226N 92.51265W EN34rb

-----Original Message-----
From: main@WSJTX.groups.io <main@WSJTX.groups.io> On Behalf Of Bill Somerville
Sent: Sunday, October 3, 2021 10:52
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] Rig forced to VFO A by WSJT-X #Windows 10 #WSJT-X_Config #Cat_RigControl

On 03/10/2021 16:32, Ricky Gilliland via groups.io wrote:
Currently using WSJT-X version 2.3.0 oc42df. After upgrading to 2.5.0
the software pre-selects VFO-A at start up instead of VFO-B which the
rig is set to. Previous versions always read the rig correctly. When I
press Test Cat in settings the software switches back to VFO-A. Is
there a setting I need to change in this new version or is this a glitch?
Hi Ricky,

the Hamlib developers have decided that to use their library the rig must be on VFO A. I understand that this is a new restriction but I doubt that it will change. Is there any particular reason why selecting VFO B is important with your rig?

73
Bill
G4WJS.




--
W0MN EN34rb 44.08226 N 92.51265 W

Hierro candente, batir de repente

HP Laptop


Michael Black
 

FYI...I'm going to work on fixing this.  This was a quick fix to another problem but apparently causes other problems.

Mike W9MDB


On Sunday, October 3, 2021, 10:49:38 AM CDT, Ricky Gilliland via groups.io <rwgilland@...> wrote:


Currently using WSJT-X version 2.3.0 oc42df. After upgrading to 2.5.0 the software pre-selects VFO-A at start up instead of VFO-B which the rig is set to. Previous versions always read the rig correctly. When I press Test Cat in settings the software switches back to VFO-A. Is there a setting I need to change in this new version or is this a glitch?




Bob McGraw - K4TAX
 

So what is so important about VFO B?   Doesn't VFO A have the same capability?   If so, then that which is so important on VFO A can be done on VFO B.   Just let the software do its job and learn to use it as designed.  

I think hams spend most of their time dreaming up ways to make things complex.  It is a frickin' hobby folks and no more complex than pushing a dang button.   Of course, I know many hams have difficulty in doing just that and thus expect the software developers to do it for them.   Grrrrrrr!!!!!

Bob, K4TAX


Gary - AG0N
 

On Oct 4, 2021, at 15:02, Bob McGraw - K4TAX <rmcgraw@benlomand.net> wrote:

So what is so important about VFO B? Doesn't VFO A have the same capability? If so, then that which is so important on VFO A can be done on VFO B. Just let the software do its job and learn to use it as designed.
One of the reasons I don’t run rig-split, is because I use VFO-B for other things, and casual operation on VFO-A. Fake it, keeps it this way and I never have to question what is going on with the VFOs.

I could be wrong, but I believe it was DESIGNED to work with both VFOs, but a change was made to, at least temporarily, get around the problem by always using VFO-A as “master”. If i’m wrong about that, fine, but that’s how I thought it was. As I said, it isn’t a problem for me because I don’t use rig-split.

Gary - AG0N


Jim Brown
 

On 10/4/2021 2:18 PM, Gary - AG0N wrote:
One of the reasons I don’t run rig-split, is because I use VFO-B for other things, and casual operation on VFO-A. Fake it, keeps it this way and I never have to question what is going on with the VFOs.
I do the same, because I work lots of CW and RTTY contests. With rig-split it would leave the radio (a K3) when I quit FT8, which is a PITA.

73, Jim K9YC


Sam Birnbaum
 

Hi Gary,

Using Split = Rig is more efficient as the program does not need to issue any 
commands associated with shifting the frequency and then waiting for the 
confirmation every time you switch from RX to TX and then back.
On rigs that do have 2 VFOs and using Spilt = Rig, the TX VFO frequency 
is set the second the offset for TX is set. That is done once and there are 
no more commands required to be issued when the program switches from 
RX to TX and back.  Just a point of information. 
 
73,
  
Sam W2JDB



-----Original Message-----
From: Gary - AG0N <wb0kkm@...>
To: main@wsjtx.groups.io <main@WSJTX.groups.io>
Sent: Mon, Oct 4, 2021 5:18 pm
Subject: Re: [WSJTX] Rig forced to VFO A by WSJT-X #Windows 10 #WSJT-X_Config #Cat_RigControl



> On Oct 4, 2021, at 15:02, Bob McGraw - K4TAX <rmcgraw@...> wrote:
>
> So what is so important about VFO B?  Doesn't VFO A have the same capability?  If so, then that which is so important on VFO A can be done on VFO B.  Just let the software do its job and learn to use it as designed. 


One of the reasons I don’t run rig-split, is because I use VFO-B for other things, and casual operation on VFO-A.  Fake it, keeps it this way and I never have to question what is going on with the VFOs.

I could be wrong, but I believe it was DESIGNED to work with both VFOs, but a change was made to, at least temporarily, get around the problem by always using VFO-A as “master”.  If i’m wrong about that, fine, but that’s how I thought it was.  As I said, it isn’t a problem for me because I don’t use rig-split.

Gary - AG0N





Bill Somerville
 

Hi Sam,

WSJT-X takes the view that the rig may have been changed directly, because of that the CAT commands to prepare for Tx, or after returning to Rx, are sent every time. That means that roughly the same amount of CAT traffic is exchanged in either Rig split mode or in Fake It split mode.

What is far more important is the lack of timing constraints when using SPLIT mode on the rig. Several rigs respond differently to CAT commands when in SEND mode, this can cause ambiguity if we do not know exactly when the rig switches from Rx to Tx and back. This happens when using VOX, or external PTT for sequencing pre-amps and amplifiers, when WSJT-X cannot know exactly when the rig switches from Rx to Tx and back. Using SPLIT mode there is no ambiguity since the Rx and Tx VFOs are set independently of Tx/Rx switching timing.

73
Bill
G4WJS.

On 05/10/2021 02:58, Sam Birnbaum via groups.io wrote:
Hi Gary,

Using Split = Rig is more efficient as the program does not need to issue any 
commands associated with shifting the frequency and then waiting for the 
confirmation every time you switch from RX to TX and then back.
On rigs that do have 2 VFOs and using Spilt = Rig, the TX VFO frequency 
is set the second the offset for TX is set. That is done once and there are 
no more commands required to be issued when the program switches from 
RX to TX and back.  Just a point of information. 
 
73,
  
Sam W2JDB



-----Original Message-----
From: Gary - AG0N <wb0kkm@...>
To: main@wsjtx.groups.io <main@WSJTX.groups.io>
Sent: Mon, Oct 4, 2021 5:18 pm
Subject: Re: [WSJTX] Rig forced to VFO A by WSJT-X #Windows 10 #WSJT-X_Config #Cat_RigControl



> On Oct 4, 2021, at 15:02, Bob McGraw - K4TAX <rmcgraw@...> wrote:
>
> So what is so important about VFO B?  Doesn't VFO A have the same capability?  If so, then that which is so important on VFO A can be done on VFO B.  Just let the software do its job and learn to use it as designed. 


One of the reasons I don’t run rig-split, is because I use VFO-B for other things, and casual operation on VFO-A.  Fake it, keeps it this way and I never have to question what is going on with the VFOs.

I could be wrong, but I believe it was DESIGNED to work with both VFOs, but a change was made to, at least temporarily, get around the problem by always using VFO-A as “master”.  If i’m wrong about that, fine, but that’s how I thought it was.  As I said, it isn’t a problem for me because I don’t use rig-split.

Gary - AG0N



Sam Birnbaum
 

Hi Bill,

Thank you for explanation. I would not have thought of that as I know that as soon as I change the 
TX offset in WSJT-X, the TS590s  VFO-B TX frequency shifts immediately. That happens without 
any TX taking place.  I never checked out that scenario where I changed VFO-B after you already 
issued the commands to shift it after the original TX Offset was selected.  

I already knew about the timing constraints as that was very well explained by you in one of the very 
early  email threads as well as by my experience writing custom code for tracking/controlling various 
rigs that I and/or friends own.

Thank you again for the explanation and for me anyway, additional knowledge regarding WSJT-X.

Thanks the work/effort you and the rest of the team have put into this product.

If down the road the team has the time and/or inclination to enhance UDP Message #15 by adding 
the TX offset field, it would greatly enhance/simplify the function I use for the blind hams when selecting 
the open slot in the band pass and/or shifting it programmatically.  

73,
 
Sam W2JDB



-----Original Message-----
From: Bill Somerville <g4wjs@...>
To: main@WSJTX.groups.io; wb0kkm@... <wb0kkm@...>
Sent: Tue, Oct 5, 2021 3:39 am
Subject: Re: [WSJTX] Rig forced to VFO A by WSJT-X #Windows 10 #WSJT-X_Config #Cat_RigControl

Hi Sam,

WSJT-X takes the view that the rig may have been changed directly, because of that the CAT commands to prepare for Tx, or after returning to Rx, are sent every time. That means that roughly the same amount of CAT traffic is exchanged in either Rig split mode or in Fake It split mode.

What is far more important is the lack of timing constraints when using SPLIT mode on the rig. Several rigs respond differently to CAT commands when in SEND mode, this can cause ambiguity if we do not know exactly when the rig switches from Rx to Tx and back. This happens when using VOX, or external PTT for sequencing pre-amps and amplifiers, when WSJT-X cannot know exactly when the rig switches from Rx to Tx and back. Using SPLIT mode there is no ambiguity since the Rx and Tx VFOs are set independently of Tx/Rx switching timing.

73
Bill
G4WJS.

On 05/10/2021 02:58, Sam Birnbaum via groups.io wrote:
Hi Gary,

Using Split = Rig is more efficient as the program does not need to issue any 
commands associated with shifting the frequency and then waiting for the 
confirmation every time you switch from RX to TX and then back.
On rigs that do have 2 VFOs and using Spilt = Rig, the TX VFO frequency 
is set the second the offset for TX is set. That is done once and there are 
no more commands required to be issued when the program switches from 
RX to TX and back.  Just a point of information. 
 
73,
  
Sam W2JDB



-----Original Message-----
From: Gary - AG0N <wb0kkm@...>
To: main@wsjtx.groups.io <main@WSJTX.groups.io>
Sent: Mon, Oct 4, 2021 5:18 pm
Subject: Re: [WSJTX] Rig forced to VFO A by WSJT-X #Windows 10 #WSJT-X_Config #Cat_RigControl



> On Oct 4, 2021, at 15:02, Bob McGraw - K4TAX <rmcgraw@...> wrote:
>
> So what is so important about VFO B?  Doesn't VFO A have the same capability?  If so, then that which is so important on VFO A can be done on VFO B.  Just let the software do its job and learn to use it as designed. 


One of the reasons I don’t run rig-split, is because I use VFO-B for other things, and casual operation on VFO-A.  Fake it, keeps it this way and I never have to question what is going on with the VFOs.

I could be wrong, but I believe it was DESIGNED to work with both VFOs, but a change was made to, at least temporarily, get around the problem by always using VFO-A as “master”.  If i’m wrong about that, fine, but that’s how I thought it was.  As I said, it isn’t a problem for me because I don’t use rig-split.

Gary - AG0N





Bob McGraw - K4TAX
 

I use FAKE IT as the configuration VFO mode for WSJT-X.  Regardless of the radio mode, the radio is in or configured, when I open WSJT-X it connects to the radio and defaults to VFO A as the TX and RX VFO.  If I change WSJT-X to RIG SPLIT then VFO A is the RX selection and VFO B is the TX selection.  Seems the choice of the user will allow the radio to use one VFO or both VFO's.    I also find this configuration works for both of my radios, Elecraft K3S and Tentec Eagle.  

Bob, K4TAX


Carl - WC4H
 

I'm with you on this Bob.  Much ado about very little.  Goodness, we can't change the mode from USB-D or DATA-U or whatever to RTTY? 

As far as I can tell, if I use Winwarbler, FLdigi, DM780 or other program for RTTY, I can change the radio mode from the program.  This works with DXlab Commander, FLrig and HRD respectively.  

So, by setting up the radio control program and the RTTY program, one does not even have to change the mode on the radio manually.

73.

Carl - WC4H


Paul Taylor
 

Hi Mike, any updates on this? It will be good to go back to how it was when WSJT-X didn't tinker with my settings by switching to VFO A all the time.

To paraphrase Bob McGraw, one might say "what is so important about VFO A?" I definitely would like to be able to keep all my digital work on VFO B, which is also where I have my filtering set differently on the rig, although I can live with it for now if it's a temporary thing.

Paul


Bill Somerville
 

On 18/10/2021 10:51, Paul Taylor wrote:
Hi Mike, any updates on this? It will be good to go back to how it was when WSJT-X didn't tinker with my settings by switching to VFO A all the time.

To paraphrase Bob McGraw, one might say "what is so important about VFO A?" I definitely would like to be able to keep all my digital work on VFO B, which is also where I have my filtering set differently on the rig, although I can live with it for now if it's a temporary thing.

Paul
Hi Paul,

I am informed this has been repaired. If you are running on MS Windows you can try the latest snapshot build of Hamlib from the Hamlib team. Download the appropriate binary snapshot from here:

http://n0nb.users.sourceforge.net/

you need the .ZIP archive for you platform (32-bit or 64-bit WSJT-X installation), extract the libhamlib-4.dll library from it (in the bin sub-directory) and replace the file with the same name in your WSJT-X installation (C:\WSJT\wsjtx\bin\ is the default location).

Let us know how it goes please?

73
Bill
G4WJS.


Michael Black
 

Download the 32 or 64-bit zip file or exe and replace the libhamlib-4.dll in WSJT-X from the packge.
The VFOA problem has been fixed.


Mike W9MDB




On Monday, October 18, 2021, 04:53:40 AM CDT, Paul Taylor <poglad@...> wrote:


Hi Mike, any updates on this? It will be good to go back to how it was when WSJT-X didn't tinker with my settings by switching to VFO A all the time.

To paraphrase Bob McGraw, one might say "what is so important about VFO A?" I definitely would like to be able to keep all my digital work on VFO B, which is also where I have my filtering set differently on the rig, although I can live with it for now if it's a temporary thing.

Paul




Paul Taylor
 

Superb news, thanks Mike and Bill!


On Mon, 18 Oct 2021, 11:04 Michael Black via groups.io, <mdblack98=yahoo.com@groups.io> wrote:
Download the 32 or 64-bit zip file or exe and replace the libhamlib-4.dll in WSJT-X from the packge.
The VFOA problem has been fixed.


Mike W9MDB




On Monday, October 18, 2021, 04:53:40 AM CDT, Paul Taylor <poglad@...> wrote:


Hi Mike, any updates on this? It will be good to go back to how it was when WSJT-X didn't tinker with my settings by switching to VFO A all the time.

To paraphrase Bob McGraw, one might say "what is so important about VFO A?" I definitely would like to be able to keep all my digital work on VFO B, which is also where I have my filtering set differently on the rig, although I can live with it for now if it's a temporary thing.

Paul