Hi Al,
Your WSJT-X version 2.2.0 is quite old.
Also, your Hamlib must be even older as you are using the short model
numbers.
Hamlib shipped with WSJT-X 2.2.0 use new longer model numbers, for
example FT-736R is now model number 1010
and FT-890 is 1015.
Suggest you upgrade to current WSJT-X version 2.4.0 and also make sure
that correct version of Hamblib are being used.
73's de Kari, oh2gqc
On 18.7.2021 17.44, alawler mudhawk.com via wsjt-devel wrote:
HI Folks,
I've encountered what seems to be a bug in how wsjtx uses the
network hamlib functionality. I'm going to start with a simple
symptom statement, then will include more supporting detail and the
specific configuration etc.
The problem:
wsjtx does not work with a remotely connected Yaesu FT-736r using the
Net Hamlib option.
Symptom:
During setup, when I set Hamlib NET Rigctl in the radioconfiguration
information and click "Test Cat", I get an error message box
saying "Rig Failure" "Hamlib error: Feature not available while
getting current frequency".
What I think is happening is that for a locally connected radio,
wsjtx is "smart enough" to not send a "get frequency" command to the
FT-736r, however, in the Net Rigctld mode, it makes an assumption
that this is a relatively safe and widely supported way of testing
basic communications and sends the command without first checking rig
capabilities.
I believe this is the expected behavior from Hamlib, since the
FT-736r does not support this particular option.
Configuration:
wsjtx-2.2.0 running on Ubuntu
The radio server is a Raspberry Pi running either rigctld 3.0 or
rigctl-wsjtx 4.0 (the behavior is the same.)
rigctld command: rigctld-wsjtx -m 110 -r /dev/ttyUSB0 -s 4800 -t
10006 -vvvvv
Other test notes:
I am using port 10006 on purpose, but I don't believe that is related
to the problem.
My raspberry Pi/rigctld server works fine with other FT-736r code that
I have written, so I'm pretty sure the hardware and configuration are
correct.
hamlib trace:
igctl(d): v 'currVFO' '' '' ''
rig_get_vfo called
client lock disengaged
client lock engaged
rig_strvfo called
rigctl(d): f 'currVFO' '' '' ''
rig_get_freq called
client lock disengaged
Trying the idential experiment using my FT-890 (ritctld -m 115) which
DOES have a bidirectional CAT interface works fine.
I am looking at the code with the hopes of just bypassing the
frequency set command in my own local setup, but figured I'd mention
this in case other folks might find it useful.
Thanks for any consideration
--al
WB1BQE
_______________________________________________
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
