Compute the autoscale min/max from the spec/wf averages


being a long time enthusiast Kiwi user, I noted many times
that the Autoscale feature could make a better min/max choice
if it considered also the averaged values instead of just the current (very noisy) ones.

I would set the min from the averages, and the max from the maximum got
while computing the averages

Doing so, the min would become closer to the noise floor, and would not require
manual tweaking with the slider, and the max would always fit the spectrum view.

In the code I suspect that this might be done here.. is this correct?



  • jksjks
    edited August 2020
    Funny you should bring this up. I have such a scheme running in development now. An addition to the colormap menu called "auto" that dynamically adjusts min/max as the waterfall is tuned/zoomed.

    However it is a feature that is implemented as closed source and will be distributed as a binary-only file in the distro. All significant additions to the Kiwi project going forward that are not required to be open source will now be closed. This is to help create incentive for people to continue to purchase our hardware in the face of recent clones (for which we receive no royalty as compensation for our years of full-time software development).
  • Oh, this is a pity yet I understand your point and I wish long life to this project. What you say also means that
    the github commits will not reflect anymore the true status of the "official" software, correct?

    Anyway I'm happy that the project is improving. Thanks for keeping me posted here :-)

    About the colormap, also there IMO there is space for improvement, as the waterfall is a bit grainy if compared to other SDR softwares, as if the colour palette were small.

  • jksjks
    edited August 2020
    No, GitHub will reflect the true project state just as before. And the auto-update scheme will work just as before.

    It's just that some modules will be binary-only instead of source that is rebuilt from scratch each time you update. We have had this all along: For example the proxy client is distributed as a binary module because it's written in the Go language (and setting up a Go compile environment is a pain and unnecessary). And the DRM module binaries are cached (but the source included) because they take so long to compile.

    I would like to know the details of other color map implementations. But, ironically, most of them are closed source! lol
  • fbx wrote
    "Doing so, the min would become closer to the noise floor, and would not require manual tweaking with the slider, and the max would always fit the spectrum view."

    Should this not be "... farther from the noise floor..." in order to exercise the dark blue, higher contrast part of the waterfall?
  • @n6gn, technically you're right, referring to the noise floor of the receiver. Good that we got the message right, I was meaning the noise got from the antenna

    @jks, the colour map of gqrx should be open, and also the one of websdr. In general, I have the impression that the cool-looking colormaps tend to have more shades of dark, to reduce the grainy noise
  • edited August 2020
    That could have to to with the fact that the human brain is very good at correlating brightness to power, but not very good at correlating colors with power.

    I've read a study about this some years ago but can't find it at the moment. But here's an article that describes it:

    Edit: I found the paper:
    The full text is available on, in bad quality though.
  • Re waterfall "graininess". I find you can minimize it by adjusting max/min properly. What's happening is that min is set too "high" (e.g. -100 dBm instead of -110) and the noise floor gets into the lighter blue part of the colormap. The same can happen if the max is set too "low" and the colormap stretched to cover too small of a dynamic range.

    The tradeoff is that you want small signals to cause enough color change against a dark background to be seen. This is where a good auto adjustment algorithm can help. If you've got a good way to reliably detect the noise floor value you can be constantly placing it in a dark area of the colormap. And then setting the waterfall max value to cover the dynamic range of the signals in the waterfall.

    The current setup I have replaces the WF max/min sliders in "auto" colormap mode with WF "ceil/floor" slider values. These are fixed amounts to add to the auto computed max/min values. They essentially give fixed spacing at the top and bottom of the spectrum display. This is most useful in determining exactly where in the colormap the noise floor is set.

    The other question is when to run the algorithm. Right now it is run whenever the waterfall is panned or the zoom changed (i.e. when there waterfall display is changed in any way). But you could also imagine wanting to run it periodically if you happened to have a dynamic signal environment where strong signals were coming and going (e.g. zoomed in on a ham CW contest). I'll probably have a colormap extension panel where more precise parameters like this can be set.
  • I think your ceiling/floor slider could go a long way to adjusting a WF the way I typically do. I almost automatically hit 'shift W' about 6 times every time I auto scale. Sometimes I also bring the maximum down 10-30 dB as well but it's the dark blue territory that I find the most valuable the way I typically use the kiwi. Others may have different desires though...
  • @jks ... in my original thought the button "auto scale" was totally fine. If the plan is to reassign the slider to being offsets to ceil/floor maybe you want to turn the "auto scale" into a toggle, to enable and disable this feature. I am not sure about the usability though, as it will depend on small details. Your idea to trigger the algorithm on pan and zoom seems intriguing to me though.
Sign In or Register to comment.