Tagged: rtl_tcp

Significantly Improving RTL_TCP’s Performance with Ring Buffers

Thank you to an anonymous contributor for bringing to attention a two part blog post by Stephen Blinick. Stephen's post details how the performance of rtl_tcp can be significantly improved by modifying to code to use a ring buffer instead of using semaphore based locking. If you weren't aware, rtl_tcp is a program that allows you to run your RTL-SDR remotely, and connect to it over a network connection.

The result is a tremendous performance improvement in rtl_tcp according to Stephen. Before the changes he noted that his Raspberry Pi 3B+ could only support a sample rate of 1.92 MSPS over WiFi, and even that had 1-2 seconds of lag. After the ring buffer changes his Pi 3B+ can handle the maximum sample rate of 3.2 MSPS with zero lag. On his Pi Zero W he can achieve a sample rate of 1.92 MSPS over WiFi with minimal lag, whereas before he could only achieve 0.92 MSPS with huge 5-10 second of lag.

The patch is available as a pull request over on the Osmocom GitHub.

Unfortunately this patch might not be included in the official upstreamed Osmocom drivers because Stephen submitted the patch as a pull request to the GitHub, and Osmocom only accept patches via their mailing list. If anyone reading this is familiar with the Osmocom patch submission requirements, we'd like to encourage you to help submit this patch for consideration.

Ring Buffer Patch for rtl_tcp
Ring Buffer Patch for rtl_tcp

rsp_tcp: An rtl_tcp compatible IQ Server for SDRplay SDRs

The SDRplay team have released an updated version of a program called "rsp_tcp" (originally written by F4FHH Nicholas). This is a streaming IQ server for SDRplay devices, which is directly ported from the original rtl_tcp code that was designed for RTL-SDRs. The rsp_tcp code is fully compatible with the rtl_tcp protocol, so this should allow almost any software that accepts an rtl_tcp stream as an input to use an SDRplay device as the SDR hardware instead of an RTL-SDR.

The downside to using this server is that in order to be compatible with the standard rtl_tcp protocol, the software will downgrade the RSP data stream from 14-bits to 8-bits only, thus forfeiting the RSP's greater dynamic range. However, if a custom ExtIO plugin is used on the client software, then the full 14-bits can be restored.

On their forums the SDRplay team write:

This software is based on a fork of F4FHH’s version of RTL TCP Server. It has been updated to support the RSP features, but also contains an extended mode. The extended mode allows the client (via a compatible interface) to fully control all aspects of the RSPs, including notch filters, Bias-T enable and switching ports (where applicable)

The user guide for the server software can be found on our downloads page and also here: https://www.sdrplay.com/docs/SDRplay_RS ... _Guide.pdf

We have provided binaries for Windows, Mac and RPi on our downloads page and the source code for all platforms can be found on our GitHub repository: https://github.com/SDRplay/RSPTCPServer

To utilise the extended mode, extra commands need to be sent from the client. We have provided an example of this in the form of an ExtIO plugin. You can find the Windows dll on our downloads page and the source code for the plugin on our GitHub repository: https://github.com/SDRplay/ExtIO_RSP_TCP

In standard mode, the server will be compatible with any RTL server client.

The team also note that they have updated their Raspberry Pi SD card to include the server.

Using the VirtualHere USB Server for Remote RTL-SDR

Over on our forums one user luc4sss has been discussing a method for using RTL-SDR's and perhaps other SDR dongles remotely which does not rely on rtl_tcp, SpyServer or other SDR specific server software. Using an SDR remotely is advantageous because it can allow you to position the SDR closer to the antenna, which results in less signal loss from long runs of lossy coax cable.

Instead of rtl_tcp, luc4sss uses a program called VirtualHere, which is a server that can work with any USB device. It essentially allows you to use USB devices over a network with the remote device acting as if it was plugged directly into your remotely operated PC. The server can run on single board Linux computers like the Raspberry Pi and luc4sss has been using an $8 Orange Pi Zero 256 MB as his server.

With the VirtualHere software and RTL-SDR running on his Orange Pi Zero, he's able to connect to a remote RTL-SDR over his network. He writes that data usage is about 5 - 6 MB/s so a wired Ethernet connection or high quality WiFi connection would be required. In comparison rtl_tcp should use about the same amount of data, but server software with some compression and data saving techniques implemented like SpyServer use much less data and is efficient enough to be used over the internet.

We can see the VirtualHere software being very useful for use with RTL-SDR compatible programs that don't have rtl_tcp support, which is most of them. It should also be useful for other SDRs that don't have streaming server software available.

VirtalHere is not free as a license costs $49. But it does have a 10-day trial period which supports 1 device being shared at a time.

VirtualHere USB Network Server
VirtualHere USB Network Server

Luc4sss has also uploaded a video on YouTube that shows him running the VirtualHere server and client, and connecting to the remote RTL-SDR with GQRX and dump1090. He also shows the data usage which is about 6 MB/s when running the RTL-SDR at 2.8 MSPS. Operation appears to be problem free and with almost entirely no latency as well.

RTL-SDR over Ethernet with VirtualHere Client/Server

QuestaSDR Android App now with Remote Network Streaming: RTL-SDR, Airspy, SDRplay Supported

Back in April we posted about QuestaSDR, which had just released the Android version of its SDR software. Recently QuestaSDR programmer 'hOne' wrote in and noted that a new update has enabled remote streaming in QuestaSDR.

To get set up, just run the Windows version of QuestaSDR on a PC, and open the "SDR Server" app. Once the server is running, you can connect to it via the Android version of QuestaSDR over a network connection. The server supports the RTL-SDR, Airspy and any ExtIO compatible device such as SDRplay units. As far as we're aware, this is the only Android app that currently supports streaming from non rtl_tcp compatible units such as the Airspy and SDRplay.

hOne has been able to run an Airspy at the maximum bandwidth of 10 MSPS through his network connection. He also notes that you can now zoom into the IF spectrum in detail by using the new "IF Spectrum" plugin.

hOne also notes that the streaming feature is currently in beta, and any bugs/suggestions or feedback are welcome.

QuestaSDR Streaming over a network connection with an Airspy
QuestaSDR Streaming over a network connection with an Airspy

AirSpy windows server, android client LAN Remote

Raspberry Pi 3 B+ Released: Faster CPU, Faster Networking and Power over Ethernet

RTL-SDR dongles and other SDRs are often used on single board computers. These small credit sized computers are powerful enough to run multiple dongles, and run various decoding programs. Currently, the most popular of these small computers is the Raspberry Pi 3.

Just recently the Raspberry Pi 3 B+ was released at the usual US$35 price. It is an iterative upgrade over the now older Raspberry Pi 3 B. The 3B+ has an improved thermal design for the CPU, which allows the frequency to be boosted by 200 MHz. WiFi and Ethernet connectivity has also been improved, both sporting up to 3x faster upload and download speeds.

The Raspberry Pi 3 B+ Power over Ethernet Hat
The Raspberry Pi 3 B+ Power over Ethernet Hat

The 3B+ also implements new Ethernet headers which allows for a cleaner Power over Ethernet (PoE) implementation via a hat. Previous PoE hats required that you connect the Ethernet ports together, whereas the new design does not. PoE allows you to power the Raspberry Pi over an Ethernet cable. The official PoE hat is not released yet, but they expect it to be out soon.

The faster processing speed should allow more processing intensive graphical apps like GQRX to run smoother, whilst the improved WiFi connectivity speeds should improve performance with bandwidth hungry applications like running a remote rtl_tcp server. PoE is also a welcome improvement as it allows you to easily power a remote Raspberry Pi + RTL-SDR combination that is placed in a difficult to access area, such as in an attic close to an antenna. Placing the Pi and RTL-SDR near to the antenna eliminates the need for long runs of lossy coax cable. If the Pi runs rtl_tcp, SpyServer or a similar server, then the RTL-SDR can then be accessed by a networked connected PC anywhere in your house, or even remotely over the internet from anywhere in the world. 

The Raspberry Pi 3 B+
The Raspberry Pi 3 B+

Enumerating Multiple RTL-SDR Dongles Deterministically for rtl_tcp in Linux

Thanks to user 'luma' on our forums for submitting his technique for managing multiple RTL-SDR dongles on a Linux system. The problem is that rtl_tcp tends to enumerate devices depending on the order they are plugged in. This can create problems like not knowing which dongle is connected to which antenna without physically checking. He writes:

I was looking to utilize a couple RTL dongles to monitor two ISM band frequencies commonly used in LoRa without buying an SDR with wide enough bandwidth to cover both ranges. I pretty quickly ran into issues with how SpyServer and rtl_tcp enumerate devices, which appears to be based mostly upon the order in which each device had been plugged in.

With some work, I think I've come upon a flexible and secure solution to handle an arbitrary number of dongles on one system while maintaining deterministic control of each device. This means I can label an individual dongle, connect it to the desired antenna, and then connect to that dongle on the assigned TCP port every time, without regard to the order in which things have been plugged in.

The rest of his post shows the steps which include creating an unprivileged service user, using rtl_eeprom to set device serial numbers and using a script that automatically runs on startup which will enumerate the dongles deterministically each time.

RTL-SDR Tutorial: Setting up and using the SpyServer Remote Streaming Server with an RTL-SDR

A number of people have asked how to use SDR#'s SpyServer with an RTL-SDR. In this tutorial we will show how to set up SpyServer on both Windows and Linux systems. We try to assume as little knowledge as possible, but we do assume that you have decent experience with computers. Also for the Linux/Raspberry Pi setup we need to assume that you have some basic experience with Linux and setting up Raspberry Pi's.

What is SpyServer?

SpyServer is a free RTL-SDR compatible SDR server that is designed to work with the popular SDR# software. It is actually designed for the Airspy range of products, but the author has also made it compatible with RTL-SDR dongles. Running a SpyServer allows you to connect to and use a remotely positioned RTL-SDR over a network connection (such as a local LAN/WiFi or the Internet). Once connected, using the dongle is the same as if the dongle was directly connected to the users PC.

An example SpyServer Overview
An example SpyServer Overview (Can use an RTL-SDR instead of the Airspy HF+)

Remote servers are useful as you may want to set up an antenna in a remote location (such as up on your roof or shack), and don't want to run a long lossy coax cable down to the PC. Instead you could run Ethernet cable, or avoid cables by using WiFi. All you'd need is power for a remote computing device like a Raspberry Pi 3. Perhaps you also have a great antenna location at a friends house, or other property and want to access that antenna remotely. Or maybe you want to use your radio while travelling.

SpyServer is similar to another tool that you may already be familiar with called rtl_tcp. However, SpyServer is regarded as superior because it is signficantly more efficient at network usage. Instead of sending the entire raw data like rtl_tcp does, SpyServer only sends the IQ data of the currently tuned in signal. Waterfall data is processed on the server and sent in compressed form. There is one disadvantage to SpyServer in that it requires slightly more powerful computing hardware like a Pi 2 or Pi 3, whereas rtl_tcp can run on the lowest end hardware.

Network usage when streaming with SpyServer will be about 120 KB/s when listening to WFM and about 38 KB/s when listening to narrow band modes for one client being connected. Multiple clients can connect to the SpyServer and share the same currently tuned bandwidth.

Continue reading

Configuring OpenWRT and RTL_TCP for WiFi Streaming

In his last video YouTube user GusGorman402 showed us how to install OpenWRT and the RTL-SDR drivers on a cheap used $20 router. The idea is that the router with custom third party Linux firmware can be used as a remote device for streaming raw data from an RTL-SDR over a network connection. Normally something like a $35 Raspberry Pi is used for something like this, but an old router could be cheaper and should have even better network performance as it is designed for high data rates (assuming the CPU on your router is powerful enough to run the RTL-SDR).

In his new video Gus shows how to properly configure OpenWRT and RTL_TCP for WiFi streaming of radio data. This includes things like setting up port forwarding and determining network performance.

We’ve also seen this post by GoJimmyPi which was inspired by Gus’s original video. This is a text and screenshot based tutorial which goes through the same process.

Configuring OpenWrt and RTL_TCP for wifi