Software Defined Radios are Flaky

Software Defined Radios are Flaky and they are much more flaky than people think. As the author of SdrGlut, I though that people might want a peek behind the curtain at some of the things that are being hidden from them by the software programs that control the hardware. This video points out a few of the problems with the hardware that the software is hiding.

Software Defined Radios are Flaky

SdrGlut

Dropped packets could be result of different things:

  • motherboard USB (HW and/or SW)
  • OS
  • USB cables
  • SDR HW issue

In any case you must hear cracks in demodulated audio, no need to SDR software give warning or information about it. Author of YT video insist on running several instances of the same SDR program. Why is that so important or significant? USB host controller could be saturated or sw driver not working properly or… If you want 100% guarantied bandwidth USB transfer then ISOCHRONOUS end points must be used! I dont think that any of devices in video does that! They use BULK which is error free protocol but without any guarantee that packet will be delivered on time. BULK protocol share usable bandwidth with other USB devices, it is perfect for flash memory with file system.
SDR programs can be divided into several segments:

  • DSP part
  • Display routines
  • connection with SDR hw (USB, eth…).

In SDRglut for DSP part is used liquid-dsp library (https://github.com/jgaeddert/liquid-dsp), display part is pretty simple, connection part are using libs (I’m not sure are they externally built from HW manufacturer or not). SDRglut with 4 instances has problem but is it SDRglut or OS or mobo or HW responsable is hard to tell. SDR radios are certainly not flaky! This is only my two cents.

“In any case you must hear cracks in demodulated audio” - Yes, you would hear a crack if the bad records were not removed and the spectrum and waterfall would show glitches - that is why the SDR programs remove the bad records.

With additional testing , I found that the HackRF One stops generating bad records with sample rates greater than 6 MSPS, but it will not even run at 1 MSPS. The RFSPACE NetSDR+ and the Icom IC-R8600 are the only ones that I have found with no bad records.

4 instances is only 8 MSPS - even USB 2 can handle that. The problem occurs when I run them one at a time or all together. I ran them all together - just to save time. The glitches are as often as a few times per second - if they were not hidden, I would find it more than distracting - I would say that the SDR is flaky.

Statement “SDR programs remove the bad records” is new for me and I dont understand it. I never saw that SDR program handles packets directlly (USB or network), it is done on protocol level. BULK or TCP are error free, ISOC and UDP not error free but bad packets are never discarded because it is less damage to have wrong packet than not to have one (audio sound cards use ISOC and works like I described; SDRwidget is very popular for ham radio SDR applications)!
When you have dropped packets results is empty buffer (filled with zeros or FF) sent to DSP routine which returns again empty buffer (filled with zeros or FF). Empty buffer is then converted with D/A converter to audio and as final results you hear cracks.
One of your SDR is popular RTL based devices, widely used all over the world. I never saw that many users complain about lost packets.
What is your host PC? Raspberry PI? RPi host controller chip share ethernet and USB resource.

I just tried the SDRplay RSP2 and a RTL stick, On MacOS, On Windows 7, On Windows 10, On ubuntu 20.04 and the Raspberry Pi 4. The error rate is about the same across all devices with the RTL stick giving about 10 times as many errors as the SDRplay RSP2.
What the program is doing is - it is reading 10 records per second. It keeps a running average of the magnitude of the first (4096-32786) complex samples in each record. When the average of a record drops well below the running global average (it is usually 1/100 or less of the global average) the record is dropped and a drop out is flagged.

By the way - they are drop outs - i.e. amplitude near zero - so there is no click - just a fraction of a second of silence and nobody notices.

Uses do not complain, because they do not know that it is happening the software is hiding the errors from them.

The RFSPACE NetSDR+ uses ethernet the others are USB devices.

Show me an example where an RTL does not generate bad records. You only need about a 100 line program to test it. The Github for SoapSDR has an example you could use.

Airspy works fine. How do I turn on debug messages?

RTL-SDR v3 is not for use with SDRglut, runs fine with SDR# and GSDR.

The print out is only in the latest version.

I put the latest version, SdrGlut-886, for windows out at -

this morning.

Left click on the water fall and hit the ‘o’’ key to toggle the print out of the dropped frames.

All of SDRs will do that some times - the reading of the data blocks is failing for every block.

The list of possible fixes -

1). Right click and open the “SDR Dialog” and hit the “Apply” button.
This fixes it 9 out of 10 times.

2). Close and reopen the window.

3). Unplugging it an plug it back in.

4). reboot.

One of those has always got the SDR going for me.

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