IC-705 WiFi to rigctl

I have successfully connected and controlled an IC-705 over my network using wfview and rigctld. The radio can be connected to wfview either by USB or WiFi.

Everything would be great but for two problems:

The USB connection radiates a great deal of noise which endless combinations of cables and ferrites have been unable to squelch.

While the noise goes away with WiFi (and also produces a much faster waterfall), my problem would be solved except:

The screen on all 8 of my computers, including old and new desktops, laptops, Surfaces, and all-in-one’s go black randomly when and only when wfview is running. Unfortunately, this renders the computer useless for any other tasks.
https://forum.wfview.org/t/m803-marine-ham-transceiver/2149/21

I thought perhaps wfserver would be just the thing. If it could connect to the radio via WiFi, and act as a rigctld server, no USB noise, and without a GUI, nothing to mess with the screen.

So I downloaded and compiled the source, but can’t find any settings which bridge the radio via WiFi to rigctld as wfview does.

I would be delighted if anyone could outline how that might be done with wfserver.

wfserver does not contain rigctld.

I am confused about the screens going randomly black. As it is happening on all of your machines, it is more likely something specific to the configuration of YOUR machines, as none of the many 100s of other wfview users has ever reported anything like this. Can you explain exactly what is happening as it may be interaction with other software installed on the machines? It would also help if you could give some indication of what operating system(s) you are using.

The only similarity between the machines is that they are running Linux Mint 21, and when wfview starts, it is just a matter of time until the screen begins to randomly go fully black (except the mouse pointer), partially black, normal, repeat …

It doesn’t matter whether wfview is in focus or not or minimized or not, or what page it is on, or whether the waterfall is on or not. I originally thought the Surface was fine until it was not. It does seem to happen faster if connected via WiFi.

This phenomenon does not occur with any other program I use, including graphically intensive programs such as DaVinci Resolve. From dual Xeon dual nVidia to a Microsof Surface, the screen will go blank, it’s just a matter of when.

I have installed, many many more wfview instances on all linux and windows and yes even those surface pro’s None of them even showed signs of black screens icm wfview.

For the linux part: using X or wayland?

In any case: you are as far as I know the only one who has it on several systems, which leads to backing up what Phil says: it’s an issue on your end and may even be a setting you love so much that you applied it to all the systems.

There are no settings that have been applied to all the systems.

All are clean installs from Mint 21, which uses X. Some are 21.2 and some upgraded to 21.3. While the desktops have had many intensive audio-visual programs added, some, like the the Surface Pro’s, have had nothing whatsoever added other than as needed by the install.sh to build wfview.

Eight vastly different machines with the identical problem with only one program, but it has nothing to do with the program?

I’ve been tracking down program glitches for over 5 decades. Right now, I don’t have the time. So:

  • I will pay $500 to the first person who can convincingly demonstrate that the black screens are not caused by wfview.

  • I will also pay $500 to the first person who can fix the problem, i.e., provide a bridge between an IC-705 WiFi, and rigctld, as wfview currently does quite well but for the black screen.

That could involve fixing wfview, or it might be as simple as omitting to “show()” the main window of wfview. It could be grafting code to control the IC-705 via WiFi which is already in wfview to wfserver or rigctld, or gluing together existing code into a daemon bridge. No audio required, just rig control.

Naturally, the argument that since it has not happened to you personally, therefore it does not exist, does not qualify for either of the above.

Any solution offered would necessarily be open source.

Cheers,

Noel Sterrett, NO1N

Hi Noel,

I agree that simply because it doesn’t happen for one person does not imply it does not happen for anyone!

I’ve been using Mint since around version 17 or 18 basically exclusively and I personally have not seen this issue. I’m on Mint 21 (kernel 6.2) on an AMD Thinkpad (radeon graphics via the iGPU) at the moment.

Do you have DaVinci on all these systems? Can you check if it’s hung in the background and running?

What GPU are you using and what set of drivers?

Have you tried temporarily halting ACPI in case it is some kind of malfunctioning power management? I have seen things like this happen on Ubuntu with other programs, but it is rare.

We will get it figured out!

–E
de W6EL

Hi Noel,

You should also be open to the fact that as it only happens to you, it is quite likely to be something specific to your environment. wfview uses the Qt framework, are you aware of any other programs that you use which do not exhibit this particular issue also being Qt based?

As an experiment, I have just installed Mint and wfview on a Satellite Pro laptop (C40-H103) using the process below, please can you let us know if your process has deviated from the below in any way? I assume you are installing wfview from source, not using the pre-packaged Linux download?

  1. download: linuxmint-21-cinnamon-64bit.iso
  2. write to 8GB USB stick with Rufus
  3. Press F2 to run setup and disable secure boot
  4. Boot Satellite Pro with USB stick
  5. Plug network connection into laptop
  6. Select option “Start Linux Mint 21.2 Cinnamon 64-bit”
  7. Once booted, select “Install Linux Mint”
    a. Language: English
    b. English (US)
    c. Select “Install Multimedia Codecs”
    d. Select “Erase disk and install Linux Mint”
    e. Reboot and remove USB stick
  8. Once booted, Run driver manager to check for any additional drivers (none required)
  9. Open Firefox and browse to https://wfview.org
  10. Download https://gitlab.com/eliggett/scripts/~blob/master/fullbuild-wfview.sh
  11. Open terminal
  12. cd ~/Downloads
  13. chmod a+x fullbuild-wfview.sh
  14. ./fullbuild-wfview.sh
  15. Press Y to install dependencies and enter your password when requested
  16. Press [enter] to download wfview’s source code
  17. Press enter to start compiling
  18. wait a while
  19. Press Y to install wfview
  20. Enter wfview to start program
  21. Select Settings tab:
    a. Select Network
    b. Enter IP address of radio in Hostname
    c. Enter username/password
    d. Return to View tab, select “Save Settings”
    e. Click “Connect to Radio”
  22. Enjoy wfview

DaVinci on Linux only really works with nVidia GPU’s and only if they have sufficient memory (I think at least 4 GiB). The desktops (Xeon, Threadripper) have 1080’s, currently with nvidia-driver-535.

Two of the laptops also have nVidia cards. One a Gigabyte with a 3060 GPU, another is an Asus ROG with a similar GPU. The Surface Pro’s don’t support DaVinci at all.

While all are updated periodically, and on kernal 5.15, none are exactly the same, and the nVidia drivers vary somewhat.

A few small telltales are that the mouse never disappears, the black screen only appears when a radio is connected, and the screen can be restored, at least temporarily, with a ‘Print Scrn’. The screen also cycles between black and partially black with rectangles of varying sizes and shapes, sometimes matching a full or partial program window.

It takes place only when ‘connected’ with either USB or LAN, but seems to trigger quicker with LAN.

Power options for the desktops and some of the laptops is ‘never’. The screensavers are on.

I’m traveling today, but will try turning everything off and see if that makes a difference.

There is one thing I do which is not ‘stock’. Installing/upgrading nVidia drivers once was quite problematic, so use ‘systemctl set-default multi-user.target’, login, and then ‘startx’ to boot.

While I have nothing to back it up, my gut tells me this is related to the USB/LAN/Audio I/O and not the GUI. Something is stepping on something is shouldn’t. In one instance, I noticed wfview was using over 2 GiB of memory and climbing steadily.

If it were not for the fact that it is happening on all my machines, and no other program is doing anything remotely similar, I would not be as certain that it is related to wfview.

Thanks for the help.

Noel

I found these https://wiki.qt.io/List_of_Qt_Applications:
Clementine
qjackctl
VLC
Wireshark
musescore

and as above,

DaVinci Resolve, and my own rig controller written in PyQt 5.

What you outlined is what I did with the following additions:

GRUB_TIMEOUT_STYLE=menu
GRUB_TIMEOUT=5
sudo update-grub
sudo update-initramfs -u
systemctl set-default multi-user.target
reboot
login
startx

Perhaps the question is: How could you create this behavior without wfview?

Different pieces of the screen are being alternatively displayed:

  • Full view
  • Black screen but with mouse
  • Partial view of a program window but with the date/time and mouse
  • Black screen with mouse
  • Different partial view of different non Qt application
  • etc…

Then, the question would be how could wfview do that?


Cheers,

Noel

Using nvidia drivers? Or open source?

Noel,

Did you compile wfview from source or use a package or other binary install? We strongly recommend that you use our build script and compile from source (it’s a single command). But perhaps you already got that far.

Since Resolve installs it’s own QT runtime, it may be that you have two conflicting libraries.

Can you also please send us a log file?

https://wfview.org/wfview-user-manual/how-to-send-a-logfile/

Thanks,

—E
de W6EL

Elliott,

I compiled from source using the amazing install.sh.

So easy! No more 'you’re missing libxxx, so get libxxx, then another …

I don’t think it’s a Qt runtime conflict since several machines have never had Resolve installed.

I’ll send a log, but I doubt wfview is aware or perhaps could even detect tha anything has happened to the screen. It runs as though the screen was visible, controls the radio, and appears on the LAN as rigctld. It keeps working, It’s just that the screen is a bit discombobulated.

And the video drivers?

Nvidia 535 was mentioned earlier, but unknown if all computers have the same version.

Use the open source versions and retest

I don’t DaVinci will work that way. But I could be wrong.

I tested wfview using mint and the proprietary nvidia drivers and it worked just fine.

I know but to test stuff to rule out $Op needs to disable it and retest.

There are all MINT installs, right? Is Mint Wayland now? or Xwayland? The move from X11 on some distros breaks things that are not ‘mainstream’… For example, legacy games like UNREAL (nVidia required) fail in Wayland, as do some cross-platform remote desktop servers, causing white screens on clients.

Microsoft Surface Pro’s do not have nVidia GPU’s, cannot use DaVinci Resolve, and no drivers other than those in a clean install are in use. Yet as can be seen, the Surface has the same problem.

If you take a look at the lower image above, only a part of wfview is displayed. The top and bottom sections are missing. My guess is that the section displayed corresponds to a layout or portion of a layout in Qt.

In other cases, other portions of, and sometimes other complete applications are displayed with the rest of the screen black. They are all rectangles of varying shape.

Does Qt even have the mechanism and permissions necessary to display portions of other applications and leave the rest black?

If not, what processes do have permission to do that to other applications?

Like all programs, without a camera pointed at the screen, wfview cannot know what is displayed on the screen, only what it has attempted to display on the screen.

Could you run with QT_DEBUG_PLUGINS=1 and send the output to see what is actually loading. QT can interfere with X rendering a number of ways as can USB/networking causing scheduler stalls, etc. You aren’t running the Cinnamon Wayland alpha are you? I think not since that is a 21.3 release item I believe. When the screen issues start are there any error outputs in the kernel ring buffer (dmesg)?