Re: [wsjt-devel] Hamlib 4.0 error with rigctld/IC706: Invalid parameter while exchanging VFOs

[Black Michael via wsjt-devel]

I found the problem with rigctld -- that's been there forever.so should 
have been failing on any rig where set_vfo==NULLSee the latest comment 
herehttps://github.com/Hamlib/Hamlib/issues/490

I have some tests to run today and should posting the fix today.
Mike W9MDB

 

On Thursday, January 7, 2021, 05:32:42 PM CST, Black Michael 
 wrote:  
 
 Not completely fixed yet
Turns out that was just one part...working now with an IC706 user and we got 
the mode change working now but rigctld isn't working with wsjtx.
But I also need to test this change on another Icom rig tomorrow (IC-7300) to 
ensure it works correctly before committing it,.
Mike W9MDB
 

On Thursday, January 7, 2021, 05:24:51 PM CST, Bill Somerville 
 wrote:  
 
  On 07/01/2021 20:13, Christoph Berg wrote:
  
  Re: Patrick 9A5CW
 
 have the same problem.
If i start the radio in USB mode, manually i change with a button on the
radio IC706mk2 mode to CW, then i go back into WSJT-X i
chose a freq from the dropdown menu list, radio is trying to switch to that
selected frequency but can't do it.
 
 I have the same problem here. If IC706 is in CW mode, wsjtx fails to
change the mode, and will even refuse to key PTT via the attached
usb-serial dongle. Changing bands via wsjtx works somewhat, but the
rig stays on CW, and the dreaded "Rig Control Error" popup appears.

Log of "Test CAT" and the failing "Test PTT" attached. (IC706 directly
attached without rigctld.)

Christoph
  
 
Hi Christoph,
 
this is a known issue with Hamlib 4.0, it is not able to set the rig mode for 
some of the older Icom rigs. You can work around it in WSJT-X by checking 
"Settings->Radio->Mode->None". The issue is fixed in the Hamlib master branch 
by commit 02c08544.
 
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] Hamlib 4.0 error with rigctld/IC706: Invalid parameter while exchanging VFOs

[Black Michael via wsjt-devel]

Not completely fixed yet
Turns out that was just one part...working now with an IC706 user and we got 
the mode change working now but rigctld isn't working with wsjtx.
But I also need to test this change on another Icom rig tomorrow (IC-7300) to 
ensure it works correctly before committing it,.
Mike W9MDB
 

On Thursday, January 7, 2021, 05:24:51 PM CST, Bill Somerville 
 wrote:  
 
  On 07/01/2021 20:13, Christoph Berg wrote:
  
  Re: Patrick 9A5CW
 
 have the same problem.
If i start the radio in USB mode, manually i change with a button on the
radio IC706mk2 mode to CW, then i go back into WSJT-X i
chose a freq from the dropdown menu list, radio is trying to switch to that
selected frequency but can't do it.
 
 I have the same problem here. If IC706 is in CW mode, wsjtx fails to
change the mode, and will even refuse to key PTT via the attached
usb-serial dongle. Changing bands via wsjtx works somewhat, but the
rig stays on CW, and the dreaded "Rig Control Error" popup appears.

Log of "Test CAT" and the failing "Test PTT" attached. (IC706 directly
attached without rigctld.)

Christoph
  
 
Hi Christoph,
 
this is a known issue with Hamlib 4.0, it is not able to set the rig mode for 
some of the older Icom rigs. You can work around it in WSJT-X by checking 
"Settings->Radio->Mode->None". The issue is fixed in the Hamlib master branch 
by commit 02c08544.
 
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] Hamlib 4.0 error with rigctld/IC706: Invalid parameter while exchanging VFOs

[Bill Somerville]

On 07/01/2021 20:13, Christoph Berg wrote:

Re: Patrick 9A5CW

have the same problem.
If i start the radio in USB mode, manually i change with a button on the
radio IC706mk2 mode to CW, then i go back into WSJT-X i
chose a freq from the dropdown menu list, radio is trying to switch to that
selected frequency but can't do it.

I have the same problem here. If IC706 is in CW mode, wsjtx fails to
change the mode, and will even refuse to key PTT via the attached
usb-serial dongle. Changing bands via wsjtx works somewhat, but the
rig stays on CW, and the dreaded "Rig Control Error" popup appears.

Log of "Test CAT" and the failing "Test PTT" attached. (IC706 directly
attached without rigctld.)

Christoph


Hi Christoph,

this is a known issue with Hamlib 4.0, it is not able to set the rig 
mode for some of the older Icom rigs. You can work around it in WSJT-X 
by checking "Settings->Radio->Mode->None". The issue is fixed in the 
Hamlib master branch by commit 02c08544.


73
Bill
G4WJS.

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

Re: [wsjt-devel] Hamlib 4.0 error with rigctld/IC706: Invalid parameter while exchanging VFOs

[Christoph Berg]

Re: Black Michael via wsjt-devel
> I'd like to hook up with you and debug this.
> Do you do Skype?  We can use "Quick Assist" if you are on Windows 10.

I apparently haven't mentioned Debian often enough ;)

Jitsi works quite well, but unfortunately I have a Bridge sked in a
few minutes. Some time tomorrow or on the weekend?

Christoph


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

Re: [wsjt-devel] Hamlib 4.0 error with rigctld/IC706: Invalid parameter while exchanging VFOs

[Black Michael via wsjt-devel]

I'd like to hook up with you and debug this.
Do you do Skype?  We can use "Quick Assist" if you are on Windows 10.
Mike

 

On Thursday, January 7, 2021, 02:17:22 PM CST, Christoph Berg 
 wrote:  
 
 Re: Patrick 9A5CW
> have the same problem.
> If i start the radio in USB mode, manually i change with a button on the
> radio IC706mk2 mode to CW, then i go back into WSJT-X i
> chose a freq from the dropdown menu list, radio is trying to switch to that
> selected frequency but can't do it.

I have the same problem here. If IC706 is in CW mode, wsjtx fails to
change the mode, and will even refuse to key PTT via the attached
usb-serial dongle. Changing bands via wsjtx works somewhat, but the
rig stays on CW, and the dreaded "Rig Control Error" popup appears.

Log of "Test CAT" and the failing "Test PTT" attached. (IC706 directly
attached without rigctld.)

Christoph
___
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] Hamlib 4.0 error with rigctld/IC706: Invalid parameter while exchanging VFOs

[Patrick 9A5CW]

Hi Christoph,
Yes the same behaviour noted here, if you disable USB mode in the WSJT-X
radio settings all works ok, except no more USB is automaticaly selected.
Must be something wrong related to USB mode switching or so.
Hope to solve the problem with Mike in next few days.

Best regards,
Patrik 9a5cw

čet, 7. sij 2021. 21:17 Christoph Berg  je napisao:

> Re: Patrick 9A5CW
> > have the same problem.
> > If i start the radio in USB mode, manually i change with a button on the
> > radio IC706mk2 mode to CW, then i go back into WSJT-X i
> > chose a freq from the dropdown menu list, radio is trying to switch to
> that
> > selected frequency but can't do it.
>
> I have the same problem here. If IC706 is in CW mode, wsjtx fails to
> change the mode, and will even refuse to key PTT via the attached
> usb-serial dongle. Changing bands via wsjtx works somewhat, but the
> rig stays on CW, and the dreaded "Rig Control Error" popup appears.
>
> Log of "Test CAT" and the failing "Test PTT" attached. (IC706 directly
> attached without rigctld.)
>
> Christoph
> ___
> 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] Hamlib 4.0 error with rigctld/IC706: Invalid parameter while exchanging VFOs

[Christoph Berg]

Re: Patrick 9A5CW
> have the same problem.
> If i start the radio in USB mode, manually i change with a button on the
> radio IC706mk2 mode to CW, then i go back into WSJT-X i
> chose a freq from the dropdown menu list, radio is trying to switch to that
> selected frequency but can't do it.

I have the same problem here. If IC706 is in CW mode, wsjtx fails to
change the mode, and will even refuse to key PTT via the attached
usb-serial dongle. Changing bands via wsjtx works somewhat, but the
rig stays on CW, and the dreaded "Rig Control Error" popup appears.

Log of "Test CAT" and the failing "Test PTT" attached. (IC706 directly
attached without rigctld.)

Christoph


WSJT-X_RigControl-ic706-cw.log.gz
Description: application/gzip
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Hamlib 4.0 error with rigctld/IC706: Invalid parameter while exchanging VFOs

[Christoph Berg]

Re: Bill Somerville
> > ... and the "Hamlib error: Invalid parameter while exchanging VFOs" popup.
> 
> Hi Christoph,
> 
> the rigctld trace doesn't show any errors. Please put the attached file into
> the local configuration directory ~/.config and run the test again then quit
> WSJT-X. It will generate a file ~/Desktop/WSJT-X_RigControl.log which will
> have trace info from the WSJT-X end.

The attached logfiles contain a test with IC706 directly connected,
and then via rigctld with the above error message.

Christoph


WSJT-X_RigControl-ic706.log.gz
Description: application/gzip


WSJT-X_RigControl-rigctld.log.gz
Description: application/gzip
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Hamlib 4.0 error with rigctld/IC706: Invalid parameter while exchanging VFOs

[Black Michael via wsjt-devel]

If that's an MKII then you should be using "-m 3010"
rigctl -l | grep 706  3009  Icom                   IC-706                  
20201219.0      Stable      RIG_MODEL_IC706  3010  Icom                   
IC-706MkII              20201219.0      Stable      RIG_MODEL_IC706MKII  3011  
Icom                   IC-706MkIIG             20201219.0      Stable      
RIG_MODEL_IC706MKIIG


Mike W9MDB

 

On Wednesday, January 6, 2021, 03:38:10 PM CST, Patrick 9A5CW 
 wrote:  
 
 Hi Bill,it looks like i does work, if i turn  the VFO up down i can see that 
frequency change in the WSJT-X main screen.Only problem is when i change the 
mode manually on the radio and i try to come back on working frequency with 
WSJT-X by selectingthat frequency in the drop down menu i can't do - radio is 
trying switching something but can't change the mode.
Using homebrew MC1489 UART Chip as a level converter, all others logging / 
contest programs working fine.Michael said that i am losing packets... but 
never noted b4 that i lose communication with my radio. I can try to make a new 
CiV interface withMAX232 but that will not solve the problem. (i believe so).
73, Patrik 9A5CW

On Wed, Jan 6, 2021 at 10:25 PM Bill Somerville  wrote:

  Hi Patrick, 
  that's a different rig, an IC-706MkIIG. There are no responses from your rig, 
is your CI-V interface working correctly? 
  73
 Bill
 G4WJS. 
  On 06/01/2021 21:13, Patrick 9A5CW wrote:
  
  Hi all, have the same problem. If i start the radio in USB mode, manually i 
change with a button on the radio IC706mk2 mode to CW, then i go back into 
WSJT-X i 
  chose a freq from the dropdown menu list, radio is trying to switch to that 
selected frequency but can't do it. Already spoke with Michael about that 
problem but so far no results. All Hamlib versions after 12.12.2020 or so have 
something wrong with IC706mk2 settings. (Using also JTDX - same problem). Echo 
is disabled in the radio menu, speed is set to 4800. 
  debug.txt in the attachment
  
  Best regards, 73 Patrik 9A5CW
  
  
   
  On Wed, Jan 6, 2021 at 9:27 PM Christoph Berg  wrote:
  
Re: Black Michael via wsjt-devel
 > So if you do an "ldd" on the executables they all point to the same 
 > libhamlib ?
 
 $ ldd /usr/bin/wsjtx | grep hamlib
         libhamlib.so.4 => /lib/x86_64-linux-gnu/libhamlib.so.4 
(0x7f556f2a)
 $ ldd /usr/bin/rigctl* | grep hamlib
         libhamlib.so.4 => /lib/x86_64-linux-gnu/libhamlib.so.4 
(0x7f54323ba000)
         libhamlib.so.4 => /lib/x86_64-linux-gnu/libhamlib.so.4 
(0x7f348d105000)
         libhamlib.so.4 => /lib/x86_64-linux-gnu/libhamlib.so.4 
(0x7ffa08c89000)
 
 > If that's true please provide some debug info from rigctld so we can see the 
 > problem.  What I suspect you'll see is it's asking for "VFO_SUB" which is 
 > the behavior we've seen with the problemthat's the common problem with 
 > the structure realignment. 
 
 $ /usr/bin/rigctld -m 3009 -r /dev/ttyUSBICOM -p /dev/ttyUSBPTT -v
 Recommend using --vfo switch for rigctld if client supports it
 rigctl and netrigctl will automatically detect vfo mode
 rigctld Hamlib 4.0
 Last commit was Sa Jan 02 00:47:50 2021 + SHA=5f4cc3
 Report bugs to 
 
 rig_init called
 initrigs4_icom: _init called
 rig_register called
 rig_register: rig_register (3055)
 rig_register called
 rig_register: rig_register (3085)
 rig_register called
 rig_register: rig_register (3009)
 rig_register called
 rig_register: rig_register (3010)
 rig_register called
 [...]
 rig_register called
 rig_register: rig_register (3076)
 icom_init called
 icom_init: done
 main: twiddle=0, uplink=0
 rig_open called
 port_open called
 serial_open called
 serial_setup called
 serial_setup: tcgetattr
 serial_setup: cfmakeraw
 serial_setup: cfsetispeed=19200,0x000e
 serial_setup: cfsetospeed=19200,0x000e
 serial_setup: data_bits=8
 serial_setup: parity=0
 serial_setup: tcsetattr TCSANOW
 serial_flush called
 tcflush
 icom_rig_open 757
 icom_rig_open: IC-706 v20201219.0
 icom_get_usb_echo_off called
 icom_get_usb_echo_off: retry temp set to 1
 icom_transaction: cmd=0x03, subcmd=0x, payload_len=0, data_len=80
 rig_flush: called for serial device
 serial_flush called
 tcflush
 write_block called
 write_block(): TX 6 bytes
     fe fe 48 e0 03 fd                                   ..H...
 read_string called, rxmax=80
 read_string(): RX 6 characters
     fe fe 48 e0 03 fd                                   ..H...
 read_string called, rxmax=80
 read_string(): RX 11 characters
     fe fe e0 48 03 00 70 35 05 00 fd                    ...H..p5...
 icom_get_usb_echo_off: ack_len=6
 icom_get_usb_echo_off: USB echo on detected
 rig_get_vfo called
 rig_get_vfo: no get_vfo
 rig_open: Icom rig so default vfo = currVFO
 Opened rig model 3009, 'IC-706'
 Backend version: 20201219.0, Status: Stable
 main: Using IPV4
 
 ... clicking on "Test CAT" in wsjtx 2.3.0~rc3:
 
 Connection opened from localhost:54898
 sync_callback: client lock engaged
 

Re: [wsjt-devel] Hamlib 4.0 error with rigctld/IC706: Invalid parameter while exchanging VFOs

[Patrick 9A5CW]

Hi Bill,
it looks like i does work, if i turn  the VFO up down i can see that
frequency change in the WSJT-X main screen.
Only problem is when i change the mode manually on the radio and i try to
come back on working frequency with WSJT-X by selecting
that frequency in the drop down menu i can't do - radio is trying switching
something but can't change the mode.
Using homebrew MC1489 UART Chip as a level converter, all others logging /
contest programs working fine.
Michael said that i am losing packets... but never noted b4 that i lose
communication with my radio. I can try to make a new CiV interface with
MAX232 but that will not solve the problem. (i believe so).

73, Patrik 9A5CW

On Wed, Jan 6, 2021 at 10:25 PM Bill Somerville 
wrote:

> Hi Patrick,
>
> that's a different rig, an IC-706MkIIG. There are no responses from your
> rig, is your CI-V interface working correctly?
>
> 73
> Bill
> G4WJS.
>
> On 06/01/2021 21:13, Patrick 9A5CW wrote:
>
> Hi all,
> have the same problem.
> If i start the radio in USB mode, manually i change with a button on the
> radio IC706mk2 mode to CW, then i go back into WSJT-X i
> chose a freq from the dropdown menu list, radio is trying to switch to
> that selected frequency but can't do it.
> Already spoke with Michael about that problem but so far no results. All
> Hamlib versions after 12.12.2020 or so have something wrong with IC706mk2
> settings. (Using also JTDX - same problem). Echo is disabled in the radio
> menu, speed is set to 4800.
>
> debug.txt in the attachment
>
> Best regards,
> 73 Patrik 9A5CW
>
>
>
> On Wed, Jan 6, 2021 at 9:27 PM Christoph Berg  wrote:
>
>> Re: Black Michael via wsjt-devel
>> > So if you do an "ldd" on the executables they all point to the same
>> libhamlib ?
>>
>> $ ldd /usr/bin/wsjtx | grep hamlib
>> libhamlib.so.4 => /lib/x86_64-linux-gnu/libhamlib.so.4
>> (0x7f556f2a)
>> $ ldd /usr/bin/rigctl* | grep hamlib
>> libhamlib.so.4 => /lib/x86_64-linux-gnu/libhamlib.so.4
>> (0x7f54323ba000)
>> libhamlib.so.4 => /lib/x86_64-linux-gnu/libhamlib.so.4
>> (0x7f348d105000)
>> libhamlib.so.4 => /lib/x86_64-linux-gnu/libhamlib.so.4
>> (0x7ffa08c89000)
>>
>> > If that's true please provide some debug info from rigctld so we can
>> see the problem.  What I suspect you'll see is it's asking for "VFO_SUB"
>> which is the behavior we've seen with the problemthat's the common
>> problem with the structure realignment.
>>
>> $ /usr/bin/rigctld -m 3009 -r /dev/ttyUSBICOM -p /dev/ttyUSBPTT -v
>> Recommend using --vfo switch for rigctld if client supports it
>> rigctl and netrigctl will automatically detect vfo mode
>> rigctld Hamlib 4.0
>> Last commit was Sa Jan 02 00:47:50 2021 + SHA=5f4cc3
>> Report bugs to 
>>
>> rig_init called
>> initrigs4_icom: _init called
>> rig_register called
>> rig_register: rig_register (3055)
>> rig_register called
>> rig_register: rig_register (3085)
>> rig_register called
>> rig_register: rig_register (3009)
>> rig_register called
>> rig_register: rig_register (3010)
>> rig_register called
>> [...]
>> rig_register called
>> rig_register: rig_register (3076)
>> icom_init called
>> icom_init: done
>> main: twiddle=0, uplink=0
>> rig_open called
>> port_open called
>> serial_open called
>> serial_setup called
>> serial_setup: tcgetattr
>> serial_setup: cfmakeraw
>> serial_setup: cfsetispeed=19200,0x000e
>> serial_setup: cfsetospeed=19200,0x000e
>> serial_setup: data_bits=8
>> serial_setup: parity=0
>> serial_setup: tcsetattr TCSANOW
>> serial_flush called
>> tcflush
>> icom_rig_open 757
>> icom_rig_open: IC-706 v20201219.0
>> icom_get_usb_echo_off called
>> icom_get_usb_echo_off: retry temp set to 1
>> icom_transaction: cmd=0x03, subcmd=0x, payload_len=0, data_len=80
>> rig_flush: called for serial device
>> serial_flush called
>> tcflush
>> write_block called
>> write_block(): TX 6 bytes
>> fe fe 48 e0 03 fd   ..H...
>> read_string called, rxmax=80
>> read_string(): RX 6 characters
>> fe fe 48 e0 03 fd   ..H...
>> read_string called, rxmax=80
>> read_string(): RX 11 characters
>> fe fe e0 48 03 00 70 35 05 00 fd...H..p5...
>> icom_get_usb_echo_off: ack_len=6
>> icom_get_usb_echo_off: USB echo on detected
>> rig_get_vfo called
>> rig_get_vfo: no get_vfo
>> rig_open: Icom rig so default vfo = currVFO
>> Opened rig model 3009, 'IC-706'
>> Backend version: 20201219.0, Status: Stable
>> main: Using IPV4
>>
>> ... clicking on "Test CAT" in wsjtx 2.3.0~rc3:
>>
>> Connection opened from localhost:54898
>> sync_callback: client lock engaged
>> sync_callback: client lock disengaged
>> handle_socket: vfo_mode=0
>> rigctl_parse: called, interactive=1
>> rigctl_parse: cmd=\(5c)
>> rigctl_parse: cmd=chk_vfo
>> rigctl_parse: vfo_opt=0
>> rigctl_parse: debug1
>> rigctl_parse: debug5
>> rigctl_parse: debug10
>> sync_callback: client lock engaged
>> rigctl(d): ð 

Re: [wsjt-devel] Hamlib 4.0 error with rigctld/IC706: Invalid parameter while exchanging VFOs

[Bill Somerville]

Hi Patrick,

that's consistent with the rig not responding to commands from rigctld. 
Something is not working between your rig and PC. What is your CI-V 
interface? Does it need power?


73
Bill
G4WJS.

On 06/01/2021 21:20, Patrick 9A5CW wrote:

HI Bill,
my log file is in the attachment.

best 73
Patrik 9A5CW

On Wed, Jan 6, 2021 at 10:10 PM Bill Somerville > wrote:


On 06/01/2021 20:22, Christoph Berg wrote:
> ... and the "Hamlib error: Invalid parameter while exchanging
VFOs" popup.

Hi Christoph,

the rigctld trace doesn't show any errors. Please put the attached
file
into the local configuration directory ~/.config and run the test
again
then quit WSJT-X. It will generate a file
~/Desktop/WSJT-X_RigControl.log which will have trace info from the
WSJT-X end.

73
Bill
G4WJS.



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

Re: [wsjt-devel] Hamlib 4.0 error with rigctld/IC706: Invalid parameter while exchanging VFOs

[Bill Somerville]

Hi Patrick,

that's a different rig, an IC-706MkIIG. There are no responses from your 
rig, is your CI-V interface working correctly?


73
Bill
G4WJS.

On 06/01/2021 21:13, Patrick 9A5CW wrote:

Hi all,
have the same problem.
If i start the radio in USB mode, manually i change with a button on 
the radio IC706mk2 mode to CW, then i go back into WSJT-X i
chose a freq from the dropdown menu list, radio is trying to switch to 
that selected frequency but can't do it.
Already spoke with Michael about that problem but so far no results. 
All Hamlib versions after 12.12.2020 or so have something wrong with 
IC706mk2 settings. (Using also JTDX - same problem). Echo is disabled 
in the radio menu, speed is set to 4800.


debug.txt in the attachment

Best regards,
73 Patrik 9A5CW



On Wed, Jan 6, 2021 at 9:27 PM Christoph Berg > wrote:


Re: Black Michael via wsjt-devel
> So if you do an "ldd" on the executables they all point to the
same libhamlib ?

$ ldd /usr/bin/wsjtx | grep hamlib
        libhamlib.so.4 => /lib/x86_64-linux-gnu/libhamlib.so.4
(0x7f556f2a)
$ ldd /usr/bin/rigctl* | grep hamlib
        libhamlib.so.4 => /lib/x86_64-linux-gnu/libhamlib.so.4
(0x7f54323ba000)
        libhamlib.so.4 => /lib/x86_64-linux-gnu/libhamlib.so.4
(0x7f348d105000)
        libhamlib.so.4 => /lib/x86_64-linux-gnu/libhamlib.so.4
(0x7ffa08c89000)

> If that's true please provide some debug info from rigctld so we
can see the problem.  What I suspect you'll see is it's asking for
"VFO_SUB" which is the behavior we've seen with the
problemthat's the common problem with the structure realignment.

$ /usr/bin/rigctld -m 3009 -r /dev/ttyUSBICOM -p /dev/ttyUSBPTT -v
Recommend using --vfo switch for rigctld if client supports it
rigctl and netrigctl will automatically detect vfo mode
rigctld Hamlib 4.0
Last commit was Sa Jan 02 00:47:50 2021 + SHA=5f4cc3
Report bugs to mailto:hamlib-develo...@lists.sourceforge.net>>

rig_init called
initrigs4_icom: _init called
rig_register called
rig_register: rig_register (3055)
rig_register called
rig_register: rig_register (3085)
rig_register called
rig_register: rig_register (3009)
rig_register called
rig_register: rig_register (3010)
rig_register called
[...]
rig_register called
rig_register: rig_register (3076)
icom_init called
icom_init: done
main: twiddle=0, uplink=0
rig_open called
port_open called
serial_open called
serial_setup called
serial_setup: tcgetattr
serial_setup: cfmakeraw
serial_setup: cfsetispeed=19200,0x000e
serial_setup: cfsetospeed=19200,0x000e
serial_setup: data_bits=8
serial_setup: parity=0
serial_setup: tcsetattr TCSANOW
serial_flush called
tcflush
icom_rig_open 757
icom_rig_open: IC-706 v20201219.0
icom_get_usb_echo_off called
icom_get_usb_echo_off: retry temp set to 1
icom_transaction: cmd=0x03, subcmd=0x, payload_len=0,
data_len=80
rig_flush: called for serial device
serial_flush called
tcflush
write_block called
write_block(): TX 6 bytes
    fe fe 48 e0 03 fd  ..H...
read_string called, rxmax=80
read_string(): RX 6 characters
    fe fe 48 e0 03 fd  ..H...
read_string called, rxmax=80
read_string(): RX 11 characters
    fe fe e0 48 03 00 70 35 05 00 fd ...H..p5...
icom_get_usb_echo_off: ack_len=6
icom_get_usb_echo_off: USB echo on detected
rig_get_vfo called
rig_get_vfo: no get_vfo
rig_open: Icom rig so default vfo = currVFO
Opened rig model 3009, 'IC-706'
Backend version: 20201219.0, Status: Stable
main: Using IPV4

... clicking on "Test CAT" in wsjtx 2.3.0~rc3:

Connection opened from localhost:54898
sync_callback: client lock engaged
sync_callback: client lock disengaged
handle_socket: vfo_mode=0
rigctl_parse: called, interactive=1
rigctl_parse: cmd=\(5c)
rigctl_parse: cmd=chk_vfo
rigctl_parse: vfo_opt=0
rigctl_parse: debug1
rigctl_parse: debug5
rigctl_parse: debug10
sync_callback: client lock engaged
rigctl(d): ð 'currVFO' '' '' ''
rigctl_parse: vfo_opt=0
rigctl_parse: vfo_opt=0
rigctl_parse: retcode=0
sync_callback: client lock disengaged
handle_socket: vfo_mode=0
rigctl_parse: called, interactive=1
rigctl_parse: cmd=\(5c)
rigctl_parse: cmd=dump_state
rigctl_parse: vfo_opt=0
rigctl_parse: debug1
rigctl_parse: debug5
rigctl_parse: debug10
sync_callback: client lock engaged
rigctl(d):  'currVFO' '' '' ''
rigctl_parse: vfo_opt=0
rigctl_parse: vfo_opt=0
rigctl_parse: retcode=0
sync_callback: client lock disengaged
handle_socket: vfo_mode=0
rigctl_parse: called, interactive=1
rigctl_parse: cmd=v(76)
rigctl_parse: cmd==0x76
rigctl_parse: 

Re: [wsjt-devel] Hamlib 4.0 error with rigctld/IC706: Invalid parameter while exchanging VFOs

[Patrick 9A5CW]

Hi all,
have the same problem.
If i start the radio in USB mode, manually i change with a button on the
radio IC706mk2 mode to CW, then i go back into WSJT-X i
chose a freq from the dropdown menu list, radio is trying to switch to that
selected frequency but can't do it.
Already spoke with Michael about that problem but so far no results. All
Hamlib versions after 12.12.2020 or so have something wrong with IC706mk2
settings. (Using also JTDX - same problem). Echo is disabled in the radio
menu, speed is set to 4800.

debug.txt in the attachment

Best regards,
73 Patrik 9A5CW



On Wed, Jan 6, 2021 at 9:27 PM Christoph Berg  wrote:

> Re: Black Michael via wsjt-devel
> > So if you do an "ldd" on the executables they all point to the same
> libhamlib ?
>
> $ ldd /usr/bin/wsjtx | grep hamlib
> libhamlib.so.4 => /lib/x86_64-linux-gnu/libhamlib.so.4
> (0x7f556f2a)
> $ ldd /usr/bin/rigctl* | grep hamlib
> libhamlib.so.4 => /lib/x86_64-linux-gnu/libhamlib.so.4
> (0x7f54323ba000)
> libhamlib.so.4 => /lib/x86_64-linux-gnu/libhamlib.so.4
> (0x7f348d105000)
> libhamlib.so.4 => /lib/x86_64-linux-gnu/libhamlib.so.4
> (0x7ffa08c89000)
>
> > If that's true please provide some debug info from rigctld so we can see
> the problem.  What I suspect you'll see is it's asking for "VFO_SUB" which
> is the behavior we've seen with the problemthat's the common problem
> with the structure realignment.
>
> $ /usr/bin/rigctld -m 3009 -r /dev/ttyUSBICOM -p /dev/ttyUSBPTT -v
> Recommend using --vfo switch for rigctld if client supports it
> rigctl and netrigctl will automatically detect vfo mode
> rigctld Hamlib 4.0
> Last commit was Sa Jan 02 00:47:50 2021 + SHA=5f4cc3
> Report bugs to 
>
> rig_init called
> initrigs4_icom: _init called
> rig_register called
> rig_register: rig_register (3055)
> rig_register called
> rig_register: rig_register (3085)
> rig_register called
> rig_register: rig_register (3009)
> rig_register called
> rig_register: rig_register (3010)
> rig_register called
> [...]
> rig_register called
> rig_register: rig_register (3076)
> icom_init called
> icom_init: done
> main: twiddle=0, uplink=0
> rig_open called
> port_open called
> serial_open called
> serial_setup called
> serial_setup: tcgetattr
> serial_setup: cfmakeraw
> serial_setup: cfsetispeed=19200,0x000e
> serial_setup: cfsetospeed=19200,0x000e
> serial_setup: data_bits=8
> serial_setup: parity=0
> serial_setup: tcsetattr TCSANOW
> serial_flush called
> tcflush
> icom_rig_open 757
> icom_rig_open: IC-706 v20201219.0
> icom_get_usb_echo_off called
> icom_get_usb_echo_off: retry temp set to 1
> icom_transaction: cmd=0x03, subcmd=0x, payload_len=0, data_len=80
> rig_flush: called for serial device
> serial_flush called
> tcflush
> write_block called
> write_block(): TX 6 bytes
> fe fe 48 e0 03 fd   ..H...
> read_string called, rxmax=80
> read_string(): RX 6 characters
> fe fe 48 e0 03 fd   ..H...
> read_string called, rxmax=80
> read_string(): RX 11 characters
> fe fe e0 48 03 00 70 35 05 00 fd...H..p5...
> icom_get_usb_echo_off: ack_len=6
> icom_get_usb_echo_off: USB echo on detected
> rig_get_vfo called
> rig_get_vfo: no get_vfo
> rig_open: Icom rig so default vfo = currVFO
> Opened rig model 3009, 'IC-706'
> Backend version: 20201219.0, Status: Stable
> main: Using IPV4
>
> ... clicking on "Test CAT" in wsjtx 2.3.0~rc3:
>
> Connection opened from localhost:54898
> sync_callback: client lock engaged
> sync_callback: client lock disengaged
> handle_socket: vfo_mode=0
> rigctl_parse: called, interactive=1
> rigctl_parse: cmd=\(5c)
> rigctl_parse: cmd=chk_vfo
> rigctl_parse: vfo_opt=0
> rigctl_parse: debug1
> rigctl_parse: debug5
> rigctl_parse: debug10
> sync_callback: client lock engaged
> rigctl(d): ð 'currVFO' '' '' ''
> rigctl_parse: vfo_opt=0
> rigctl_parse: vfo_opt=0
> rigctl_parse: retcode=0
> sync_callback: client lock disengaged
> handle_socket: vfo_mode=0
> rigctl_parse: called, interactive=1
> rigctl_parse: cmd=\(5c)
> rigctl_parse: cmd=dump_state
> rigctl_parse: vfo_opt=0
> rigctl_parse: debug1
> rigctl_parse: debug5
> rigctl_parse: debug10
> sync_callback: client lock engaged
> rigctl(d):  'currVFO' '' '' ''
> rigctl_parse: vfo_opt=0
> rigctl_parse: vfo_opt=0
> rigctl_parse: retcode=0
> sync_callback: client lock disengaged
> handle_socket: vfo_mode=0
> rigctl_parse: called, interactive=1
> rigctl_parse: cmd=v(76)
> rigctl_parse: cmd==0x76
> rigctl_parse: vfo_opt=0
> rigctl_parse: debug1
> rigctl_parse: debug5
> rigctl_parse: debug10
> sync_callback: client lock engaged
> rigctl(d): v 'currVFO' '' '' ''
> rigctl_parse: vfo_opt=0
> rig_get_vfo called
> rig_get_vfo: no get_vfo
> rigctl_parse: vfo_opt=0
> rigctl_parse: return#1 RPRT -11
> rigctl_parse: retcode=-11
> sync_callback: client lock disengaged
> handle_socket: rigctl_parse retcode=-11
> handle_socket: 

Re: [wsjt-devel] Hamlib 4.0 error with rigctld/IC706: Invalid parameter while exchanging VFOs

[Bill Somerville]

On 06/01/2021 20:22, Christoph Berg wrote:

... and the "Hamlib error: Invalid parameter while exchanging VFOs" popup.


Hi Christoph,

the rigctld trace doesn't show any errors. Please put the attached file 
into the local configuration directory ~/.config and run the test again 
then quit WSJT-X. It will generate a file 
~/Desktop/WSJT-X_RigControl.log which will have trace info from the 
WSJT-X end.


73
Bill
G4WJS.

[Sinks.SYSLOG]
Destination=TextFile
Asynchronous=true
AutoFlush=false
FileName="${AppLocalDataLocation}/wsjtx_syslog.log"
TargetFileName="${AppLocalDataLocation}/logs/wsjtx_syslog_%Y-%m.log"
RotationTimePoint="01 00:00:00"
Append=true
EnableFinalRotation=false
MaxSize=41943040
MinFreeSpace=1073741824
MaxFiles=12
Target="${AppLocalDataLocation}/logs"
ScanForFiles="Matching"
Format="[%Channel%][%TimeStamp(format=\"%Y-%m-%d 
%H:%M:%S.%f\")%][%Uptime(format=\"%O:%M:%S.%f\")%][%Severity%] %Message%"
Filter="%Severity% >= info"

[Sinks.RIGCTRL]
Destination=TextFile
Asynchronous=true
AutoFlush=true
FileName="${DesktopLocation}/WSJT-X_RigControl.log"
Append=true
Format="[%TimeStamp(format=\"%Y-%m-%d 
%H:%M:%S.%f\")%][%Uptime(format=\"%O:%M:%S.%f\")%][%Channel%:%Severity%] 
%Message%"
Filter="%Channel% matches \"RIGCTRL\" | %Severity% >= info"
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Hamlib 4.0 error with rigctld/IC706: Invalid parameter while exchanging VFOs

[Christoph Berg]

Re: Black Michael via wsjt-devel
> So if you do an "ldd" on the executables they all point to the same libhamlib 
> ?

$ ldd /usr/bin/wsjtx | grep hamlib
libhamlib.so.4 => /lib/x86_64-linux-gnu/libhamlib.so.4 
(0x7f556f2a)
$ ldd /usr/bin/rigctl* | grep hamlib
libhamlib.so.4 => /lib/x86_64-linux-gnu/libhamlib.so.4 
(0x7f54323ba000)
libhamlib.so.4 => /lib/x86_64-linux-gnu/libhamlib.so.4 
(0x7f348d105000)
libhamlib.so.4 => /lib/x86_64-linux-gnu/libhamlib.so.4 
(0x7ffa08c89000)

> If that's true please provide some debug info from rigctld so we can see the 
> problem.  What I suspect you'll see is it's asking for "VFO_SUB" which is the 
> behavior we've seen with the problemthat's the common problem with the 
> structure realignment. 

$ /usr/bin/rigctld -m 3009 -r /dev/ttyUSBICOM -p /dev/ttyUSBPTT -v
Recommend using --vfo switch for rigctld if client supports it
rigctl and netrigctl will automatically detect vfo mode
rigctld Hamlib 4.0
Last commit was Sa Jan 02 00:47:50 2021 + SHA=5f4cc3
Report bugs to 

rig_init called
initrigs4_icom: _init called
rig_register called
rig_register: rig_register (3055)
rig_register called
rig_register: rig_register (3085)
rig_register called
rig_register: rig_register (3009)
rig_register called
rig_register: rig_register (3010)
rig_register called
[...]
rig_register called
rig_register: rig_register (3076)
icom_init called
icom_init: done
main: twiddle=0, uplink=0
rig_open called
port_open called
serial_open called
serial_setup called
serial_setup: tcgetattr
serial_setup: cfmakeraw
serial_setup: cfsetispeed=19200,0x000e
serial_setup: cfsetospeed=19200,0x000e
serial_setup: data_bits=8
serial_setup: parity=0
serial_setup: tcsetattr TCSANOW
serial_flush called
tcflush
icom_rig_open 757
icom_rig_open: IC-706 v20201219.0
icom_get_usb_echo_off called
icom_get_usb_echo_off: retry temp set to 1
icom_transaction: cmd=0x03, subcmd=0x, payload_len=0, data_len=80
rig_flush: called for serial device
serial_flush called
tcflush
write_block called
write_block(): TX 6 bytes
fe fe 48 e0 03 fd   ..H...
read_string called, rxmax=80
read_string(): RX 6 characters
fe fe 48 e0 03 fd   ..H...
read_string called, rxmax=80
read_string(): RX 11 characters
fe fe e0 48 03 00 70 35 05 00 fd...H..p5...
icom_get_usb_echo_off: ack_len=6
icom_get_usb_echo_off: USB echo on detected
rig_get_vfo called
rig_get_vfo: no get_vfo
rig_open: Icom rig so default vfo = currVFO
Opened rig model 3009, 'IC-706'
Backend version: 20201219.0, Status: Stable
main: Using IPV4

... clicking on "Test CAT" in wsjtx 2.3.0~rc3:

Connection opened from localhost:54898
sync_callback: client lock engaged
sync_callback: client lock disengaged
handle_socket: vfo_mode=0
rigctl_parse: called, interactive=1
rigctl_parse: cmd=\(5c)
rigctl_parse: cmd=chk_vfo
rigctl_parse: vfo_opt=0
rigctl_parse: debug1
rigctl_parse: debug5
rigctl_parse: debug10
sync_callback: client lock engaged
rigctl(d): ð 'currVFO' '' '' ''
rigctl_parse: vfo_opt=0
rigctl_parse: vfo_opt=0
rigctl_parse: retcode=0
sync_callback: client lock disengaged
handle_socket: vfo_mode=0
rigctl_parse: called, interactive=1
rigctl_parse: cmd=\(5c)
rigctl_parse: cmd=dump_state
rigctl_parse: vfo_opt=0
rigctl_parse: debug1
rigctl_parse: debug5
rigctl_parse: debug10
sync_callback: client lock engaged
rigctl(d):  'currVFO' '' '' ''
rigctl_parse: vfo_opt=0
rigctl_parse: vfo_opt=0
rigctl_parse: retcode=0
sync_callback: client lock disengaged
handle_socket: vfo_mode=0
rigctl_parse: called, interactive=1
rigctl_parse: cmd=v(76)
rigctl_parse: cmd==0x76
rigctl_parse: vfo_opt=0
rigctl_parse: debug1
rigctl_parse: debug5
rigctl_parse: debug10
sync_callback: client lock engaged
rigctl(d): v 'currVFO' '' '' ''
rigctl_parse: vfo_opt=0
rig_get_vfo called
rig_get_vfo: no get_vfo
rigctl_parse: vfo_opt=0
rigctl_parse: return#1 RPRT -11
rigctl_parse: retcode=-11
sync_callback: client lock disengaged
handle_socket: rigctl_parse retcode=-11
handle_socket: vfo_mode=0
rigctl_parse: called, interactive=1
rigctl_parse: cmd==0x0a
rigctl_parse: cmd=v(76)
rigctl_parse: cmd==0x76
rigctl_parse: vfo_opt=0
rigctl_parse: debug1
rigctl_parse: debug5
rigctl_parse: debug10
sync_callback: client lock engaged
rigctl(d): v 'currVFO' '' '' ''
rigctl_parse: vfo_opt=0
rig_get_vfo called
rig_get_vfo: no get_vfo
rigctl_parse: vfo_opt=0
rigctl_parse: return#1 RPRT -11
rigctl_parse: retcode=-11
sync_callback: client lock disengaged
handle_socket: rigctl_parse retcode=-11
handle_socket: vfo_mode=0
rigctl_parse: called, interactive=1
rigctl_parse: cmd==0x0a
rigctl_parse: cmd=f(66)
rigctl_parse: cmd==0x66
rigctl_parse: vfo_opt=0
rigctl_parse: debug1
rigctl_parse: debug5
rigctl_parse: debug10
sync_callback: client lock engaged
rigctl(d): f 'currVFO' '' '' ''
rigctl_parse: vfo_opt=0
rig_get_freq called vfo=currVFO
vfo_fixup: vfo=currVFO
vfo_fixup: Leaving currVFO 

Re: [wsjt-devel] Hamlib 4.0 error with rigctld/IC706: Invalid parameter while exchanging VFOs

[Dan Malcolm]

Not sure if my problem has anything to do with this discussion.  If not I’ll 
start with a fresh thread.  I installed rc3 yesterday and it worked fine.  This 
morning rc-3 and v2.2.2 will not connect to the virtual COM port.  I have 
rebooted & reinstalled vspMgr to no avail.  See the attached screen capture for 
the error message.

__
Dan – K4SHQ
CFI/II

From: Black Michael via wsjt-devel 
Sent: Wednesday, January 6, 2021 11:57 AM
To: wsjt-devel@lists.sourceforge.net
Cc: Black Michael 
Subject: Re: [wsjt-devel] Hamlib 4.0 error with rigctld/IC706: Invalid 
parameter while exchanging VFOs

Maybe I should move up the 4.1 release date or do a 4.0.1?

Mike W9MDB




On Wednesday, January 6, 2021, 07:40:05 AM CST, Bill Somerville 
mailto:g4...@classdesign.com>> wrote:


On 06/01/2021 13:28, Black Michael via wsjt-devel wrote:
> There is a binary incompatibility that happened under shared library
> use so if you use the rigctld-wsjtx from WSJTX it should hopefully
> worknot the rigctld from hamlib-4.0
>
> There's a future fix that will hopefully be in the 2.3.0 GA release
> that fixes this problem.
>
>
> Mike W9MDB
>
Mike,

those changes will not be in WSJT-X v2.3.0 GA, mainly because Hamlib 4.0
has a regression that breaks rigs with no get frequency CAT commands. I
expect the changes to be in a future WSJT-X release that is able to be
built against a Hamlib shared library that allows safe linking, I guess
that will be Hamlib v4.1.

73
Bill
G4WJS.




___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net<mailto: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] Hamlib 4.0 error with rigctld/IC706: Invalid parameter while exchanging VFOs

[Black Michael via wsjt-devel]

Maybe I should move up the 4.1 release date or do a 4.0.1?
Mike W9MDB

 

On Wednesday, January 6, 2021, 07:40:05 AM CST, Bill Somerville 
 wrote:  
 
 On 06/01/2021 13:28, Black Michael via wsjt-devel wrote:
> There is a binary incompatibility that happened under shared library 
> use so if you use the rigctld-wsjtx from WSJTX it should hopefully 
> worknot the rigctld from hamlib-4.0
>
> There's a future fix that will hopefully be in the 2.3.0 GA release 
> that fixes this problem.
>
>
> Mike W9MDB
>
Mike,

those changes will not be in WSJT-X v2.3.0 GA, mainly because Hamlib 4.0 
has a regression that breaks rigs with no get frequency CAT commands. I 
expect the changes to be in a future WSJT-X release that is able to be 
built against a Hamlib shared library that allows safe linking, I guess 
that will be Hamlib v4.1.

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] Hamlib 4.0 error with rigctld/IC706: Invalid parameter while exchanging VFOs

[Black Michael via wsjt-devel]

So if you do an "ldd" on the executables they all point to the same libhamlib ?

If that's true please provide some debug info from rigctld so we can see the 
problem.  What I suspect you'll see is it's asking for "VFO_SUB" which is the 
behavior we've seen with the problemthat's the common problem with the 
structure realignment. 

On Wednesday, January 6, 2021, 07:59:19 AM CST, Christoph Berg 
 wrote:  
 
 Re: Bill Somerville
> Is your WSJT-X built against the same hamlib-dev package that fldigi is? I
> would guess that it is so something else must be broken.

Everything is linked against the 4.0 release tarball, yes.

Christoph


___
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] Hamlib 4.0 error with rigctld/IC706: Invalid parameter while exchanging VFOs

[Christoph Berg]

Re: Bill Somerville
> Is your WSJT-X built against the same hamlib-dev package that fldigi is? I
> would guess that it is so something else must be broken.

Everything is linked against the 4.0 release tarball, yes.

Christoph


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

Re: [wsjt-devel] Hamlib 4.0 error with rigctld/IC706: Invalid parameter while exchanging VFOs

[Black Michael via wsjt-devel]

I'm not suggesting moving away from shared librariesjust noting that hamlib 
wasn't designed to allow references to internal data structures with shared 
libraries.  Static linking does fix that problem.  What happened was a new 
variable in hamlib_port_t realigned the rig_caps data structure and vfo_list 
points to incorrect data as the 1st thing that gets referenced.Hamlib 5.0 will 
completely break such backwards compatibility in shared libraries as I plan on 
making changes to reduce the fragile structure layout and eliminate anybody 
trying to refer to rig_caps except through an API.
I was hoping that rigctld-wsjtx does work correctly...did you try that one?
Mike W9MDB
 

On Wednesday, January 6, 2021, 07:42:32 AM CST, Christoph Berg 
 wrote:  
 
 Re: Black Michael via wsjt-devel
> Does the Debian WSJT-X use hamlib as a shared library?
> Sounds like that may be the problem.

Mike, please stop suggesting that moving away from shared linking
would solve any problems. That will not happen on Debian.

> There is a binary incompatibility that happened under shared library use so 
> if you use the rigctld-wsjtx from WSJTX it should hopefully worknot the 
> rigctld from hamlib-4.0
> There's a future fix that will hopefully be in the 2.3.0 GA release that 
> fixes this problem.

I'm using the hamlib rigctld. That works fine with fldigi also linked
against hamlib 4.0, so that shouldn't be a problem.

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

Re: [wsjt-devel] Hamlib 4.0 error with rigctld/IC706: Invalid parameter while exchanging VFOs

[Bill Somerville]

On 06/01/2021 13:42, Christoph Berg wrote:

Re: Black Michael via wsjt-devel

Does the Debian WSJT-X use hamlib as a shared library?
Sounds like that may be the problem.

Mike, please stop suggesting that moving away from shared linking
would solve any problems. That will not happen on Debian.


There is a binary incompatibility that happened under shared library use so if 
you use the rigctld-wsjtx from WSJTX it should hopefully worknot the 
rigctld from hamlib-4.0
There's a future fix that will hopefully be in the 2.3.0 GA release that fixes 
this problem.

I'm using the hamlib rigctld. That works fine with fldigi also linked
against hamlib 4.0, so that shouldn't be a problem.

Christoph


Christoph,

you can demand whatever you like but Hamlib in its current form is not 
suitable for shared linking unless one very strict caveat is applied. 
That caveat is that every Hamlib client must be compiled and linked 
against the very same commit of Hamlib. It might work without that, but 
it is not guaranteed. Mike is suggesting that you may have broken that 
caveat, perhaps unknowingly, but nevertheless you may have fallen foul 
of it.


Is your WSJT-X built against the same hamlib-dev package that fldigi is? 
I would guess that it is so something else must be broken.


73
Bill
G4WJS.

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

Re: [wsjt-devel] Hamlib 4.0 error with rigctld/IC706: Invalid parameter while exchanging VFOs

[Christoph Berg]

Re: Black Michael via wsjt-devel
> Does the Debian WSJT-X use hamlib as a shared library?
> Sounds like that may be the problem.

Mike, please stop suggesting that moving away from shared linking
would solve any problems. That will not happen on Debian.

> There is a binary incompatibility that happened under shared library use so 
> if you use the rigctld-wsjtx from WSJTX it should hopefully worknot the 
> rigctld from hamlib-4.0
> There's a future fix that will hopefully be in the 2.3.0 GA release that 
> fixes this problem.

I'm using the hamlib rigctld. That works fine with fldigi also linked
against hamlib 4.0, so that shouldn't be a problem.

Christoph


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

Re: [wsjt-devel] Hamlib 4.0 error with rigctld/IC706: Invalid parameter while exchanging VFOs

[Bill Somerville]

On 06/01/2021 13:28, Black Michael via wsjt-devel wrote:
There is a binary incompatibility that happened under shared library 
use so if you use the rigctld-wsjtx from WSJTX it should hopefully 
worknot the rigctld from hamlib-4.0


There's a future fix that will hopefully be in the 2.3.0 GA release 
that fixes this problem.



Mike W9MDB


Mike,

those changes will not be in WSJT-X v2.3.0 GA, mainly because Hamlib 4.0 
has a regression that breaks rigs with no get frequency CAT commands. I 
expect the changes to be in a future WSJT-X release that is able to be 
built against a Hamlib shared library that allows safe linking, I guess 
that will be Hamlib v4.1.


73
Bill
G4WJS.



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

Re: [wsjt-devel] Hamlib 4.0 error with rigctld/IC706: Invalid parameter while exchanging VFOs

[Black Michael via wsjt-devel]

Does the Debian WSJT-X use hamlib as a shared library?
Sounds like that may be the problem.
There is a binary incompatibility that happened under shared library use so if 
you use the rigctld-wsjtx from WSJTX it should hopefully worknot the 
rigctld from hamlib-4.0
There's a future fix that will hopefully be in the 2.3.0 GA release that fixes 
this problem.

Mike W9MDB

 

On Tuesday, January 5, 2021, 03:55:02 PM CST, Christoph Berg 
 wrote:  
 
 Hi,

since I switched the Debian wsjtx package to hamlib 4.0 with my IC706,
Hamlib rigctld operation doesn't work anymore:

Hamlib error: Invalid parameter while exchanging VFOs

FLdigi works fine through rigctld, both with the 3.3 and 4.0 hamlib.
(Including adjusting the rig number in rigctld.)

Attaching the rig directly works better. I didn't have any problems
with 2.3.0 rc2 earlier this week, but 2.3.0 rc3 needed quite some
manual poking now (setting band and mode manually on the rig) before
wsjtx wanted to work with it. Split mode is enabled.

Christoph


___
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