Airspy Dynamic Range Improved in the Latest SDRSharp

In a previous post we posted about how SDR# had been updated to vastly improve on the CPU usage. The author has been hard at work once again, and has now released a new update which significantly improves the dynamic range with the Airspy SDR. The new update gives a boost of up to 12dB in dynamic range when using decimation. This means that the gains can be turned up further without overloading occurring, and that weaker signals can come in much stronger without strong signals overloading and drowning them out.

The example images show some examples of the dynamic range improvements.

An example of the improved dynamic range for the Airspy on the latest SDR#.
An example of the improved dynamic range for the Airspy on the latest SDR#.
Using decimation removes overload.
Using decimation removes overload.

Notify of

Inline Feedbacks
View all comments

Can someone please explain how to enable this new mode? The ‘Enable HDR’ box is greyed out for me. I have an Airspy Mini, so not sure if that makes a difference.



Remove all other SDR devices, plug in the Airspy mini only. And when the stop button is pressed the check box works for me.


Cool, thanks for that. It works now!

Ben Hutchinson

This needs to be enabled or disabled while SDR# is idle. Click the stop or pause button for SDR# and all reception should stop (no scrolling waterfalls, no sound etc). While in this idle mode you can change enable/disable HDR mode as well as adjust other settings that can’t be changed while SDR# is in running mode. What I’d like to know is just what HDR mode actually does? Does it use some kind of software DSP filter on the signal in some way? Or does it enable some actual onboard-hardware DSP feature of the AirSpy itself?


Is this possible to implement with SDR Play too?

anonymous (but not the rude one)

Decimation improves the resolution, not the range. You can improve the bit-depth using decimation (at the sacrifice of 4^n samples for n-bits), but it doesn’t change the dynamic range of the receiver. It can improve the resolution by up to 12 dB (in this case) but it doesn’t give you 12 dB more range of RF power.

Regardless, thank you for implementing it – and please implement a linux version of SDR# so I can actually use it 🙂


More attention to the details is required here. The same decimation and gain settings were used with and without the new enhancements in the first screenshots, with clearly different results. So you must be overlooking something.
While what you said is still valid for textbook ADC’s examples, I believe the combination of techniques used for AirSpy is not that straightforward.


This is why I pointed it out. It’s a common mistake to say dynamic range when bit depth is meant. The difference is subtle, but they do have different meanings.

The plots (FFT and waterfall) don’t show the dynamic range of the receiver. It’s showing dB of the quantized output value from the ADC+oversampling. The minimum and maximum real value that can be measured remains the same. The range of ADC values increases proportional to the increase in bit depth provided by oversampling.

Put another way, the dB range of the ADC values is increased, but the dB range of the real values the ADC is measuring remains the same. The dynamic range corresponds to the real values. The bit-depth corresponds to the quantized representation.

The plots do look different. They should look different, they’re showing dB of the FFT of the ADC+oversampled values and the ADC+oversampled part has increased in resolution.


You definitely need to up the game over the ADC basics (or have a pure caffeine injection and try concentrate again).
The same gain and decimation settings are used in both scenarios – thus both are configured to the same NF as would any RF engineer do. So this is definitely not comparing quantization noise or bit depth of the ADC, they are the same.
The test highlight the actual dynamic range of entire setups with one below saturation and the other completely saturated.
That’s just a smarter way of using the same hardware.


Decimation reduces the ADCs quantization error at the expense of instantaneous bandwith.

There is a great discussion of ADC overloads and what they mean on the Flexradio website:

One of the salient points he also makes is that “You cannot talk about instantaneous dynamic range without talking about detection bandwidth”. Both the Airspy and SDRPlay have 12 bit ADCs with an ENOB of 10.7. This leads to a SNR/Dynamic range calculation of 6.02 * ENOB + 1.76 dB or 66.2 dB. SDRPlay claims a dynamic range of 67 dB while Airspy claims 80 dB.

They’re both right. SDRPlay has a dynamic range of 67 dB over a bandwidth of 10 MHz. Airspy also has a dynamic range of 67 db over a bandwidth of 10 MHz. With a decimation factor of 16 enabled, Airspy realizes a process gain of 12 dB for a total dynamic range of 67 dB +12 dB = 79 dB. However the instantaneous bandwidth is reduced to 0.625 MHz.

So a more accurate dynamic range spec would look like:

SDRPlay Dynamic Range = 67 dB @ 10 MHz instantaneous bandwidth
Airspy Dynamic Range = 79 dB @ 0.625 MHz instantaneous bandwidth

For those who are interested in the basics of ADC, I highly recommend the Data Conversion Handbook put out by Analog Devices.


Here’s the link:


Thanks for the link, reading book now.


Correct, but it’s not that straightforward. There are other parameters involved when estimating the narrow band performance.
1) SFDR: If you decimate enough and end up un-burying ADC spurs, you can only claim the SFDR, not the wide band SNR + processing gain.
2) Reciprocal mixing: Not all frontends are born equal. You can perfectly make a radio look good with the right separation and signal levels. In reality, strong signals tend to mix together through phase noise and non-linearities and rise the noise floor, causing faster degradation of the performance than one would expect.
3) Natural dithering: All lab tests are lying to you. Most radios behave better with real signals and a natural background of RF noise. The net effect is the randomization of ADC artifacts which improves the SFDR quite a bit. Yet, not all ADCs behave the same with dithering, be it natural or artificial.


I’m only guessing here, but say a mini is sampling at 6MSPS. What would happen if an analogue frontend filter of 5MHz bandwidth with an attenuation of 0.1dB is replaced by a 600kHz analogue frontend filter with an attenuation of 6dB, would oversampling and 8x decimation improve the dynamic range by at least 5.9dB ?

I do not know what is going on under the hood, I’m just guessing, but the results above look clear enough.


For decimation to work the signal needs to remain relatively steady over the decimation number of measurements (8 in your example.) So you’d actually need the smaller bandwidth filter to use decimation in your example. You must oversample the signal for decimation to increase the bit-depth.

If your signal remains within the dynamic range of the receiver then your ability to demodulate should be improved by using oversampling and decimation. The dynamic range doesn’t change (it’s complicated, see my other post above.) A combination of different bandpass filtering and gain being used by the receiver will alter the dynamic range but that’s not a result of using the oversampling and decimation.


Now I get it. So it could work for SDR-RTL as well. Will give it a try in GNURadio.

Thank you kind anonymous! 😉


I’m still only guessing here, but maybe dittering and noise shaping are being used to increase the dynamic range for the band of interest.


There are guides easily googled for using it in Linux with mono, and it’s actually pretty simple to get running overall. The one issue I’ve had though is if your HiDPI screen (3200×1800 in my case) is in high resolution mode the left control panels are abruptly cut in half. Running at a lower resolution fixes it though.


thank you


You can’t count up to 12, can you?


12 dB improvement! Will the SDR# do the decimation or the Airspy itself? If it is the Airspy than it will be easy on the PC won’t it? If it is SDR#, any chance it’s applicable to my SDR-RTL and will it work for both Airspy R2 and Airspy mini?

Cheers, Jaap


It requires decimation to work so the Airspy R2 and Mini are fine. I’ve tried both and it works very well.

However a standard RTL device does not have the option for decimation in SDR# so it won’t work.


8 bits is still 8 bits


Ever heard over oversampling?