We find some crucial features missing in currently used SDR software. (some have pointed out that you can get most of these features by mixing SDR# with various 3rd-party plugins, which unfortunately are not always open-source, multi-platform etc.)

Network transparency. Process the data remotely and send to the client only waterfall pixels and filtered narrowband channels instead of the entire SDR baseband. With this, you can use the SDR remotely over WAN.

Multiple demodulators running at once. How the hell can this be missing?

History browsing. It happens to me all the time: I see a new station scrolling on the waterfall. Before I manage to tune to it, it disappears (or at least the callsign is over). I have 8 GB of RAM, so why can't I store the last minute of the entire SDR baseband for future reference?

Pluggable demodulators. Why is it so much pain to add GSM, Tetra, Tetrapol and other modes to existing software? I just want to provide a binary and have the data piped to stdin.

Squelch sucks. The squelch should not care about absolute signal level, but about level relative to surrounding channels. Additionally, it should have hysteresis and a small buffer, so when it triggers, it correctly replays the beginning of the conversation. Oh, and when recording, the squelch should timestamp the parts of conversation.

Histogram. It is difficult to see clipping on the FFT output. Why don't we have histogram of samples?

Autotune/AFC. Obvious.

Scanner. Both for automatic demodulating all peaks in the spectrum and for retuning the SDR and finding stations. Even the crappiest rtl-sdr has 2 MHz bandwidth and can retune in 50 ms. This means 1600 channels per second. Compare this with commercial scanners.

Thus, we present Kukuruku, a modular SDR software consisting of a preprocessing server, a Python module allowing you to easily implement your own SDR solution, and a GTK application built upon this module.

https://jenda.hrach.eu/gitweb/?p=kukuruku;a=summary

You may also like: fcl