rigctl server and new hamlib used by WSJT-X

[frspin]

Version 2.5.4 of WSJT-X use a new command for setting frequency: F VFOX [freq]

where X is A|B and so

but rigctl server in SDR++ is awaiting only a command as:

F [freq]

Regards

Franco Spinelli IW2DHW

[AlexandreRouma]

duplicate of #573 please follow that issue instead

[lwvmobile]

Just for clarity, which of these syntax is the 'correct' syntax? I currently have DSD-FME written to use the F [freq] approach, and that works just fine in SDR++ and GQRX. If this gets changed, then its going to break compatibility with one or the other, so I'll have to write additional lines to retry with the new syntax if the old syntax returns RPRT 1.

[frspin]

Il 29/12/22 09:04, lwvmobile ha scritto:

Just for clarity, which of these syntax is the 'correct' syntax? I currently have DSD-FME written to use the F [freq] approach, and that works just fine in SDR++ and GQRX. If this gets changed, then its going to break compatibility with one or the other, so I'll have to write additional lines to retry with the new syntax if the old syntax returns RPRT 1.

As far as I know there is no "correct" syntax.

Many programs, also rigctl, send F [freq] but WSJT-X (current version, not beta) send F [vfo] [freq]. So the correct behavior for SDR++ is to test how many tokens are in command. 2 tokens mean F [freq], 3 mean F [vfo] [freq]

Regards

Franco Spinelli IW2DHW

[ve9qrp]

I ran "nc -l -p 4532" to sniff what additionally WSJT might request. I found that when pressing the 'Test CAT' button on the Radio Settings tab, it called the following before timing out with an error: \chk_vfo \dump_state

In fact, it will start any session with checking these, and I couldn't get it to start a simple frequency request without doing so. The TLDR is that minimal compatibility with WSJT will require a valid response to these two Hamlib commands alongside any sort of frequency control.

[ve9qrp]

The attached pexpect script was written to keep WSJT-X happy in querying a hamlib port. It's based on sniffing the corresponding responses of gqrx, whose code of course works and might be a good starting point for developing the corresponding code in SDR++. It of course does not accurately report the state of SDR++. However, it does show just how extensive the WSJT-X querying is before it gets to simply asking to change the frequency! expect_wsjt.zip

[AlexandreRouma]

I already know about all of that. I just do not have time to work on that stuff at the moment.

[ve9qrp]

I apologise. I didn't mean to set an agenda for you: you're already doing so much great stuff! I just thought I'd document the issues for anyone who is interested.