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
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] WSJT-X v2.3.0-rc3 Tune Button Error

[Joe Taylor]

Hi Gene,

I'm not sure whether someone else has looked into your reported issue. 
I have, and did not "fix" anything because I could not reproduce your 
problem.


Instead of clicking Tune a second time to stop your Tune cycle, have you 
tried clicking Halt?  FWIW, either one works as expected here, and the 
next Tx cycle starts as it should.


-- Joe, K1JT

On 1/6/2021 11:11 AM, Gene H wrote:

Good morning,

I have tested the *WSJT-X v2.3.0-rc3* in the FT8 mode and am still 
noticing the problem with clicking the *Tune *button twice (to tune and 
then release the tune) that keeps the program from transmitting 
correctly at the start of the next transmit cycle while calling another 
station. I had reported this in October and November but was uncertain 
if it was being addressed. The ramification is to always be 30 seconds 
behind on making calls to any station since the next transmit cycle is 
being missed. Here are links to the prior messages.


https://sourceforge.net/p/wsjt/mailman/message/37146970 



https://sourceforge.net/p/wsjt/mailman/message/37133486 



_My work-around_ has been to use the *Tune *button to allow me to 
operate a remote tuner and then clicking the *Halt Tx* button to stop 
the transmission.


A fix would be to always have the program perform the *Halt Tx *command 
whenever the *Tune *button was pressed if *Tune *was currently invoked.


I am using: WSJT-X Version v2.3.0-rc3,  64-bit Windows-10 Pro O/S, 
IC-7610 Transceiver.


Thank you,

Gene, K5PA




___
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] WSJT-X: UI wdiget tab navigation ordering

[Sam W2JDB via wsjt-devel]

Hi Bill,
Ok. Thanks for the reply. No Worries. Cheers.
73,

Sam W2JDB


-Original Message-
From: Bill Somerville 
To: wsjt-devel@lists.sourceforge.net
Sent: Wed, Jan 6, 2021 2:09 pm
Subject: Re: [wsjt-devel] WSJT-X: UI wdiget tab navigation ordering

 Hi Sam, 
  WSJT-X follows long established operating practice, when starting a QSO the 
operating frequency is set and kept the same throughout the QSO. Moving during 
a QSO requires direct intervention by the operator. 
  The FT8 decoder in WSJT-X is capable of decoding more than signal on the same 
frequency, time synchronization differences are not particularly relevant. 
Weaker underlying signals are revealed to the decoder by subtracting an exact 
facsimile (both amplitude and phase) of previously decoded signals, then trying 
the decoding again on the remaining waveform. 
  73
 Bill
 G4WJS. 
  On 06/01/2021 18:48, Sam W2JDB via wsjt-devel wrote:
  
  Hi Bill, 
  Testing 2.3-RC3 – So far so good. Made the necessary adjustments to the 
different tab sequences so that is no longer an issue. My program recognizes 
the current running WSJT-X version and now reacts correctly whether you are 
using WSJT-X 2.2.2 as well as 2.3-rc3. If you have not done so, you don’t need 
to change anything with tab sequencing on my account in the next release.  
  I did notice one item that may cause inadvertent QRM. I replied to a station 
calling CQ. As I did not have Hold TX checked, WSJT-X moved automatically to 
the calling CQ offset. After logging the QSO, I replied to another calling 
station that was a few Hertz away from the previous caller and as expected 
WSJT-X moved to the second caller offset. After my first reply, the second 
station moved to another clear offset but WSJT-X stayed on the second caller 
first offset. While the QSO was completed, I think that WSJT-X should have 
moved again to the second caller new offset as I still did not have Hold TX 
checked.  
  Looking at the screen at the DT time and offset values, I believe that the 
reason WSJT-X was able to decode the second caller even though he was just a 
few Hertz away from the first called is because the first caller DT was 1.1 
while the second caller DT was 0.1. 
  Anyway, that is just an observation. 
  Have a great day and thanks again. 
  
  73, 
 
   Sam W2JDB 

 
 -Original Message-
 From: Sam W2JDB mailto:w2...@aol.com
 To: g4...@classdesign.com mailto:g4...@classdesign.com; 
wsjt-devel@lists.sourceforge.net mailto:wsjt-devel@lists.sourceforge.net
 Sent: Tue, Jan 5, 2021 7:53 pm
 Subject: Re: [wsjt-devel] WSJT-X: UI wdiget tab navigation ordering - was Re: 
WSJT-X 2.3.0-rc3 - wsjtx_app_version utility
 
Hi Bill, 
  Thanks for the email. I just have to make sure that it all works. Just 
thought I would mention it.  
  It wasn't until I started making QLog visually impaired friendly that I 
realized how important the tabbing sequence really is in the UI. 
  I am already modifying QLog to take care of this situation so that it can be 
used with 2.2x and 2.3x 
  Keep up the great work with this product. I can assure you that the blind 
hams are having a great time with this.  
  Have a safe and healthy 2021. 
  73, 
Sam W2JDB 

 
 -Original Message-
 From: Bill Somerville mailto:g4...@classdesign.com
 To: wsjt-devel@lists.sourceforge.net
 Sent: Tue, Jan 5, 2021 6:38 pm
 Subject: [wsjt-devel] WSJT-X: UI wdiget tab navigation ordering - was Re: 
WSJT-X 2.3.0-rc3 - wsjtx_app_version utility
 
On 05/01/2021 21:49, Sam W2JDB via wsjt-devel wrote:
  
 Downloaded the new version and started testing it with my program (QLog) for 
the visually impaired. Noticed some weird tab sequences in the Generate Std 
Msgs group of controls. 
  In Ver 2.2 pressing Shortcut keys Ctrl+6 then Shift+Tab changed focus to the 
tx6 input box. Subsequent multiple Shift+Tab key strokes shift focus to the 
previous Tx input boxes. 
  In Ver 2.3-rc3 pressing Shortcut keys Ctrl+6 then Shift+Tab changes focus  to 
the [1] control in the group. The next Shift+Tab changes focus to the Hold Tx 
Freq check box.  If you press Ctrl+6 then the TAB key, focus shifts the tx1 
input box. The next TAB key press shifts  focus to the tx6 input box, the next 
TAB moves you to the [tx5] button, another TAB moves to  the [tx2] button, next 
TAB move to the tx2 input, followed by a TAB to the tx4 input.  Just an FYI 
  73, 
Sam W2JDB   
 Hi Sam, I don't think anyone has consciously attempted to define any sort of 
logical flow of Tab/Shift+Tab widget navigation for the WSJT-X main window. I 
have defined the ordering for the next release but be aware that it may vary 
when widgets are changed in the future.  73
 Bill
 G4WJS.  
 
  ___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
___
wsjt-devel mailing list

Re: [wsjt-devel] WSJT-X: UI wdiget tab navigation ordering

[Bill Somerville]

Hi Sam,

WSJT-X follows long established operating practice, when starting a QSO 
the operating frequency is set and kept the same throughout the QSO. 
Moving during a QSO requires direct intervention by the operator.


The FT8 decoder in WSJT-X is capable of decoding more than signal on the 
same frequency, time synchronization differences are not particularly 
relevant. Weaker underlying signals are revealed to the decoder by 
subtracting an exact facsimile (both amplitude and phase) of previously 
decoded signals, then trying the decoding again on the remaining waveform.


73
Bill
G4WJS.

On 06/01/2021 18:48, Sam W2JDB via wsjt-devel wrote:

Hi Bill,

Testing 2.3-RC3 – So far so good. Made the necessary adjustments to 
the different tab sequences so that is no longer an issue. My program 
recognizes the current running WSJT-X version and now reacts correctly 
whether you are using WSJT-X 2.2.2 as well as 2.3-rc3. If you have not 
done so, you don’t need to change anything with tab sequencing on my 
account in the next release.


I did notice one item that may cause inadvertent QRM. I replied to a 
station calling CQ. As I did not have Hold TX checked, WSJT-X moved 
automatically to the calling CQ offset. After logging the QSO, I 
replied to another calling station that was a few Hertz away from the 
previous caller and as expected WSJT-X moved to the second caller 
offset. After my first reply, the second station moved to another 
clear offset but WSJT-X stayed on the second caller first offset. 
While the QSO was completed, I think that WSJT-X should have moved 
again to the second caller new offset as I still did not have Hold TX 
checked.


Looking at the screen at the DT time and offset values, I believe that 
the reason WSJT-X was able to decode the second caller even though he 
was just a few Hertz away from the first called is because the first 
caller DT was 1.1 while the second caller DT was 0.1.


Anyway, that is just an observation.

Have a great day and thanks again.


73,


Sam W2JDB



-Original Message-
From: Sam W2JDB 
To: g4...@classdesign.com ; 
wsjt-devel@lists.sourceforge.net 

Sent: Tue, Jan 5, 2021 7:53 pm
Subject: Re: [wsjt-devel] WSJT-X: UI wdiget tab navigation ordering - 
was Re: WSJT-X 2.3.0-rc3 - wsjtx_app_version utility


Hi Bill,

Thanks for the email. I just have to make sure that it all works.
Just thought I would mention it.

It wasn't until I started making QLog visually impaired friendly that
I realized how important the tabbing sequence really is in the UI.

I am already modifying QLog to take care of this situation so
that it can be used with 2.2x and 2.3x

Keep up the great work with this product. I can assure you that
the blind hams are having a great time with this.

Have a safe and healthy 2021.

73,

Sam W2JDB



-Original Message-
From: Bill Somerville 
To: wsjt-devel@lists.sourceforge.net
Sent: Tue, Jan 5, 2021 6:38 pm
Subject: [wsjt-devel] WSJT-X: UI wdiget tab navigation ordering - was 
Re: WSJT-X 2.3.0-rc3 - wsjtx_app_version utility


On 05/01/2021 21:49, Sam W2JDB via wsjt-devel wrote:
Downloaded the new version and started testing it with my program 
(QLog) for the visually impaired.
Noticed some weird tab sequences in the Generate Std Msgs group of 
controls.


In Ver 2.2 pressing Shortcut keys Ctrl+6 then Shift+Tab changed focus 
to the tx6 input box.
Subsequent multiple Shift+Tab key strokes shift focus to the previous 
Tx input boxes.


In Ver 2.3-rc3 pressing Shortcut keys Ctrl+6 then Shift+Tab changes 
focus
to the [1] control in the group. The next Shift+Tab changes focus to 
the Hold Tx Freq check box.
If you press Ctrl+6 then the TAB key, focus shifts the tx1 input box. 
The next TAB key press shifts
focus to the tx6 input box, the next TAB moves you to the [tx5] 
button, another TAB moves to
the [tx2] button, next TAB move to the tx2 input, followed by a TAB 
to the tx4 input.

Just an FYI

73,

Sam W2JDB

Hi Sam,
I don't think anyone has consciously attempted to define any sort of 
logical flow of Tab/Shift+Tab widget navigation for the WSJT-X main 
window. I have defined the ordering for the next release but be aware 
that it may vary when widgets are changed in the future.

73
Bill
G4WJS.



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

Re: [wsjt-devel] WSJT-X: UI wdiget tab navigation ordering

[Sam W2JDB via wsjt-devel]

Hi Bill,
Testing 2.3-RC3 –So far so good. Made the necessary adjustments to the 
different tabsequences so that is no longer an issue. My program recognizes 
thecurrent running WSJT-X version and now reacts correctly whether youare using 
WSJT-X 2.2.2 as well as 2.3-rc3. If you have not done so,you don’t need to 
change anything with tab sequencing on my accountin the next release. 
I did notice oneitem that may cause inadvertent QRM. I replied to a station 
callingCQ. As I did not haveHold TX checked, WSJT-X moved automatically to the 
calling CQ offset. After logging theQSO, I replied to another calling station 
that was a few Hertz awayfrom the previous caller and as expected WSJT-X moved 
to the secondcaller offset. After my first reply, the second station moved 
toanother clear offset but WSJT-X stayed on the second caller firstoffset. 
While the QSO was completed, I think that WSJT-X should havemoved again to the 
second caller new offset as I still did not haveHold TX checked. 
Looking at thescreen at the DT time and offset values, I believe that the 
reasonWSJT-X was able to decode the second caller even though he was just afew 
Hertz away from the first called is because the first caller DTwas 1.1 while 
the second caller DT was 0.1.
Anyway, that is justan observation.
Have a great day andthanks again.

73,

Sam W2JDB


-Original Message-
From: Sam W2JDB 
To: g4...@classdesign.com ; 
wsjt-devel@lists.sourceforge.net 
Sent: Tue, Jan 5, 2021 7:53 pm
Subject: Re: [wsjt-devel] WSJT-X: UI wdiget tab navigation ordering - was Re: 
WSJT-X 2.3.0-rc3 - wsjtx_app_version utility

Hi Bill,
Thanks for the email. I just have to make sure that it all works.Just thought I 
would mention it. 
It wasn't until I started making QLog visually impaired friendly thatI realized 
how important the tabbing sequence really is in the UI.
I am already modifying QLog to take care of this situation sothat it can be 
used with 2.2x and 2.3x
Keep up the great work with this product. I can assure you thatthe blind hams 
are having a great time with this. 
Have a safe and healthy 2021.
73,
Sam W2JDB


-Original Message-
From: Bill Somerville 
To: wsjt-devel@lists.sourceforge.net
Sent: Tue, Jan 5, 2021 6:38 pm
Subject: [wsjt-devel] WSJT-X: UI wdiget tab navigation ordering - was Re: 
WSJT-X 2.3.0-rc3 - wsjtx_app_version utility

 On 05/01/2021 21:49, Sam W2JDB via wsjt-devel wrote:
  
 Downloaded the new version and started testing it with my program (QLog) for 
the visually impaired. Noticed some weird tab sequences in the Generate Std 
Msgs group of controls. 
  In Ver 2.2 pressing Shortcut keys Ctrl+6 then Shift+Tab changed focus to the 
tx6 input box. Subsequent multiple Shift+Tab key strokes shift focus to the 
previous Tx input boxes. 
  In Ver 2.3-rc3 pressing Shortcut keys Ctrl+6 then Shift+Tab changes focus  to 
the [1] control in the group. The next Shift+Tab changes focus to the Hold Tx 
Freq check box.  If you press Ctrl+6 then the TAB key, focus shifts the tx1 
input box. The next TAB key press shifts  focus to the tx6 input box, the next 
TAB moves you to the [tx5] button, another TAB moves to  the [tx2] button, next 
TAB move to the tx2 input, followed by a TAB to the tx4 input.  Just an FYI 
  73, 
Sam W2JDB   
 Hi Sam, I don't think anyone has consciously attempted to define any sort of 
logical flow of Tab/Shift+Tab widget navigation for the WSJT-X main window. I 
have defined the ordering for the next release but be aware that it may vary 
when widgets are changed in the future. 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]

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

[wsjt-devel] WSJT-X v2.3.0-rc3 Tune Button Error

[Gene H]

Good morning,

I have tested the *WSJT-X v2.3.0-rc3* in the FT8 mode and am still 
noticing the problem with clicking the *Tune *button twice (to tune and 
then release the tune) that keeps the program from transmitting 
correctly at the start of the next transmit cycle while calling another 
station. I had reported this in October and November but was uncertain 
if it was being addressed. The ramification is to always be 30 seconds 
behind on making calls to any station since the next transmit cycle is 
being missed. Here are links to the prior messages.


https://sourceforge.net/p/wsjt/mailman/message/37146970 



https://sourceforge.net/p/wsjt/mailman/message/37133486 



_My work-around_ has been to use the *Tune *button to allow me to 
operate a remote tuner and then clicking the *Halt Tx* button to stop 
the transmission.


A fix would be to always have the program perform the *Halt Tx *command 
whenever the *Tune *button was pressed if *Tune *was currently invoked.


I am using: WSJT-X Version v2.3.0-rc3,  64-bit Windows-10 Pro O/S, 
IC-7610 Transceiver.


Thank you,

Gene, K5PA


___
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

Re: [wsjt-devel] WSJT-X 2.3.0-rc3

[Bill Somerville]

On 06/01/2021 12:53, Claude Frantz wrote:

On 1/6/21 11:59 AM, Bill Somerville wrote:


On 06/01/2021 10:53, Claude Frantz wrote:


so that shows you have deleted the files in the debian sub-directory, 
was that by accident or deliberate?


Hi Bill,

It was not deliberate, probably by accident.

Now, I have run:

$ git checkout -B master origin/master
M    CMakeLists.txt
D    debian/CMakeLists.txt
D    debian/changelog.in
D    debian/copyright.in
Branch 'master' set up to track remote branch 'master' from 'origin'.
Reset branch 'master'
Your branch is up to date with 'origin/master'.
$ git reset --hard origin/master
HEAD is now at 580363c29 Merge branch 'release-2.3.0'


I hope that it was the right sequence.

Then I have changed to the build directory…

make -k

The problem related to xsltproc occurred again. The executable "wsjtx" 
has not been rebuilt. Using cmake-gui, I have disabled the generation 
of the man pages.


make -B wsjtx

Now, I have the executable. Please note this warnings:

[ 89%] Generating qrc_wsjtx.cpp
/home/claude/ham/JoeTaylor/wsjtx/build/wsjtx.qrc: Warning: potential 
duplicate alias detected: 'qt_it.qm'
/home/claude/ham/JoeTaylor/wsjtx/build/wsjtx.qrc: Warning: potential 
duplicate alias detected: 'wsjtx_it.qm'

[ 89%] Building CXX object CMakeFiles/wsjtx.dir/qrc_wsjtx.cpp.o

At next: make -k. The run goes to end.

Now, I have to run the executable.

Many thanks, Bill !

Best wishes,
Claude (DJ0OT) 


Hi Claude,

the warnings can be ignored, they are due to out translators adding 
translations for labels that are already translated by the Qt team.


Thanks for the update, glad you are up and running again.

73
Bill
G4WJS.

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

Re: [wsjt-devel] WSJT-X 2.3.0-rc3

[Claude Frantz]

On 1/6/21 11:59 AM, Bill Somerville wrote:


On 06/01/2021 10:53, Claude Frantz wrote:


so that shows you have deleted the files in the debian sub-directory, 
was that by accident or deliberate?


Hi Bill,

It was not deliberate, probably by accident.

Now, I have run:

$ git checkout -B master origin/master
M   CMakeLists.txt
D   debian/CMakeLists.txt
D   debian/changelog.in
D   debian/copyright.in
Branch 'master' set up to track remote branch 'master' from 'origin'.
Reset branch 'master'
Your branch is up to date with 'origin/master'.
$ git reset --hard origin/master
HEAD is now at 580363c29 Merge branch 'release-2.3.0'


I hope that it was the right sequence.

Then I have changed to the build directory…

make -k

The problem related to xsltproc occurred again. The executable "wsjtx" 
has not been rebuilt. Using cmake-gui, I have disabled the generation of 
the man pages.


make -B wsjtx

Now, I have the executable. Please note this warnings:

[ 89%] Generating qrc_wsjtx.cpp
/home/claude/ham/JoeTaylor/wsjtx/build/wsjtx.qrc: Warning: potential 
duplicate alias detected: 'qt_it.qm'
/home/claude/ham/JoeTaylor/wsjtx/build/wsjtx.qrc: Warning: potential 
duplicate alias detected: 'wsjtx_it.qm'

[ 89%] Building CXX object CMakeFiles/wsjtx.dir/qrc_wsjtx.cpp.o

At next: make -k. The run goes to end.

Now, I have to run the executable.

Many thanks, Bill !

Best wishes,
Claude (DJ0OT)







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

Re: [wsjt-devel] WSJT-X 2.3.0-rc3

[Bill Somerville]

On 06/01/2021 10:53, Claude Frantz wrote:

On 1/6/21 11:38 AM, Bill Somerville wrote:

Hi Bill,

I am not sure what has happened, but that directory contains a 
CMakeLists.txt file in both  the master branch and the 
wsjtx-2.3.0-rc3 tag. Looks like something has gone wrong with your 
local clone of the WSJT-X repository. What does this print:


git -C ~/ham/JoeTaylor/wsjtx status


Here is the output:

$ git -C ~/ham/JoeTaylor/wsjtx status
On branch master
Your branch is up to date with 'origin/master'.

You are in the middle of an am session.
  (fix conflicts and then run "git am --continue")
  (use "git am --skip" to skip this patch)
  (use "git am --abort" to restore the original branch)

Changes not staged for commit:
  (use "git add/rm ..." to update what will be committed)
  (use "git checkout -- ..." to discard changes in working 
directory)


modified:   CMakeLists.txt
deleted:    debian/CMakeLists.txt
deleted:    debian/changelog.in
deleted:    debian/copyright.in

Untracked files:
  (use "git add ..." to include in what will be committed)

HamlibTransceiver.hpp.orig
User_Guide_FOP.pdf
build/
doc/user_guide/en/install-linux.pdf
doc/user_guide/en/install-mac.pdf
doc/user_guide/en/my_Makefile
doc/user_guide/en/settings-frequencies.pdf
doc/user_guide/en/wsjtx-main.xml
doc/user_guide/en/wsjtx-main_via_docpdf.pdf
doc/user_guide/en/wsjtx-main_via_pandoc.pdf

no changes added to commit (use "git add" and/or "git commit -a")


Best wishes,
Claude (DJ0OT) 


Hi Claude,

so that shows you have deleted the files in the debian sub-directory, 
was that by accident or deliberate?


73
Bill
G4WJS.

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

Re: [wsjt-devel] WSJT-X 2.3.0-rc3

[Claude Frantz]

On 1/6/21 11:38 AM, Bill Somerville wrote:

Hi Bill,

I am not sure what has happened, but that directory contains a 
CMakeLists.txt file in both  the master branch and the wsjtx-2.3.0-rc3 
tag. Looks like something has gone wrong with your local clone of the 
WSJT-X repository. What does this print:


git -C ~/ham/JoeTaylor/wsjtx status


Here is the output:

$ git -C ~/ham/JoeTaylor/wsjtx status
On branch master
Your branch is up to date with 'origin/master'.

You are in the middle of an am session.
  (fix conflicts and then run "git am --continue")
  (use "git am --skip" to skip this patch)
  (use "git am --abort" to restore the original branch)

Changes not staged for commit:
  (use "git add/rm ..." to update what will be committed)
  (use "git checkout -- ..." to discard changes in working directory)

modified:   CMakeLists.txt
deleted:debian/CMakeLists.txt
deleted:debian/changelog.in
deleted:debian/copyright.in

Untracked files:
  (use "git add ..." to include in what will be committed)

HamlibTransceiver.hpp.orig
User_Guide_FOP.pdf
build/
doc/user_guide/en/install-linux.pdf
doc/user_guide/en/install-mac.pdf
doc/user_guide/en/my_Makefile
doc/user_guide/en/settings-frequencies.pdf
doc/user_guide/en/wsjtx-main.xml
doc/user_guide/en/wsjtx-main_via_docpdf.pdf
doc/user_guide/en/wsjtx-main_via_pandoc.pdf

no changes added to commit (use "git add" and/or "git commit -a")


Best wishes,
Claude (DJ0OT)



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

Re: [wsjt-devel] WSJT-X 2.3.0-rc3

[Claude Frantz]

On 1/6/21 8:36 AM, Claude Frantz wrote:

After having disabled the Debian stuff in CMakeLists.txt, the building 
process runs up to this output:


[ 87%] Generating man/man1/rigctlcom-wsjtx.1.gz
a2x: ERROR: "xsltproc" -param man.endnotes.list.enabled 0 -param 
man.endnotes.are.numbered 0 --stringparam callout.graphics 0 
--stringparam navig.graphics 0 --stringparam admon.textlabel 1 
--stringparam admon.graphics 0  "/etc/asciidoc/docbook-xsl/manpage.xsl" 
"/home/claude/ham/JoeTaylor/wsjtx/build/manpages/man/man1/rigctlcom-wsjtx.1.xml" 
returned non-zero exit status 5


make[2]: *** [manpages/CMakeFiles/manpages.dir/build.make:184: 
manpages/man/man1/rigctlcom-wsjtx.1.gz] Error 1
make[2]: Target 'manpages/CMakeFiles/manpages.dir/build' not remade 
because of errors.
make[1]: *** [CMakeFiles/Makefile2:2010: 
manpages/CMakeFiles/manpages.dir/all] Error 2



Error number 5 is: Error in the stylesheet

Best wishes,
Claude (DJ0OT)


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

Re: [wsjt-devel] WSJT-X 2.3.0-rc3

[Bill Somerville]

On 06/01/2021 07:36, Claude Frantz wrote:

On 1/5/21 11:30 PM, Dave Slotter wrote:

Hi Dave, Bill and all,

Unfortunately, I was not successful while trying to install from the 
source code from the git repo. Here is the output:


$ make
-- **
-- Building for for: Linux-i686
-- **
-- Building wsjtx v2.3.0.0-rc3
-- Found hamlib
-- hamlib_INCLUDE_DIRS: /usr/local/include;/usr/include/libusb-1.0
-- hamlib_LIBRARIES: 
-L/usr/local/lib;-lhamlib;-lm;-lusb-1.0;-ludev;-pthread

-- hamlib_LIBRARY_DIRS: /usr/local/lib
-- Asking qmake for QT_PLUGINS_DIR and got /usr/lib/qt5/plugins
-- Asking qmake for QT_TRANSLATIONS_DIR and got 
/usr/share/qt5/translations

-- Asking qmake for QT_IMPORTS_DIR and got /usr/lib/qt5/imports
-- Asking qmake for QT_DATA_DIR and got /usr/lib/qt5
CMake Error at CMakeLists.txt:1500 (add_subdirectory):
  The source directory

    /home/claude/ham/JoeTaylor/wsjtx/debian

  does not contain a CMakeLists.txt file.


-- Configuring incomplete, errors occurred!
See also 
"/home/claude/ham/JoeTaylor/wsjtx/build/CMakeFiles/CMakeOutput.log".
See also 
"/home/claude/ham/JoeTaylor/wsjtx/build/CMakeFiles/CMakeError.log".

make: *** [Makefile:14885: cmake_check_build_system] Error 1



The directory /home/claude/ham/JoeTaylor/wsjtx/debian is present but 
empty.


Best wishes,
Claude (DJ0OT) 


Hi Claude,

I am not sure what has happened, but that directory contains a 
CMakeLists.txt file in both  the master branch and the wsjtx-2.3.0-rc3 
tag. Looks like something has gone wrong with your local clone of the 
WSJT-X repository. What does this print:


git -C ~/ham/JoeTaylor/wsjtx status

73
Bill
G4WJS.

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

Re: [wsjt-devel] TAB3

[jarmo]

Wed, 6 Jan 2021 11:41:52 +0200
"Reino Talarmo"  kirjoitti:

> Jarmo,
> 
> Free text on edelleenkin Tab 1 Tx5. Siihen kirjoitetun tekstin saa
> talletettua Return näppäimellä ja lista talletetuista tulee
> oikeanpuoleisella menunappulalla. Muuten kaikki Tx1 - Tx6 kentät voi
> editoida, mutta vain Tx5 säilyy suljettaessa.
> 
> 73, Reino OH3mA
Moi
Kiitos, menin hieman hämilleen, kun etsin sitä
vanhaa... Siihen TX5 on aina pystyny kirjottamaan
ennenkin...

Hyvä kun selvis nyt paremmin, ei ihan oo kerinny
lukemaan kaikkia uutuuksia...

Jarmo, oh1mrr


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

Re: [wsjt-devel] TAB3

[Reino Talarmo]

Jarmo,

Free text on edelleenkin Tab 1 Tx5. Siihen kirjoitetun tekstin saa
talletettua Return näppäimellä ja lista talletetuista tulee
oikeanpuoleisella menunappulalla. Muuten kaikki Tx1 - Tx6 kentät voi
editoida, mutta vain Tx5 säilyy suljettaessa.

73, Reino OH3mA

-Original Message-
From: jarmo [mailto:oh1...@nic.fi] 
Sent: 6. tammikuuta 2021 11:10
To: wsjt-devel@lists.sourceforge.net
Subject: [wsjt-devel] TAB3

Now I see 2 tabs. 1st is where can cq, 2nd seems to be fox mode tab? Where
is free text tab?
2.3.0-rc3

Jarmo, oh1mrr


___
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

[wsjt-devel] TAB3

[jarmo]

Now I see 2 tabs. 1st is where can cq, 2nd seems to be
fox mode tab? Where is free text tab?
2.3.0-rc3

Jarmo, oh1mrr


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