HI Kari, That was a worthwhile experiment, but unfortunately, I also get the exact same behavior between 2 wsjtx 2.4 instances (compiled from source) with rgctld-wsjtx showing hamlib v4.2.
I'm pretty sure this is not a hamlib problem, but rather wsjtx improperly assuming that the get frequency command was safe to use on any radio type as a basic connectivity test. (And 25 years later, the misery of the FT-736r cat implementation continues... 🙂 ) I'm pretty sure I can hack the code to remove this command from the "Test Cat" routine (after a crash course in c++), or could insert an impersonator between wsjtx and rictld-wsjtx if the situation got truly dire, so I'm not blocked, but wanted to mention it in case anybody else goes down this path. --al WB1BQE ________________________________ From: Kari Sillanmäki via wsjt-devel <[email protected]> Sent: Sunday, July 18, 2021 7:56 PM To: alawler mudhawk.com via wsjt-devel <[email protected]> Cc: Kari Sillanmäki <[email protected]> Subject: Re: [wsjt-devel] Possible bug between wsjtx and net Hamlib 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 [email protected]<mailto:[email protected]> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
_______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
