Something said in the YT video triggers me really badly, to the point of writing this comment.
It’s dropping these blocks that are 100 times lower in amplitude than the adjacent blocks.
That makes no sense at all. The “blocks” are time-domain samples, and the SDR is merely passing the data to the computer. It’s not dropping blocks because of amplitude, that would defeat the purpose of using SDRs to capture weak signals. Also, 100 times lower is only 20 dB if you consider power. That’s nothing, I have to reduce aliasing by 80+ dB or my program is able to demodulate the signal with just 5 dB SNR, so 20 dB is very little.
Keep in mind, the DFT (or FFT) requires windowing to reduce the spectral leakage onto adjacent bins. Each window has scalloping losses, and the DFT itself can either calculate the average power in the bin or the maximum power, the two having different results in the displayed amplitude.
On the RSPduo, that “extra hump” you see is simply a weaker signal. If you consider it is roughly 25 dB down from the two other channels to the left of it, that puts the signal right below the noise floor in the other SDRs.
On the NetSDR, it looks like the gain is very low. The signals are only 10 dB above the noise floor. If the SDR does not support increasing the gain, try adding an external amplifier.
On the HackRF One and on the RTL2832U, the extra signals you see are most likely caused by overdriving the SDR amplifiers. Try to lower the gain a bit and they should go down faster than the signal is going down.
On 3 of them, you have a DC offset. On the RTLSDR, depending on the tuner, the value of 127.5 for the 8-bit samples is not quite enough to remove the offset. You can always add an IIR DC blocker, but make sure the bandwidth isn’t too wide. I’m not familiar with the other two, but it seems the center of the samples is not where the program or driver thinks it is. Luckily, DC offset is easy to compensate for if you don’t want to add a filter. You can just calculate the mean of a few of the samples and use that as your offset.
The dynamic range will vary from SDR to SDR, and a big player here is the sample bit depth. An 8-bit sample will always have a lower dynamic range than a 12-bit sample. This is why analog amplification and filtering are very important, and why antennas make such a huge difference on the quality of the signal received. The sampling rate also helps here, as an oversampled signal can get you a better signal if used with decimation. Of course, always pros and cons to everything done in DSP.
There are a lot of quirks to SDRs, but the big majority of them are due to poor software design, bad DSP, and lack of understanding of how an SDR works. I work with SDRs every day, developing satellite communication systems. I build the driver interface, the DSP blocks (working on publishing my own C++ DSP library, optimized for real-time processing), and all the supporting software that goes around it. I have to work in a calibrated environment, meaning that I can’t just say “output the signal at -20 dBFS”, I have to adjust the output so it matches an actual dBm value. This adjustment varies per SDR model, and a bit between two SDRs of the same model. Different SDRs have different build qualities, different internal architectures which come with other quirks you have to deal with when transmitting like LO leakage in the transmitted signal that you cannot remove through DSP. There’s a lot more to SDRs than just receiving signals and watching a DFT waterfall. Almost anything on the receive side can be fixed by proper DSP, amplification, filtering, and correct usage of the SDR, but you have to first understand the SDR you’re dealing with if you want to build high performance systems. If all you want to do is listen to the FM broadcasts or capture a few ADS-B signals, then “good enough” is usually good enough, and this is what a cheap SDR will give you, good enough performance, the rest is up to the software and user to adjust.
As has been mentioned before, the method used to transfer the samples is most likely the cause of the dropped blocks. I’ve never had any issues with dropped blocks unless the USB controller was overtaxed or the CPU couldn’t keep up with the DSP. I dropped entirely liquid-dsp because of performance and accuracy issues, FFTW3 needs to be compiled with SIMD extensions to be fast (and if you roll your own FFT implementation, it will probably be very slow in comparison), and most of the time people use way too many taps on their filters, like 1000+ taps when a 5 or 7 tap filter would be enough. It’s easy to clog up the CPU with DSP.
Disclaimer: I’m not saying all of those apply here, I’m mostly talking in general from what I’ve seen in my experience. None of this is an attack on any project or person. It’s merely me sharing my opinion and experience in the world of SDRs and DSP. I could be wrong, and if so, please prove me wrong so that we can all learn.
Cheers,
JD