Comparing the FunCube Dongle Pro+, Airspy/SpyVerter and SDRplay on Shortwave

Over on YouTube user London Shortwave has uploaded a video showing a comparison of the FunCube Dongle Pro+, Airspy with SpyVerter upconverter and SDRplay on shortwave reception. The Funcube, Airspy and SDRplay are all $150 – $250 USD software defined radios that have much higher performance compared to the RTL-SDR.

In the video he tests the reception of Radio New Zealand International (RNZI) at 9400 kHz using a 6m copper wire dipole and 9:1 matching balun raised 2m off the ground. He did not use any external antenna preselectors. The RNZI station is weak and appears to be almost blocked by a stronger station so reception of the station is difficult.

In his results it appears that the FunCube and Airspy/SpyVerter are able to clearly receive the RNZI station, but the SDRplay has trouble with images of other stations mixing into the signal.

If you are interested in a comparison of the Airspy, SDRplay and HackRF we previously did our own review here.

Portable SDR Shootout Part 1

Subscribe
Notify of
guest

7 Comments
Inline Feedbacks
View all comments
OE5

i didn’t find away yet to make SDRplay work as LAN SDR server which is also compatible with mobile apps like sdr-touch/rf-analyser , i tried Soapysdr/soapyRemote, and some sdrports like Play_tcp and play_sdr they emulate RTL therefore miss up the signals, Sdr-console works fine but allows only sdr-console clients to connect and the audio compression even with best setting makes it alittle hard to decode digital signals over LAN, i hope that sdrplay developers make a mobile app to connect remotely

Eric Cottrell

SDRSharp is a poor choice to do a comparison such as this. SDRSharp purposely disables C# interfaces on any SDR that does not have built-in front end support. Support for the Funcube and Airspy is built-in. Any added front end, like the one for the SDRPlay, is crippled. I do not consider this a fair comparison.

London Shortwave

SDR# version 1337 was used for evaluating SDRPlay. This version has full support for SDRPlay’s EXTIO plugin. In this video, SDRPlay was evaluated with its new API version 1.8.1 and EXTIO DLL 3.8.3. If you could explain in technical detail how this makes for an unfair comparison (or indeed how this gives rise to the intermodulation / imaging artefacts produced by SDRPlay in this video), I’d be interested to hear it.

P.S. More configugration details are in the YouTube video info section.

Eric Cottrell

But this is still a comparison using the native C# support for the Airspy and Funcube versus EXTIO support for the SDRPlay. EXTIO support was eventually removed from SDRSharp because of various problems. I find there is a difference in gain and images using the same EXTIO settings between SDRSharp versus HDSDR, for example. This problem is increased by having the LNA Gain turned on, like you did in your demo. You decreased the gain alittle bit, but the LNA should have been turned off first as that is a 24 db gain reduction. You also had the Enable Tuner AGC off in the EXTIO. Were like settings also off in the Funcube and Airspy?

London Shortwave

you’ll see in the video description that all three radios had both LNA and Mixer switched on (Automatic Gain Control for IF was not used in AirSpy. FunCube Dongle Pro+ doesn’t even have that option). If you turn off LNA in SDRPlay, it makes weak signals (such as the one in this video) drown in the noise floor, which you can’t compensate by pushing the gain up. So you need the LNA on for weak signals, and that’s why the option is there in the first place. If you can’t pull out weak signals without getting images and overloading, that’s just bad radio design.

At the end of the day, what you get from all three radios is IQ data. Either that IQ data includes images or it doesn’t. Software can’t make artefacts like that happen, it just demodulates the part of the spectrum that you choose. Everything else is down to the radio and it’s Analogue to Digital Converter (ADC) and filters. Images arise because of insufficient dynamic range of the ADC which results in some signals becoming to strong for the radio’s filters when you need to increase the gain enough to hear the weaker signals. You can solve this problem in traditional radios by using a preselector that effectively filters out strong signals from outside the desired narrow frequency range, but one of SDRPlay’s selling points is that it can capture wide portions of the radio spectrum, so having to use a preselector with it automatically defeats the purpose.

The only way for HDSDR to be better for SDRPlay than SDR# under this scenario is for it to specifically suppress the radio’s images in some clever way, but that software hasn’t been updated for a few years now and certainly doesn’t include SDRPlay specific code. I have deliberately used the version of SDR# that was around before the SDR# team explicitly decided to discontinue SDRPlay support, so it seems a stretch to suspect foul play from SDR# to specifically disadvantage SDRPlay.

In that way, I don’t see the fundamental difference between native C# support and an external interface.

Tim

This means SDRPlay is condemned to stay with its mediocre performance without SDR#’s blessing.