Bug 2218894 - Hamlib NET rigctl connection of Gqrx with WSJT-X does not work anymore
Summary: Hamlib NET rigctl connection of Gqrx with WSJT-X does not work anymore
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: hamlib
Version: 38
Hardware: Unspecified
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Richard Shaw
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-06-30 13:26 UTC by Daniel Rusek
Modified: 2023-07-14 13:08 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: ---
Embargoed:


Attachments (Terms of Use)
Gqrx remote control config (16.44 KB, image/png)
2023-06-30 13:29 UTC, Daniel Rusek
no flags Details
WSJT-X remote control config (80.09 KB, image/png)
2023-06-30 13:30 UTC, Daniel Rusek
no flags Details

Description Daniel Rusek 2023-06-30 13:26:26 UTC
Originally reported as rhbz#2218889, but it seems to be a hamlib regression.

I am using a Gqrx SDR in combination with WSJT-X. Everything used to work fine, however it looks like that the Gqrx control in WSJT-X using "Hamlib NET rigctl" recently stopped working. See the additional info for complete error message from WSJT-X. Also see the attached screenshots for my rig control configuration.

"nc 127.0.0.1 7356" seems to work fine and I can communicate with Gqrx, set or read frequency etc. without any problem, however the rig control in WSJT-X does not. It also happens with Flatpak version of WSJT-X that uses the same (4.5.5) version of hamlib and downgrading Gqrx did not help which makes me believe that it is actually a hamlib regression.

Reproducible: Always

Additional info:
Hamlib error:   2:rig.c(7481):async_data_handler_start entered
async_data_handler_start: async data support disabled since async_data_enabled=0
  2:rig.c(7488):async_data_handler_start returning(0) 
rig.c(254):add_opened_rig returning2(0) 
rig_open: 0x562b105dab2c rs->comm_state==1?=1
  2:rig.c(6084):rig_get_powerstat entered
rig.c(6104) trace
netrigctl_get_powerstat called
netrigctl_transaction: called len=15
rig_flush: called for network device
network_flush called
write_block(): TX 15 bytes, method=2
0000    5c 67 65 74 5f 70 6f 77 65 72 73 74 61 74 0a        \get_powerstat. 
read_string_generic called, rxmax=1024 direct=1, expected_len=1
read_string_generic(): RX 7 characters, direct=1
0000    52 50 52 54 20 31 0a                                RPRT 1.         
  2:rig.c(6109):rig_get_powerstat returning(0) 
rig_open: rig power is off, use --set-conf=auto_power_on if power on is wanted
Rig is not powered on
Rig is not powered on
 while opening connection to rig

Comment 1 Daniel Rusek 2023-06-30 13:29:54 UTC
Created attachment 1973406 [details]
Gqrx remote control config

Comment 2 Daniel Rusek 2023-06-30 13:30:23 UTC
Created attachment 1973407 [details]
WSJT-X remote control config

Comment 3 Richard Shaw 2023-07-11 11:20:33 UTC
I can post on your behalf, but have you posted this to the linuxham mailing list? Michael is pretty responsive. Since the package is the latest release version there's not much I can do. I will send Michael an email linking to this BZ though.

Comment 4 mdblack98 2023-07-11 12:58:12 UTC
This has been fixed with a new rig entry in Hamlib for Quisk if you are using that?
Also a fix was added for SDR++ and Flex.

Should work for any other SDR program trying to emulate rigctld with incomplete capability.

Mike W9MDB

Comment 5 Daniel Rusek 2023-07-14 13:08:39 UTC
(In reply to Richard Shaw from comment #3)
> I can post on your behalf, but have you posted this to the linuxham mailing
> list? Michael is pretty responsive. Since the package is the latest release
> version there's not much I can do. I will send Michael an email linking to
> this BZ though.

Nope, I did not post this to the linuxham mailing list. It would be great if you could post it on my behalf. Thanks a lot!

Daniel OK2VLK


Note You need to log in before you can comment on or make changes to this bug.