IC7300 - Issue with Wfview and WSJT-X: Client Hijacks Control from Server

1

Hello everyone,

I recently discovered this fantastic software, Wfview, and have been experimenting with it. However, I’m encountering an issue with my setup where the client Wfview seems to override control, causing problems with frequency changes on the server. Here’s my setup:

Setup Details:

  • Radio: IC-7300 connected via USB
  • Server-PC: Windows 10, connected to the radio, running:
    • Wfview v2.03 (with Radio Server and External Control (rigctld) enabled)
    • WSJT-X 2.7.1-devel improved plus (Hamlib 4.7)
  • Client-PC: Windows 10, connected to the server via wired Ethernet, running Wfview v2.03
  • Goal: Use WSJT-X on the client-PC while maintaining full control and audio functionality.

What Works:

  1. On the Server-PC, Wfview and WSJT-X work perfectly together:
  • Changing bands or frequencies in WSJT-X updates the radio and Wfview immediately.
  1. On the Client-PC, Wfview connects to the server without issue:
  • Frequency changes on the client’s Wfview are reflected on the radio and the server’s Wfview.
  • Audio from the radio works correctly on the client-PC.

The Problem:

When the client’s Wfview is running:

  • WSJT-X on the Server-PC stops functioning as expected:
    • If I try to change bands or frequencies in WSJT-X on the Server-PC, the change reverts back within seconds.
    • This behavior persists until I close Wfview on the Client-PC.
  • Control Priority Conflict:
    • It seems the Client-Wfview “hijacks” control of the radio, preventing any changes from being made via WSJT-X or Wfview on the Server-PC.

When I close Wfview on the client:

  • WSJT-X regains control:
    • I can change frequencies or bands from WSJT-X on the Server-PC again.
    • However, with Wfview closed on the client, there’s no audio stream available on the Client-PC.

Additional Observations:

  • On the Client-PC, I’ve configured WSJT-X to connect to the rigctld server running on the Server-PC via its LAN IP. This allows WSJT-X on the client to control the radio, but only if the client’s Wfview is closed.
  • Enabling “External Control” in the client’s Wfview does not open any rigctld ports for WSJT-X on the Client-PC to connect.
  • Downgrading to Wfview v2.01 and using Hamlib 4.5 in WSJT-X produces the same behavior.

My Question:

How can I configure Wfview and WSJT-X so that:

  1. I can run Wfview on both the Server-PC and Client-PC simultaneously.
  2. WSJT-X can change frequency or bands from either the Server-PC or Client-PC.
  3. Audio streaming works on the Client-PC without breaking WSJT-X control on the Server-PC.

Has anyone else encountered this issue or found a solution for similar setups? Any advice would be greatly appreciated!

Log from Server when I try to change frequency from WSJT-X on server pc via rigctl, when client Wfview is running:

2025-01-22 18:35:52.788 DBG rigctld: 3828 TX: "VFOA"
2025-01-22 18:35:52.788 DBG rigctld: 3828 TX: "\n"
2025-01-22 18:35:52.788 DBG rigctld: 3828 RX: "s"
2025-01-22 18:35:52.788 DBG rigctld: 3828 TX: "0\n"
2025-01-22 18:35:52.788 DBG rigctld: 3828 TX: "None"
2025-01-22 18:35:52.788 DBG rigctld: 3828 TX: "\n"
2025-01-22 18:35:52.789 DBG rigctld: 3828 RX: "f"
2025-01-22 18:35:52.789 DBG rigctld: 3828 TX: "10155000" # Current frequency
2025-01-22 18:35:52.789 DBG rigctld: 3828 TX: "\n"
2025-01-22 18:35:52.790 DBG rigctld: 3828 RX: "m"
2025-01-22 18:35:52.790 DBG rigctld: 3828 TX: "PKTUSB\n"
2025-01-22 18:35:52.790 DBG rigctld: 3828 TX: "3600"
2025-01-22 18:35:52.790 DBG rigctld: 3828 TX: "\n"
2025-01-22 18:35:52.791 DBG rigctld: 3828 RX: "t"
2025-01-22 18:35:52.791 DBG rigctld: 3828 TX: "0"
2025-01-22 18:35:52.791 DBG rigctld: 3828 TX: "\n"
2025-01-22 18:35:53.282 DBG rigctld: 3828 RX: "F 7074000.000000" # Trying to set new frequency from WSJT-X
2025-01-22 18:35:53.282 DBG rigctld: 3828 TX: "RPRT 0\n"
2025-01-22 18:35:53.287 DBG rigctld: 3828 RX: "v"
2025-01-22 18:35:53.287 DBG rigctld: 3828 TX: "VFOA"
2025-01-22 18:35:53.287 DBG rigctld: 3828 TX: "\n"
2025-01-22 18:35:53.794 DBG rigctld: 3828 RX: "v"
2025-01-22 18:35:53.794 DBG rigctld: 3828 TX: "VFOA"
2025-01-22 18:35:53.794 DBG rigctld: 3828 TX: "\n"
2025-01-22 18:35:53.795 DBG rigctld: 3828 RX: "s"
2025-01-22 18:35:53.795 DBG rigctld: 3828 TX: "0\n"
2025-01-22 18:35:53.795 DBG rigctld: 3828 TX: "None"
2025-01-22 18:35:53.795 DBG rigctld: 3828 TX: "\n"
2025-01-22 18:35:53.796 DBG rigctld: 3828 RX: "m"
2025-01-22 18:35:53.796 DBG rigctld: 3828 TX: "PKTUSB\n"
2025-01-22 18:35:53.796 DBG rigctld: 3828 TX: "3600"
2025-01-22 18:35:53.796 DBG rigctld: 3828 TX: "\n"
2025-01-22 18:35:53.797 DBG rigctld: 3828 RX: "t"
2025-01-22 18:35:53.797 DBG rigctld: 3828 TX: "0"
2025-01-22 18:35:53.797 DBG rigctld: 3828 TX: "\n"
2025-01-22 18:35:54.289 DBG rigctld: 3828 RX: "v"
2025-01-22 18:35:54.289 DBG rigctld: 3828 TX: "VFOA"
2025-01-22 18:35:54.289 DBG rigctld: 3828 TX: "\n"
2025-01-22 18:35:54.290 DBG rigctld: 3828 RX: "f"
2025-01-22 18:35:54.290 DBG rigctld: 3828 TX: "10155000" #Old frequency still active.
2025-01-22 18:35:54.290 DBG rigctld: 3828 TX: "\n"
2

I don’t think we have written wfview to actually work that way (locally providing rig control) when functioning as a server. I can see how it would be desirable though.

3

This is intentional, there is a setting called:

Disable local user controls when in use (restart required)

Uncheck this and the server will be usable when there is a client connected.

Phil

4

Thank you for the explanation—it really clarifies the issues I’ve been experiencing. It seems to align perfectly with what I’ve observed. Perhaps this could be addressed in future updates? I’m a bit surprised that more people aren’t using Wfview in a similar setup.

I don’t necessarily need to control the radio from the server while the client is connected. Running the server headless would work perfectly for me, but I understand that this isn’t an option at the moment.

To make things work more seamlessly, one of the following would be ideal:

  1. Allow rigctl commands to be accepted by the server even when a client is connected.
  2. Enable the client to run its own rigctld instance, so WSJT-X (or other applications) can connect to rigctld on the client.

The GUI on the client does allow enabling rigctld, but when I try, I see this in the logs:

2025-01-22 18:34:53.040 INF rigctld: could not start on port  4534

Is it by design that rigctld cannot be started on the client? Or is there something misconfigured on my system? If this limitation is intentional, would it be difficult to allow this functionality? It seems like it would be similar to what the server already does. This way, users could choose to control the radio via the client’s interface or connect WSJT-X (or similar software) to the rigctld instance on the client.

5

That means that something is already listening on that port.

6

I saw you reply after writing my reply. I saw this option in some pictures somewhere I think, but I cannot find it anywhere in the 2.03 version.

7

I have double checked, and nothing is using that port. I also tried other ports, but it refuses to start on client. No issue on server.

Ports that are in use by Wfview
image

Here are the only ports on 4xxx that are in use by any application:
image

8

It definitely does allow enabling it. Try saving settings and restart wfview.

9

I have tried many times. Here are the settings. Tried other ports also. Tired to run it as administrator.

image
image966×304 13.4 KB

After startup I checked the log again and get this line:

2025-01-22 21:29:51.348 INF rigctld: could not start on port  4534

This setting you mentioned to allow local control on server, where is that one in v2.03? I looked again and are not able to see it anywhere.

10

It looks like that setting didn’t make it into 2.03, it will be in the next version.

Not sure what to tell you about rigctl as it certainly should work. It makes no difference whether wfview is working as a client or server, so I would check any other security software/firewall that might be blocking it.

11

Do you know the last version that had this setting? Maybe I can use that version until the new one is released?

I’ll dig more here and see if anything is preventing it to start. At least now I know it should work.

Thanks for the help so far.

12

It is a new setting, although v1.64 didn’t disable the local client so you can use that.

13

Great, will try and post back the result. Thanks a lot for the help.

14

For anyone else that may have the same problem I have made it work by running v1.64 on server. I can still use the v2.03 as client. Now WSJT-X works on both computers, even at the same time…

Since at least I’m not able to run the rigctrld on client, just configure the Client-WSJT-X to use the IP:Port of the Server for cat control.

Now everything can be controlled from everywhere.

Again thank you very much for the help.

73