FFT resizing when zooming in

[ANVF-Postal]

Is there a way to increase the resolution of the FFT when the user zooms into certain frequencies? I know WebSDR and the KiwiSDR web interface both do this, so I'm wondering if it's an implemented or planned feature for OpenWebRX. I think it would improve the practicality and usability of OpenWebRX a lot.

Thanks!

[jketterl]

This is a somewhat problematic topic. I'm aware of the limitations that will show as blurry artifacts when you zoom in really close. This is the result of having a single, shared FFT process that is producing the FFT data for all users. Not only is this a question of performance, but also a question of how OpenWebRX is structured right now.

I will also say that I'm not willing to go down the same route that websdr and kiwisdr went, simply because I don't like the huge chunks of spectrum missing when you're zooming out.

So ideally, you'd have an optional FFT overlay with more detailed information that would show up when you'd zoom in. This is where things get complicated since you'd need to set up separate filters and shifts for every user, and you'd need to synchronize this with the main FFT, and you'd need to start right from the beginning: right now, the server does not have any information about what part of the spectrum you're looking at.

Lots of work considering the effect you'd be getting out of it.

In the meantime, you may want to consider going for a higher FFT resolution by setting fft_size to a higher value.

[ANVF-Postal]

Hey, thanks for the reply!

I totally agree, WebSDR's zoom could be much better. On WebSDR when you zoom out and zoom back in, the whole waterfall is rescaled, causing those parts to be blurry, even if they were sharp before. WebSDR also DELETES lines of the FFT once they move off-screen, instead of keeping them and just not rendering new ones over the off-screen frequencies.

As for performance and FFT size, I run OpenWebRX on a pi4, and share it between usually one or two people. I always figured scalable FFT would have performance benefits since I could set the FFT size down overall, and each user would get that same FFT resolution scaled to fit to the area where they zoomed in. Perhaps I'm incorrect here though. Maybe spawning multiple FFT processes would yield better performance with multi-core systems, assuming OpenWebRX only uses a single core.

Thanks a lot! I'm excited to see where this goes.

[jketterl]

I'd say that from the standpoint of performance, it depends. The problem is that in order to get a "fragment" of the full bandwidth, you'd additionally have to run dedicated filtering and downsampling per user, which will take some additional CPU. The other options is to run the base FFT at a higher resolution (consuming more CPU) and "cut out" and downsample that per user.

I don't have any insight how websdr handles this.

I don't have much insight for the kiwis either, but i suppose they do some of the work mentioned above in its own hardware.

[ANVF-Postal]

Update on this topic, I recently bought my cousin an RTL-SDR v3 and we decided to plug into our server. With a quad core processor, we were able to get an extra crispy 32768 waterfall size. This along with the available modes makes OpenWebRX a killer alternative to WebSDR! Sometimes, I wish I could zoom in just a tiny bit more, but a great workaround is to just use the tiny spectrum fft of a mode like BPSK, which allowed me to see the bottom tones of UVB-76 very clearly, even with little reception.

OpenWebRX is amazing!