Waterfall feature doesn't work on GQRX 2.17.7 with Arch Linux

[Potomac]

Hello,

I use GQRX 2.17.7 on Arch Linux,

I notice that the waterfall feature doesn't work, the area is black, no graphic is displayed for the waterfall (see the attached file).

I tried the official Arch Linux package for GQRX, and also the Appimage for 2.17.7 version : same problem, no waterfall is displayed.

I use KDE plasma as desktop, Qt 6.11.1, Wayland.
Something is probably broken in QQRX 2.17.7 about the waterfall feature.

If I try an old version of GQRX (2.14.5) then the waterfall works.

[kkettinger]

Hello @Potomac,

I just tried out GQRX and came across your issue. For me the waterfall feature works in Arch (extra/gqrx 2.17.7-2):

I use KDE plasma too, version 6.6. with Qt 6.11.0. But I use X11 with fractional scaling (175%).

You could try starting gqrx like this and see if that makes a difference:

QT_QPA_PLATFORM=xcb gqrx

Kevin

[Potomac]

I tried to start Plasma with X11 mode : the bug is still here,

I tried also "QT_QPA_PLATFORM=xcb gqrx" and I have also the bug.

Only old versions of gqrx shows the warter fall, so there is something broken on new version of gqrx, something about graphic rendering, or a change in Qt6 about graphic or GPU rendering ?

My graphic card is AMD radeon RX 7600, my screen has 1920 x 1080 resolution.

If I try on another PC with a different hardware (Intel iGPU) then I can see the water fall.
Do you know where the configuration file of gqrx is located ? Perhaps there is an incorrect setting on the PC where the water fall is missing.

[Potomac]

I found a solution :

I deleted the directory where the configuration files of gqrx are present :
~/.config/gqrx/

then I launch gqrx and now I can see the water fall.

I think you should add on gqrx a function that can check on start if the configuration file contains valid settings, if not then gqrx should automatically correct the contain of default.conf file.

[Potomac]

After further investigations I found the settings that can make disappear the water fall :

I have these 2 settings in [fft] section in ~/.config/gqrx/defaut.conf :

waterfall_max_db=0
waterfall_min_db=0

If I remove "waterfall_max_db" and "waterfall_min_db" settings then the waterfall is displayed,

the complete [fft] property settings that works :

[fft]
fft_center=1
fft_window=hamming
fft_zoom=0
pandapter_max_db=0
pandapter_min_db=-160
plot_mode=max
plot_x_unit=rbw
plot_y_unit=dbfs
waterfall_mode=max

[kkettinger]

@Potomac

I can confirm the issue, setting the waterfall min/max dB values in the default.conf to 0 makes my waterfall plot black too.

[argilo]

I take it then that the "WF dB" sliders in the "FFT Settings" panel were set all the way to the right. A black waterfall is the expected result in that case.

How did you end up in that situation? Is there a bug somewhere that needs to be fixed?

[Potomac]

I don't know if I moved the sliders of FFT settings, I noticed the bug after an upgrade of gqrx.

[argilo]

It does seem there was a behaviour change between version 2.16 and 2.17. A large number of changes were made to the FFT & waterfall in 2.17, so it could be some validation that rejected invalid values went away. Some further investigation will be needed.

[argilo]

So it looks like the validation is still there, but the fallback range for the waterfall used to be -150..0 and is now 30..0 due to the change from m_PandMindB = m_WfMindB = -150.f; to m_PandMindB = m_WfMindB = FFT_MAX_DB; in #1218. I suspect this line was meant to use FFT_MIN_DB.

[argilo]

To add some more detail:

Both the waterfall and the FFT plot require their minimum and maximum levels to be at least 2 dB apart. But the handles in the "Plot dB" and "WF dB" widgets can be slid all the way together, such that the difference between the minimum and maximum values is 0 dB. When they are moved together like this, the resulting CPlotter::setPandapterRange call sees that the values are invalid and rejects the change, preserving the plotter's previous minimum & maximum values. But the GUI sliders remain as they are, and their (invalid) values are saved to the configuration file upon exit.

When Gqrx is next started, it initially uses default values for the plotter's minimum & maximum levels (previously -150 and 0, but now 30 and 0 starting in version 2.17). It then loads the configuration file and sets the positions of the GUI sliders, which triggers a call to CPlotter::setPandapterRange. Because the values are invalid, the change is ignored and the default values are retained.

Clearly, sane default values should be used (perhaps -120 and -20 to line up with the default values used on first startup, DEFAULT_FFT_MIN_DB , and DEFAULT_FFT_MAX_DB). But it would probably also make sense to make it impossible to move the slider handles into invalid positions or save invalid values to the configuration file.

[argilo]

The audio FFT plot & waterfall also have the same issue where the GUI sliders can be set to have a difference of zero. But in that case, a default range of -80 to 0 is used during startup. However, due to input validation checks in CAudioOptions::setPandapterRange and CAudioOptions::setWaterfallRange, the sliders are left with their minimum & maximum handles both set to zero, regardless of the handle positions when they were saved. (I.e., if -55..-55 was saved, the handles will be set to 0..0 and the plot will use -80..0).

[argilo]

I opened #1459 to fix the invalid fallback ranges used when saved values are invalid. But I'll leave this issue open until the bugs that allow invalid values to be written to and loaded from the configuration file are addressed.