Re: [wsjt-devel] WSJT-x 2.5.2 Bug

2021-11-13 Thread Al Pawlowski via wsjt-devel 
Saw post where Mike gave URL for new “libhamlib.dll”. Copied to the WSJT-x bin 
folder to replace older dll and if fixed the ANR switch to off problem I was 
seeing. Everything else I have tested in 2.5.2 now seems to work normally. 
Using Win10 Home-64.

2.5.2 installed dll create date 11/03/2021. Replacement dll create date 
11/12/2021.

> Begin forwarded message:
> 
> From: Al Pawlowski 
> Subject: Re: wsjt-devel Digest, Vol 93, Issue 25
> Date: November 11, 2021 at 07:50:03 PST
> To: WSJT software development 
> 
> The VAC sound problem seems to be gone now - been working for two days fine. 
> The ANF to off problem is the same - BTW, when I wrote switching, I meant it 
> goes to off when on transmit and stays there until manually set back to on.
> 
> I just switched back to 2.5.1 and the ANF -> off problem does not occur - 
> does appear to be a 2.5.2 (maybe CAT hamlib) problem. Of course, now I have 
> the main window not remembering its previous size problem, which is fixed in 
> 2.5.2 - for me at least.
> 
>> Date: Tue, 9 Nov 2021 14:43:53 -0800
>> From: Al Pawlowski mailto:k6...@almont.com>>
>> To: WSJT software development > >
>> Subject: Re: [wsjt-devel] WSJT-x 2.5.2 Bug
>> Message-ID: > >
>> Content-Type: text/plain;charset=us-ascii
>> 
>> Recently noticed that WSJTx GA 2.5.2 Win64 will switch my HPSDR Thetis 
>> v2.8.11 ANF button to off when WSJTx does a transmit. I had not seen this on 
>> 2.5.1 or earlier versions of WSJT-x and have been using Thetis 2.8.11 for 
>> quite awhile. I run Win10 Home 64bit with auto updates on. ANF is pretty 
>> useful on digital modes so this is kind of an annoying problem. Maybe an 
>> unintended change in the CAT lib working for PowerSDR.
>> 
>> I normally run with the WSJT-x radio split operation set to Rig. If I set it 
>> to Fake It, the ANF function switching stops, turn it back to Rig and it 
>> starts switching ANF on xmit again - very repeatable.
>> 
>> I also had WSJTx 2.5.2 fail to connect to my VAC rx sound channel. I updated 
>> my VAC drivers to current version (4.66) from 4.64 and played with the 
>> windows sound device settings some and this problem seems to have gone away. 
>> I did not change any sound device settings when upgrading from WSJTx 2.5.1 
>> which was working fine. It did not seem to me the VAC update is what fixed 
>> the problem, more like me playing with the sound device properties. Seems 
>> like there has been a WSJTx 2.5.2 sound changed or a Win update got me. 
>> Hopefully, this problem will stay fixed.
> 

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] VFOs reversing

2021-11-13 Thread Sam W2JDB via wsjt-devel 
 Hi Bill, 
Thank you forpointing me to the Hamlib documentation, and yes, I do understand 
thatthe Hamlib library removes the requirements of knowing the exactcommands 
needed to control any rig that Hamlib supports. 
 While I have onlydone a cursory read through, I believe I did find the 
function calls that WSJT-X might be calling when "Split=Rig" is specified as it 
changesfrom RX to TX with the possibility of the need to change the TX offset.
In any event, Icertainly was not trying to tell you to re-engineer your code, 
just apotential workaround based on my experience of writing my own code 
totrack/control various rigs with different capabilities. My apologies if it 
was taken the wrongway.
As always, thank youagain for all your previous help and support.
73,
Sam W2JDB


-Original Message-
From: Bill Somerville via wsjt-devel 
To: wsjt-devel@lists.sourceforge.net
Cc: Bill Somerville 
Sent: Sat, Nov 13, 2021 5:11 am
Subject: Re: [wsjt-devel] VFOs reversing

Sam,

WADR before you suggest re-engineering the way WSJT-X controls rigs via 
Hamlib I think you should take some time to review the Hamlib library 
API. Note that the client API does not require client applications to 
know what rig is being controlled or to issue low level CAT commands.

https://github.com/Hamlib/Hamlib/wiki/Documentation

73
Bill
G4WJS.


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] VFOs reversing

2021-11-13 Thread Black Michael via wsjt-devel 
Moreover most rigs with targetable frequency do not have a "set freq on current 
VFO"newer Icom's are an exception to that.Rigs that do NOT have targetable 
frequency only have that (a lot of older rigs).
So the idea of doing the vfo swapping works non-targetable rigs but not 
targetable ones.
Hamlib supports 254 rigs now and I'm seeing more edge cases of behaviors partly 
due to speed ups in the serial I/O.  Knob twiddling has been a problem for a 
long time when users start twiddling knobs.The only knob twiddling I really 
care about supporting is for satellite doppler work since that is computer 
controlled and critical to operations.Other cases get support if possible but 
generally at lower priority.
Currently hamlib just reports whatever the rig claims is the current VFO and in 
some cases a simulated answer and I'm not inclined to overrule the rig answer 
but provide a better VFO method to start using RX/TX VFO options instead of 
VFOA/B and Main/Sub.
Mike W9MDB

 

On Saturday, November 13, 2021, 04:15:54 AM CST, Bill Somerville via 
wsjt-devel  wrote:  
 
 Sam,

WADR before you suggest re-engineering the way WSJT-X controls rigs via 
Hamlib I think you should take some time to review the Hamlib library 
API. Note that the client API does not require client applications to 
know what rig is being controlled or to issue low level CAT commands.

https://github.com/Hamlib/Hamlib/wiki/Documentation

73
Bill
G4WJS.

On 12/11/2021 23:11, Sam W2JDB via wsjt-devel wrote:
> Hi,
>
> The problem that I can see cropping up is that on some rigs you can not
> change the frequency of the Sub VFO until it becomes the Main VFO when
> the rig status changes to TX.
>
> You (WSJT-X) might be able to use a workaround by issuing a swap
> VFO command change the TX frequency (if needed) on the new
> Main VFO and then issue another swap VFO command.
>
> At this point you can start the TX process and let rig then takes care
> of the correct VFO swap. Mike will not need any convoluted code to
> track which is the Main VFO or Sub VFO.
>
> Just my two cents on this problem.
>
> 73,
>
> Sam W2JDB
>
>
>
> -Original Message-
> From: Bill Somerville via wsjt-devel 
> To: wsjt-devel@lists.sourceforge.net
> Cc: Bill Somerville 
> Sent: Fri, Nov 12, 2021 4:56 pm
> Subject: Re: [wsjt-devel] VFOs reversing
>
> On 12/11/2021 18:09, Black Michael via wsjt-devel wrote:
> > This is on an Elecraft K4.
> > When transmitting in split mode VFOA=Rx and VFOB=Tx and one changes
> > the Tx frequency WSJT-X assumes since VFOB is the current VFO that it
> > reverses roles and sets VFOA frequency instead.
> > If VFOB is active and split and ptt=on then VFOB is still tx.  I
> > really don't know if this applies to all rigs though.
> >
> > Mike W9MDB
>
> Mike,
>
> to deal with that sort of behaviour either all rigs must do the same
> thing or WSJT-X will have to determine the rig and decide if the current
> VFO changes (as reported by Hamlib) when transmitting split on a rig by
> rig basis. Given that a number of rigs cannot be queried for the current
> VFO I would think that the best option for Hamlib is not to change the
> current VFO when transmitting split.
>
> 73
> Bill
> G4WJS.




___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
  ___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] VFOs reversing

2021-11-13 Thread Bill Somerville via wsjt-devel 

Sam,

WADR before you suggest re-engineering the way WSJT-X controls rigs via 
Hamlib I think you should take some time to review the Hamlib library 
API. Note that the client API does not require client applications to 
know what rig is being controlled or to issue low level CAT commands.


https://github.com/Hamlib/Hamlib/wiki/Documentation

73
Bill
G4WJS.

On 12/11/2021 23:11, Sam W2JDB via wsjt-devel wrote:

Hi,

The problem that I can see cropping up is that on some rigs you can not
change the frequency of the Sub VFO until it becomes the Main VFO when
the rig status changes to TX.

You (WSJT-X) might be able to use a workaround by issuing a swap
VFO command change the TX frequency (if needed) on the new
Main VFO and then issue another swap VFO command.

At this point you can start the TX process and let rig then takes care
of the correct VFO swap. Mike will not need any convoluted code to
track which is the Main VFO or Sub VFO.

Just my two cents on this problem.

73,

Sam W2JDB



-Original Message-
From: Bill Somerville via wsjt-devel 
To: wsjt-devel@lists.sourceforge.net
Cc: Bill Somerville 
Sent: Fri, Nov 12, 2021 4:56 pm
Subject: Re: [wsjt-devel] VFOs reversing

On 12/11/2021 18:09, Black Michael via wsjt-devel wrote:
> This is on an Elecraft K4.
> When transmitting in split mode VFOA=Rx and VFOB=Tx and one changes
> the Tx frequency WSJT-X assumes since VFOB is the current VFO that it
> reverses roles and sets VFOA frequency instead.
> If VFOB is active and split and ptt=on then VFOB is still tx.  I
> really don't know if this applies to all rigs though.
>
> Mike W9MDB

Mike,

to deal with that sort of behaviour either all rigs must do the same
thing or WSJT-X will have to determine the rig and decide if the current
VFO changes (as reported by Hamlib) when transmitting split on a rig by
rig basis. Given that a number of rigs cannot be queried for the current
VFO I would think that the best option for Hamlib is not to change the
current VFO when transmitting split.

73
Bill
G4WJS.





___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel