Release 1.2c (was 1.2b) for testing need volunteers ;-)

today we’ll push out 1.2b – some more testing is needed in the rigctld area:

if you use wsjtx etc – please try and use rictld instead of pseudo serial ports and the like
to connect to wfview.

The following highlights are in this 1.x-release:

    many changes/mods/updates/enhancements to rigctld
    rigctld box added in the UI
    build process changed: you  can add the install prefix (derSuessmann)
    added "do not ask again" for switching off rig and exiting wfview
    added opus as audio transport 
    dual meter support
    rigctl basic split support
    rigctl prevents switching off civ transceive
    added 25 kHz step

if ll goes well, we’ll push out v1.2 soon.

1 Like

Can you explain how to use rigctld when using Log4OM and WSJT-x controlled via OmniRig at the server side?
I see COM3 as Port choice, does it mean that in OmniRig Rigctld is selectable as input Port?
I have never used Hamlib and Rigctld.

73, Fred

Hi Fred.

The whole point of using rigctld emulation is so that you can avoid the need for OmniRig. Both WSJT-X and Log4OM can connect directly to the wfview rigctld, I will be writing a manual page for this in the coming days but basically you just need to select the rig as rigctld within WSJT-X and Log4OM.

73 Phil


Hi all,

The Windows 1.2b release is now available for download. I won’t be able to do the MacOS build until later today.

73 Phil


connecting WSJT-X to wfview via rigctld does not work here.
(IC-7300, Debian 11)

wfview log:
2021-09-07 18:14:39.597 INF rigctld: started on port 4533
2021-09-07 18:14:39.675 INF rigctld: Got rigcaps for: “IC-7300”
2021-09-07 18:15:02.213 INF rigctld: session connected: 32
2021-09-07 18:15:02.213 INF rigctld: no rigState!
2021-09-07 18:15:03.214 INF rigctld: no rigState!
2021-09-07 18:15:04.218 INF rigctld: no rigState!
2021-09-07 18:15:05.216 INF rigctld: session connected: 33
2021-09-07 18:15:05.217 INF rigctld: no rigState!
2021-09-07 18:15:06.218 INF rigctld: no rigState!
2021-09-07 18:15:07.218 INF rigctld: no rigState!
2021-09-07 18:15:08.219 INF rigctld: no rigState!
2021-09-07 18:15:09.220 INF rigctld: 32 disconnected
2021-09-07 18:15:09.221 INF rigctld: no rigState!
2021-09-07 18:15:10.222 INF rigctld: 33 disconnected

WSJT-X connects to wfview and is sending commands to wfview (I can see that in wireshark). wfview is answering with tcp
packets without any data (I see only the tcp headers).

vy 73

Hi Uli.

The no rigState! messages are a critical error which means that rigctld hasn’t received the rigState information. I have just checked the source code and sure enough, it is not setting the initial rig state when connected over USB (my testing has been done almost exclusively over LAN).

I have just pushed a 1 line fix to master which should address this. As you are on Debian, can you try this fix? This kind of report is exactly why we beta test :slight_smile:

73 Phil M0VSE

I have put 1.2c for linux on the downloads page

Windows version is now up as well. This definitely fixes the rigctld issue with USB/Serial connected rigs!

Phil just got a post about the new rigctrl is not compatible with rasping, I’ll try and find the link. It’s Jason ACK on YouTube that does all the work on raspi for amateur radio

So let me ask about rigctrl…what does this get me? I’m running Flrig alongside wfview because for the moment Flrig has more functionality. Is there any advantage to me using rigctrl?

Harry Bloomberg W3YJ

Hi Harry.

If you are “only” using flrig then no as flrig is not compatible with rigctld. If you also use fldigi/wsjt-x or any other program that ‘does’ support rigctld, then I strongly advise you to use it. The two are not mutually exclusive, rigctld just allows multiple applications to share the rig. There is nothing stopping you also also using flrig via a virtual serial port.

73 Phil


Thanks! I will have to give it a try.

Harry W3YJ

Hi Mike.

It isn’t really new, it has been ‘hidden’ within wfview since v1. I would be very surprised if it isn’t compatible as one of my test setups is a Pi4 connected via USB to an IC7100.

73 Phil

In 1.2b I enabled Rigctld, virtual Port: none
In WSJT-x I selected Hamlib NET rigctl as radio, and used address 4533.
Did a Test CAT, got a error message CAT test falied

Are my Settings correct?

73, Fred

Hi Fred.

If you are connecting to a USB radio (IC7300 etc.) then you will need 1.2c which was released a couple of hours ago as we discovered a problem with 1.2b that only affects USB connected rigs!

73 Phil M0VSE

Hi Phil,

with this fix WSJT-X via rigctld is now working here.

There is now another strange problem:
(IC-7300, Debian 11, wfview 1.2c)

Switching to TX by activating the Tune button in WSJT-X does not always work.
Sometimes WSJT-X shows that it is in TX mode, but wfview shows that it is receiving.

Switching to TX (and back to RX) by activating the button in wfview does always work.
I have also tested WSJT-X without wfview with hamlib rigctld, then the error does not occur.

It seems that when using the wfview rigctld emulation sometimes commands from wsjtx to wfview get lost.

vy 73

Hi Uli.

I can’t replicate that issue, every time I click TUNE in WSJT-X my rig goes into TX. Can you confirm that you have “PTT Method” set to CAT within WSJT-X? I have tried this both with a USB and LAN connected rig on Windows, Linux and MacOS.

73 Phil M0VSE

I tried 1.2c on my Windows PC but WSJT-x is not able to control my IC-7300.
The com port to my 7300 is COM3.when running WSJT-x directly with my 7300.

Settings in wfview: Rigctld enabled, Port 4533, virtual Port: none (also tried COM3)
In WSJT-x I selected Hamlib NET rigctl as radio, and port 4533.

Let me know if these settings are complete and correct.

73, Fred

Hi Phil,

yes, in WSJT-X ‘PTT Method’ is set to CAT.

So far I tested only with my IC-7300.
It is well past midnight here, so i will do more testing tomorrow evening.

73 Uli DF7SC

hi Fred,

  • does wfview work an has control w/o wsjtx?
  • if so if you start later wsjtx – do you use ? (e.g. use localhost)

if your s/w can use rigctld then just completely forget com ports when configuring this.
(obviously not the com port you used to talk to with wfview; no virtual ports further nor
serial ports on other external software or helper programs that mimic serial ports).