Local or Remote SDR ? What are the options ?

Cloud SDR - local network

(originally published in August 2016 – This post has been updated)


In this post we review the different techniques and architectures available to process RF samples coming from an SDR device on the local network or from a remote location, through the Internet for example.

Streaming SDR IQ samples to a remote computer is an interesting option to “extend the coaxial cable length” or the share receiving equipment with multiple users.

Before going into remote considerations, lets give a quick look to what is required and how it works.

Local only

The most basic setup for local operation is typically a USB SDR device and dedicated software (also known as ‘SDR console’) :local SDR operation

In terms of signal processing, the following flow-graph is a simplified description of typical SDR processing :

SDR local processing

Diagram 1 : SDR software DSP chain

  • IQ samples are received from device through dedicated driver;
  • This incoming stream is processed through FFT to generate the spectrum/waterfall display;
  • Generally providing a bandwidth much larger than the one we want to demodulate, a first DSP stage is required to extract the sub-band of interest, consisting in a local oscillator (NCO), followed by a band-pass filter and a decimator to achieve sample-rate reduction;
  • We now have the good ‘sub channel’ and we can demodulate it to extract the desired content (digital or analog);
  • For analog audio modulations (like AM/FM/SSB), the resulting audio is then feeding the external loudspeakers (or recorded into a file for later replay).

The key point here is that from external SDR hardware to output – loudspeaker for example – we have a continuous chain of signal processing blocks were latency and speed are critical. Typically we wish to have at our ears what we see on the display with no latency…

Internal network

We now want to extend the distance between the SDR device and the processing output , “extend the distance between antenna and our ears”… Different options :

  1. Take a longer RF cable…
  2. Take a longer USB cable…
  3. Use a TCP/IP network.

Network operation consists in having some software connected to the SDR device, collecting the IQ samples from the USB and deliver them through the network, as in the following diagram:

Cloud SDR - local network

Here the device is attached to a network-connected computer whose job is to convert the USB stream into a network stream.

This is described in the following flow-graph :

Cloud SDR tcp relaying

Diagram 2 : TCP/IP streaming

Here there are in fact two different software required :

  • On the SDR-side we need something to convert the IQ stream to network stream,
  • On the ‘receiving side’, we need something to do the job as described previously.

Most of the available systems take the full incoming stream from USB and just change the “transport layer” to TCP/IP. It means that the required network bandwidth is directly related to the radio bandwidth the receiver has been configured for.

Different directions have been chosen for this:

Proprietary solutions have their own networking encoding scheme to transmit IQ samples over the network. Generally the original sample format is kept and most of the systems use 2×16 bits to code the samples.

Complex signals require to code two values per sample : one for I (In-phase) and one for Q (Quadrature). Typical ADC used in SDR devices are 8, 12 or 16 bits – sometimes 24. Over USB it means at least two bytes are required per sample. Coding this into simple precision floating point values increases this to 4 bytes, 8 for double precision. Hence a double precision IQ sample is 2x8bytes…

As an example for the “software option”, lets consider what happens when using rtl_tcp software used to share the RTLSDR USB dongles through the network :

  • We set the RTL SDR dongle sampling-rate to 2 MHz,
  • Each complex (IQ) sample is coded on 8 bits/1 byte.

Hence for each complex sample two bytes (16 bits) are required. Assuming the 2 MHz sampling rate, it means this will require 2 000 000 x 2 bytes per second, that is 4 million bytes per second, 32 million bits per second.

The key point here is that this does not require much processing on the ‘server side’ and the packet encoding is rather simple. This means it can work on very small computers like Raspberry PI for example (see links at the end of this post).

Of course, the 4 Million bytes par second stream has to be multiplied by the number of remote listeners…

Main drawbacks : important network bandwidth required per user, generally requires one software per device

Going outside… connecting the SDR device to the Internet

We saw in the previous section that there are solutions for distributing the IQ stream over the network. So, what is the point with Internet ?

In fact this is just a matter of bandwidth and latency… the issue comes with our “broadband” internet access. We detailed the required bandwidth with the example of the rtl_tcp software and we saw that it would require something like 4 million bytes per second for one single remote user. In fact this is not realistic for most of the people using ADSL connection for example.

One other aspect not covered in this post is related to security: opening your computer to incoming packets from Internet is the best way to have it full of ‘software pests’…. Internet servers must have mechanisms to reject unwanted external connections.

That’s where the WebSDR applications come in. Their main goal is to share over the internet – for many users in real time – the SDR streams from locally connected devices. This gives the following architecture :


Originally created by the University of Twente, Web enabled SDR server have internally something like the following flow-graph (this picture shows one single processed channel, in fact this should be multiplied by the number of connected user, each having its own receiving chain):

Cloud SDR web SDR

Diagram 3 : Web SDR architecture

Comparing this with figure from Diagram 1, we easily see the main difference : the latest processing stages are changed, like if the original processing flow was split in two :

  1. Once the required signal has been extracted from the incoming IQ stream, the resulting audio is encoded for compression, typically using MP3 or equivalent encoders;
  2. The waterfall/spectrum is encoded as a picture periodically refreshed for display.

Users connect to this type of software using a simple Web Browser and use the embedded audio-player to listen to the signals.

Audio encoders are now extremely efficient and their compression ratio is impressive. Typically for AM or SSB signals where the audio bandwidth is very limited (9KHz for AM) the resulting required network bandwidth is very small, hence compatible with most of the internet connections bandwidth.

The main drawback of such system is that the stream contains only audio and not the “raw” IQ band.

Cloud-SDR proposed approach

Cloud-SDR technology adopts a different approach to solve the following use-cases:

  • Provide ‘non software gurus’ and easy way to share their SDR stream,
  • True IQ stream over a limited band is required for digital demodulation or remote signal processing,
  • Multiple devices have to be remotely processed,
  • Offline processing is required periodically and nobody is available to click on the user interface,
  • The incoming stream from the SDR is too wide and only sub-channels have to be shared,
  • Streams have to be reprocessed before being available for the end-user, or multiple remote streams have to be processed for the end-result (diversity processing for example, peek the best remote location for better coverage).

Cloud-SDR system architecture is like the one described for the WebSDR approach, the main changes are on the software side, as shown in the following flow-graph:

Cloud-SDR flow graph

Diagram 4 : Cloud SDR software architecture

Here the Cloud-SDR main task is to produce a reduced bandwidth containing the raw IQ stream. As full-bandwidth spectrum survey would not be available remotely because of band reduction, a full-bandwidth FFT is processed by the server and available for remote connections.

This resulting bandwidth is then encoded with different compression-levels where only the number of bits to code the IQ samples can be adjusted to cope with the available network bandwidth. Of course this as an impact on the dynamic range.

On the client side a specific software is required to “unpack” the network stream and then do the processing. Cloud-SDR includes proprietary client software and interface (EXTIO) for most well-known software (for more details on Cloud-SDR software check the wiki).

One of the most differential feature of Cloud-SDR approach is the capability to operate in “stand-alone” or “offline” mode : processing can be described in a script file (see scripting API on wiki) that can be uploaded to the server and processed locally, in the background.

Typical application of scripting : data collection under certain conditions, automatic scanning, satellite tracking etc.

Main advantages of Cloud-SDR : all devices managed by same system, sub-channel streaming and automatic processing

Main drawbacks of Cloud-SDR : requires specific software for remote reception. MP3 streaming mode is possible to have a kind-of WebSDR mode

To summarize

  1. When only one remote connection is required and the network bandwidth is not a limitation, proprietary solutions or rtl_tcp like systems are the best option,
  2. If only one type of device (one manufacturer) is in use, use the proprietary solution if it fits your needs,
  3. When you only need to listen to analog modulations and no further processing is required, WebSDR approach is the one you need,
  4. When you need the “true signal” on a limited bandwidth or “offline” processing is required, Cloud-SDR is what you need.


Some interesting links to go further :