Over on QRZ.com we have had a lively discussion with a member, an RSP2pro user,  who wanted to run our recommended GNU radio Linux flow, and installed the latest Linux API from our Downloads page while trying to run an application designed to use the older V2 API.

The purpose of this post is to help clarify the difference between the latest API which we publish for developers,  and the older one which is needed for applications already developed and being actively used by the SDRplay community.  (Note we now point out on our downloads page that the latest API is recommended for developers only)

Explaining our APIs:

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 been available on Windows for 18 months, but is now available on multiple platforms. Developers creating end applications will take time to migrate to using this version.  When they do, their applications may exploit the dual tuner features of the RSPduo and support the newer RSPdx.

So the thing to be aware of is that API 2 and API 3 are not compatible – for example, you can’t take an application that was designed for API 2 and expect it to work with API 3 – there is some work needed by the application developer to make that happen.

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 has not yet been updated to work with the new API 3)

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 SDRplay releases and supports (the API installers and issues with using the API) and things which we cannot support (e.g. issues with building 3rd party applications since the reasons for such issues 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).

Our priority is to try to do our best to help customers, where we can, by producing documentation and videos to minimise those issues.

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

Some information about USB Interfaces:

We’d also like to say something relating to  USB interfaces:  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.

Regarding SDRplay support for Linux and GNU radio users:

We are very aware that since we are a very small team, we can’t  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 (https://www.sdrplay.com/support) from which you will get an answer.  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 feedback@sdrplay.com – 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.