Author Topic: Review: SDRPlay RSP-2 & SDRUno Software  (Read 1579 times)

Offline LodeRunner

  • Prepper
  • **
  • Posts: 66
  • Karma: 6
  • Let the sparks fly...
Review: SDRPlay RSP-2 & SDRUno Software
« on: November 06, 2017, 07:30:59 PM »
This past January, I purchased two SDRPlay RSP-2 units.  After nearly a year of use, here's what I've found:

Overall, I am not at all disappointed with the hardware or software - performance was equal to or above that of many analog receivers in the $500 ~ $1000 range. I did not experience any serious RFI issues via conduction on the USB cable (as I expected I would) and typical application of Mix #77  (Amidon FB-77-1024) beads was sufficient to eliminate what little conducted noise was observed.
The included software - SDRuno and the API - are well designed and performed "as advertised" in nearly every way (see the one exception, below).

HARDWARE -

The enclosure is a neat, solid, and well fitted ABS plastic clam-shell.  I don't worry about damaging the unit when I toss it in my backpack or go-kit.  There is no foil or other RF shielding inside the enclosure, which I found surprising.  After opening one of the RSP2 units up, I can say that everything with the circuit-boards and construction look very well done - nice "tight" RF paths throughout the front end, plenty of groundplane under and around the chips and RF paths as appropriate, no "hot spots" evident in operation, and more than sufficient vias between layers to ensure consistent front-end operation across the frequency range specified.

RF and USB connectors are not cheap - they have survived a year's worth of connect/disconnect cycles without giving the slightest bit of reduced reliability.

There are lots of built-in filters to ensure good performance of this receiver.

Front End Filtering Ports A and B  (automatically configured)
Low Pass   
<=12MHz
Band Pass
12 –30MHz
30–60MHz
60 –120MHz
120 –250MHz
250 –300MHz
300 –380MHz
380 –420MHz
420 –1000MHz

High Pass
>1000MHz

Notch Filters (Software Controlled)
FM Filter  >60dB 80–100MHz
MW Filter >30dB 680–1550kHz


Front End Filtering  (High Z port)
Low Pass   <=30Mhz

One thing to note is that the Band-Pass filter selection is automatic, and is based on the 'IF frequency' - which is at the center of the available Receive Bandwidth window.  So, if we select an 8Mhz receive bandwidth, and an IF frequency of 14Mhz, then the 12-30Mhz filter will be selected automatically.  With the IF set to 14Mhz, the receive window of the ADC will be 10Mhz to 18Mhz, but the filter will substantially attenuate signals below 12Mhz (as it should).  Perhaps I'm picking nits, but one of my few issues with this receiver is that you can't bypass the internal filters - say, to use an external one with your specific characteristics.  For LF/MF/HF this is moot if you use the High Z port which has a fixed Low-Pass filter at 30Mhz, so the Automatic Filter Selection is not even close to being a deal-breaker.

Also of particular note is the fact that the MW filter of the RSP-2 cannot be used with the HiZ antenna port on the RSP-2/2Pro. This fact was not exactly obvious in their marketing sheet, but should be made so.  It represents a notable limitation of the RSP-2 for those who expect to do a lot of MF and LF reception with the RSP2 "straight out of the box".

IMHO, the MW filter doesn't cut the BC racket sufficiently, but my expectations in this regard are high: per my testing, it does *exceed* the advertised >=-30dB signal reduction in the  680~1550KHz range, and holds close to -30dB across the entire North American AMBC band, 535~1715KHz.
No intermod or digitization artifacts of strong BC signals are evident so long as you are looking at/listening to spectrum above 1.8MHz.

However, when receiving *below* 525KHz, I found additional filtering of the MW broadcast segment necessary to eliminate some small residual intermod which was rather pervasive between 90~450KHz while using various antennas, including a PA0RDT E-Probe, as well as various loops/pennants [both amplified and passive], and long wires/Beverages in the 250' to 1200' category (which were properly terminated to the RSP's  input port impedance of 50 ohms).

Let me qualify my previous statement:  I own a rural property where the noise floor is very low - in the -150dBm range - and have invested a lot of time and effort to provision that property with antennas dedicated to VLF~MF reception.  In that environment, I have found the limits of my Drake R-8, TenTec RX320, Palstar R30A, Icom PCR-1500 and R-75, and numerous other receivers, in addition to the issues I note above with the RSP-2, so please do not take my comments as specifically prejudicial to the RSP-2. Every receiver has limits; the RSP2's limits are very respectable.

If the noise floor in the VLF~MF spectrum at your location is only in the -120~135 dBm range, as is typical for a suburban neighborhood then you probably won't ever encounter the issues which I have with the performance limits at LF/MF.

Sensitivity -
The RSP-2's performance between 2MHz and 500MHz was just plain outstanding. HF sensitivity was below 1.0 uV under typical conditions.  In all of my HF and VHF testing, the units consistently demonstrated < 2.5uV sensitivity, even when very strong signals (typically SWBC or VHF 2Way base-stations) were between 10 and 1,000Khz away. 
For use above 500MHz, I'm not the guy whose opinion you want - weak-signal UHF and microwave just isn't my thing.

SOFTWARE -

One of the very attractive features with SDRplay's software, SDRuno, is that it is "designed to run multiple instances" on a single system
, and each instance of SDruno can support a separate RSP-1/2/2Pro unit - making a great deal of spectrum concurrently available on a single computer.

In the first 8~9 weeks I owned the RSP2s, I did a lot of testing with both Windows and Linux systems, and clocked over 2000 device-hours between the two RSP2 units purchased. 

The SDRuno software (ver 1.1.12 originally tested, ver 1.2.0 now available) is generally well behaved, straight forward, and easy to use, albeit a bit resource hungry on the host computer.  I will note that there were occasional glitches with the individual "Virtual Receiver" and spectrum windows when I had many [between 4 and 10] open concurrently.  This was evident whether the "Virtual Receivers" were associated with one or multiple RSP-2 units, so the issue is *not* related to operating multiple instances of the SDRuno software.

With these glitches (ver 1.1.12 - I haven't thoroughly tested v 1.2.0 yet), the particular "Virtual Receiver" windows either froze, or displayed incorrect numeric frequency and spectra for the selected "Virtual Receiver" in question.  Closing and Restarting the [Main] SDRuno window resolved the issues temporarily, and I suspect there is a memory leak specifically in the "Virtual Receiver" code itself, because the glitching becomes more pervasive as time goes on [if allowed to]  These glitches were sometimes evident after as little as one hour of operation, and were always evident after 18~24 hours of continuous operation.  Normally I did not observe this until either 1) I had many virtual receivers running,or 2) the software had been running for many hours; but I was testing on a very well provisioned system (Dual Quad-Core Intel 2.66GHz with 8GB of RAM and an SSD system drive - on lesser systems, the suspected memory leak might become apparent while subject to less demanding usage than that which I engaged in, but this is speculation on my part, not observed behavior.

The API offered with the RSP2 (for applications other than SDRuno) is excellent. It has it's own well designed control panel to manage hardware specific aspects of the RSP2 unit(s); and interfaced well with both HD-SDR on Windows, and Soapy on Linux.  In several thousands of hours of use, I have experienced -NO- software issues with their API whatsoever, which is rather impressive, considering it has a lot of 'middle man' responsibilities to make your chosen front-end software connect with the RSP unit.

Nearly a year after buying them, I'm very happy to recommend the RSP2 from SDRPlay to anyone looking for a good SDR at a good price.

Offline FreeLancer

  • Global Moderator
  • Survival Veteran
  • ******
  • Posts: 5675
  • Karma: 759
Re: Review: SDRPlay RSP-2 & SDRUno Software
« Reply #1 on: November 06, 2017, 07:51:35 PM »
I need to break out the one I got earlier this year......it's gotta be around here.....somewhere.

How much computer would you recommend for the software?

Offline Carl

  • Mr HamTastic!
  • Forum Veteran
  • *********
  • Posts: 13112
  • Karma: 712
  • COW?...No ,I haven't seen your cow.
Re: Review: SDRPlay RSP-2 & SDRUno Software
« Reply #2 on: November 07, 2017, 05:37:51 AM »
I need to break out the one I got earlier this year......it's gotta be around here.....somewhere.

How much computer would you recommend for the software?

A whole PC should do the trick :spit:   My 1 GHZ with 1/2 Gig of RAM handles it pretty well.

Offline LodeRunner

  • Prepper
  • **
  • Posts: 66
  • Karma: 6
  • Let the sparks fly...
Re: Review: SDRPlay RSP-2 & SDRUno Software
« Reply #3 on: November 07, 2017, 12:16:45 PM »
I need to break out the one I got earlier this year......it's gotta be around here.....somewhere.

How much computer would you recommend for the software?

It depends on your intended use.  When I ran many (6 to 12) 'virtual receivers' in SSB mode, it hogged resources even on a very well-provisioned desktop.  That's the worst-case scenario, but unfortunately it's what I bought them for. 

Running multiple (3 to 5) virtual receivers in FM mode shouldn't be a problem for most laptops made in the last 3~5 years, and running 5 to 10 virtuals in FM mode should be possible with a recent 'high performance' laptop/desktop, based on the system utilization I saw in my testing. 

I found that the HD*SDR software was slightly less resource-intensive than SDRuno, but that's for one Audio Decode stream, as HD*SDR doesn't do multiple virtual receivers.  But if you have an older laptop/desktop and want to dedicate it to the SDRPlay, then this might make the audio decoding smoother.  The key resource to pay attention to is memory - quantity and speed are both important.

There's another application, SDR-Console, that I haven't spent much of any time with so far - but it's supposed to (among other things) allow you to 'split' the control and capture functions of the RSP from the GUI and DSP portion - i.e. to remotely operate the RSP by attaching it to a computer separate from the one you sit in front of.  This will supposedly support Internet linking of the user and a remote RSP, which I find very attractive...  but it's a bit intensive to set up and get working from what I've seen so far.  I'll post about SDR-Console once I've given it a proper go some time this winter (I have several projects ahead of this in my queue).

There's also SDR-Touch for Android tablets, and a Raspberry-Pi (2/3) system image to support the RSP receivers as well.  I can't say anything specific about these, as I haven't tried them yet, although my understanding is that the Ras-Pi image can be the "controller" for an RSP, which then connects back to an SDR-Console over TCP/IP, and that is something I intend to try out.

FWIW, I was able to run 2 or 3 virtuals in FM mode (in SDRuno) on a ~10 year old Aspire-1 netbook without trouble, and I have a friend running as many as 4 or 5 virtuals (again, in FM mode) on a Windows tablet he bought earlier this year (sorry, I don't remember the make/model of tablet).  He had to buy a "breakout adapter" so he could connect the uUSB on the tablet to a standard USB cable, and inject separate 5V power (running the RSP2 off the tablet drained it's battery too fast for his uses) - but he got the break-out adapter from Amazon for like $10 or less.

Cheers