ad: MonitorSens-1

SDRplay RSP comparison chart and update on availability

Discussion in 'Software Defined Radio (SDR)' started by G4ABQ, Dec 7, 2019.

ad: L-HROutlet
ad: l-rl
ad: HRDLLC-2
ad: L-MFJ
ad: abrind-2
ad: L-Geochron
ad: Left-2
ad: Left-3
ad: MessiPaoloni-1
  1. KK4NSF

    KK4NSF Ham Member QRZ Page

    I have not tried the Dec 6 update. I'll look at it today. Hopefully, it will install better.... thanks
  2. G4ABQ

    G4ABQ Ham Member QRZ Page

    If you still have problems let us know - it's hard to monitor all the forums and we often miss comments!
  3. K6CLS

    K6CLS Ham Member QRZ Page

    The installation failure is your problem with CMAKE script. Nothing to do with the API.

    Didn't you read my post above? the terminal output clearly shows the problem. I bet that it will not complete successfully on any Linux system. Which means your staff didn't even try it.

    I'll send an email separately. We greatly appreciate your support.
  4. KA9JLM

    KA9JLM Ham Member QRZ Page

  5. G4ABQ

    G4ABQ Ham Member QRZ Page

    I forwarded your questions to the technical team. Their response is that the RSP source blocks for GNU Radio currently only support API V2.13 - installing API 3.x will not work with this flow until the RSP source blocks have been updated to support the new API. The RSP source blocks have been developed very kindly by an SDRplay customer in his spare time. We will try to encourage the development of the RSP source blocks to support the new API and thereby supporting the RSPduo in dual tuner mode and the new RSPdx.
    There is possibly some confusion : our deliverable is hte API installer and if that fails for any reason then please report that failure, together with and error message to our support system. We try to help people build applications by showing them videos like this: where we go from a clean OS installation to a working Cubic SDR install.
    Regarding the offset, there is no minimum offset but we recommend keeping the LO and the VFO separate by at least the signal bandwidth (an offset is only required in zero IF mode - in low IF mode there is no such need)
  6. K6CLS

    K6CLS Ham Member QRZ Page

    Thanks for your answer here.

    So you confirm that the RSP1 won't work under Linux, and won't work with Gnu Radio.

    Ok, I'm disappointed.

    Gnu Radio doesn't work under Windows. I have no alternative.
  7. DK7OB

    DK7OB Ham Member QRZ Page

    RSP1 is working under Linux with GNU radio, but only with API 2.13. I am running a heavily modified gqrx with an RSP1A. OS is Kubuntu 18.04 with the stock GnuRadio.

    It was some work to get it all running, but that was part of the fun and I find my setup (including controlling of my TS590SG) better for amateur radio than the Windows setups I installed at our club station (SDRUno and HDSDR).
  8. N2DTS

    N2DTS Ham Member QRZ Page

    I have had a few of there and find them poor as receivers go, they seem to overload very easy.
    My sdr-iq is 14 bit but seems so much better, why?

    No more usb based radios, the latency in usb makes them useless in many applications.
  9. G4ABQ

    G4ABQ Ham Member QRZ Page

    All the RSPs work fine apart from the new RSPdx, but you need to use
    API/HW DRIVER – V2.13 (20TH JUN 2018) - the only limitation is that the RSPduo will be single tuner mode only. So this works for the old RSP1,RSP1A, RSP2, RSP2pro and RSPduo.
  10. G4ABQ

    G4ABQ Ham Member QRZ Page

    There seems to be quite a lot of misunderstanding in this thread. Let’s try to clear things up…

    SDRplay produces RSPs and an API that allows applications to control them and to get IQ data from them. Over time the API evolves and in particular, when we released the RSPduo, a new type of API was required. The RSPduo has the ability to stream from each tuner completely independently and this is done using a service. So as of right now, SDRplay has two APIs:

    API 2.13: RSP1, RSP1A, RSP2, RSP2pro, RSPduo (single tuner mode only) on Windows, Linux/86, MacOS, ARM32, ARM64, (Android except RSPduo) – this is the API that has been adopted into applications such as CubicSDR (via the SoapySDR framework), GQRX, QT-DAB and the Gnu Radio source blocks (there are others)

    API 3.06: RSP1, RSP1A, RSP2, RSP2pro, RSPduo (single tuner, master/slave and dual tuner modes), RSPdx on Windows, Linux/x86 (more distributions such as Arch Linux & Alpine Linux), MacOS, ARM32, ARM64 and PPC64LE – this API has previously been on Windows for 18 months, but only available on Linux in beta format. Now it is on all platforms, HOWEVER what now needs to happen is for the end applications to be updated to take advantage of this API – this will happen over a period of time.

    API 2 and API 3 are NOT compatible – you CANNOT take an application that was designed for API 2 and just expect it to work with API 3 – there is some work to make that happen, this is what we are trying to encourage to happen. It will take time.

    Regarding Gnu Radio – we support BOTH Linux and Windows – there is a complete Gnu Radio for Windows download on our website COMPLETE with RSP source blocks (again, this is designed for the API 2 and not API 3 yet)

    We have videos on our YouTube channel showing how to get up and running with API 2 on Linux and also getting going with Gnu Radio on Windows ( & )

    It’s important to make the distinction between what we release and support (the API installers and issues with using the API) and what we cannot really support (issues with building 3rd party applications – the reasons for this could be numerous – unfortunately Linux has a history of applications that are built from code and unless you are familiar with how to do that, and in particular what to do when things go wrong, then it becomes a difficult platform to use. We are focused on helping our customers, where we can, by producing documentation and videos to minimise these issues.

    Longer term we will be supporting non-Windows platforms with our own software.

    Our tech team would also like to say something about the USB interface to those that are interested: “There are two different methods of data transfer over USB for large amounts of data – Bulk and Isochronous. Many devices such as flash drives, printers and some SDR devices use Bulk mode – we describe this mode as a fire and forget system – the application throws the data at the USB bus and the data will progress through the system at a rate defined by the system. The application has no control over when the data will arrive, just that it will arrive. It also has no control over how much bandwidth it can use, it will be allocated bandwidth on the fly as it exists. It has error correction, so that missed packets are resent. This is ideal for storage devices as you don’t really care too much when the data gets there as long as it gets there. However in an SDR system, you may actually care how long it takes for the data to get from the source to the output – you will typically see that over time, bulk mode, depending on the load of the system, will have increased latency issues.

    However, applications such as video cameras and some other SDRs (such as RSPs) use Isochronous mode as their primary method of data transfer. Isochronous mode is a guaranteed bandwidth system. When the source and destination connections are made, a specific amount of bandwidth is reserved. This means that the latency does not increase over time. No other application can use that allocated bandwidth whilst the stream is active. It has no error correction because it doesn’t need it – it’s a guaranteed data transfer method.

    Now, not all USB host controllers are the same and not all (as we’ve experienced over the years) have good support for Isochronous mode. Because of that, the RSP API supports both Isochronous and bulk transfer mode. Thus allowing the API to work effectively on low end systems while also giving best performance on those systems that fully support Isochronous transfer mode.”

    As has been mentioned, it is difficult for us as a very small team to cover every forum and respond to every question, but if anyone has a specific RSP or API related issue, the best place for support from us is our ticket system ( , however support for 3rd party application build issues is better done on a forum where others with experience can comment and help. If there is something that is not clear on our website or our promotional material, we are always happy to receive feedback to – we cannot always guarantee that we can reply, but you can be assured that every comment is read by the most appropriate SDRplay team member.

    Best 73, Jon G4ABQ on behalf of the SDRplay team
    K6CLS likes this.

Share This Page