Compute the autoscale min/max from the spec/wf averages
Hi,
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?
https://github.com/jks-prv/Beagle_SDR_GPS/blob/master/web/openwebrx/openwebrx.js#L3703
Cheers
fbx
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?
https://github.com/jks-prv/Beagle_SDR_GPS/blob/master/web/openwebrx/openwebrx.js#L3703
Cheers
fbx
Comments
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).
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.
Cheers
Fbx
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
"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?
@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
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: https://www.poynter.org/archive/2013/why-rainbow-colors-arent-always-the-best-options-for-data-visualizations/
Edit: I found the paper:
https://ieeexplore.ieee.org/document/736450
The full text is available on sci-hub.tw, in bad quality though.
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.