First thank you for a very nice app. I’ve been trying to compile it under the latest version of MX Linux, but that distro does not contain the needed or correct version of required libraries. Same applies for the pre-compiled binary.
So, I am running the Windows version of wfview along with an Icom 7300. Occasionally used in conjunction with WSJT, the 7300 will get “stuck” in transmit as WSJT cycles between transmit and receive. Unclicking “Enable TX” or clicking “Halt TX” or exiting WSJT completely does not restore the 7300 to receive. Most of the time, when this occurs, I can toggle the “Transmit” button in wfview to return to receive. However, on a few occasions, I’ve had to turn the 7300 off and then back on.
PC has an I7 processor, 32 GB RAM, and latest update of Windows 10 Pro.
Thanks for the reply. Don’t think it has anything to do with RF. Have two toroids, in series, each with 10 turns of a USB extension cable through them. Also have one toroid with 8 turns on the power supply cable thorough it.
With Windows, I can use flrig, Ham Radio Deluxe, and Win4IcomSuite with same cabling, power supply, computer, etc. without issue. When booted into Linux, I use flrig without issue.
Most of the time when things gets stuck, I can toggle “Transmit” in wfview and return to receive. Sometimes it is necessary to exit wfview completely to return to receive, and in one instance, had to turn off the Samlex power supply.
This precludes me from attempting to run remotely.
MX Linux is a distro packaged and maintained by anti-X and MX Linux developers and is based upon Ubuntu and Debian. Most debians will install and run without issue.
I’ve been using Linux since 1988 and have found that systems can sometimes be broken by updating and/or installing packages that are not in their respective repositories.
This is a dual boot machine and just booted into Windows yesterday to see if I could use wfview. Until yesterday, I’ve used Linux exclusively since March 25.
MX Linux is a distro packaged and maintained by anti-X and MX Linux developers and is based upon Ubuntu and Debian. Most debians will install and run without issue.
I’ve been running on the Linux partition of this PC since March 25, 2023 and only yesterday, booted into Windows to be able to evaluate wfview.
The next time I boot back into Linux, I’ll attempt to install the pre-compiled binary and get a list of what is missing. The instructions for installing what is needed are very good. However, since I’ve already tried three times, I will probably not be successful. I’ll also attempt to compile again, but think there will be a similar issue.
I’m reluctant to install updated packages and sometimes missing packages beyond what the MX repository has.
I ran “timeshift” to create a working backup of the Linux system prior to attempting to install wfview.
Then after I was unsuccessful, a couple of " sudo apt-autoremoves" followed by a search of the OS to find where wfview was installed. I manually deleted wfview.
An appimage, snap, flatpak, etc. would be helpful, but I recognize that this would require considerable effort to accomplish.
Have been running the Linux version of Wfview for a week now and am experiencing the same transmit/receive issue that occurred with the Windows version. I am using an Icom 7300.
The issue appears to be related to the amount of time Wfview and WSJT-X are used together.
When making a FT8 contact, all is well for about a half hour or so. After that either:
When WSJT calls for “receive”, the 7300 remains in transmit, but no RF comes from the radio, or
When WSJT calls for “transmit”, the 7300 remains in receive.
Ctrl-R usually will remedy the stuck “transmit”, but has no effect on stuck “receive”.
This morning, Ctrl-R did not get me out of stuck “transmit”, nor did closing Wfview. I had to cycle the IC7300 power button and restart the radio.
As a workaround, I now close Wfview and WSJT every half hour, and then restart both. Things work well until a half hour elapses. Not sure if just leaving the two apps running and not attempting to make contacts with WSJT would make a difference.
I have occasionally experienced this behaviour and attribute it to uncorrected errors on the Internet connection, particularly WiFi. You might try using a 5 GHz connection and see if it makes a difference. It did for me.
Just to be clear on the connections here. Not using a network connection, neither WiFi nor Ethernet, right? You’re running WSJT-X and Wfview on the computer which then has a USB connection directly to the IC-7300, correct? So only internal IP networking, from WSJT-X to port 4533 on the loopback interface?
Yes Sam. Access is via the Icom USB adapter. No external access, all via internal IP. The same connections as are used with Flrig.
I am able however, to run a Hermes Lite II remotely via SparkSDR on this same machine. HL2 connected to eth0 and controlled by Spark. Remote access via 5 gHz wifi.
This topic comes-up pretty-much every week! (please use the search function)
We are aware of the issue and it is a fundamental problem with the way that the rigctld emulation works and is NOT an easy fix.
I am currently re-writing much of the rig handling code and have addressed this problem. You can try reducing the polling frequency within wfview to mitigate the issue.
Per Phil’s suggestion, I started using “Manual Polling Interval” instead of “Auto Polling”.
I started with an interval of 120 ms and then increased by 20 ms each day. At 200 ms, I was having no issues with transmit/receive. Updates to WSJT were a bit slow when a frequency was entered via Wfview. I reduced the polling to 180 ms and that reduction of 20 ms helped a bit.
I’ve run Wfview for a week now with zero transmit/receive problems.
Radio is an Icom 7300, computer is Dell 9020 with a I7 processor, and OS MX Linux 21.3.
Linux Mint, IC-7610, wfview, WSJT-X (built recently from their code repo). I connect WSJT-X to wfview using wfview’s built-in rigctld server. Default polling interval. wfview was connected to the 7610 USB port, just as you might do with a 7300. I use the USB port when I’m at the 7610, and I use the LAN if I am in another room.
I ran it for three weeks (transmit and receive) doing a little propagation study with WSPR mode. No issues.