Over on his YouTube channel M Khanfar has put together a tutorial for an interesting idea. The idea is to use an automatic SSH connection to tell your Windows PC to run rtl_tcp whenever you open SDRTouch or RFAnalyzer on your Android device. SDRTouch and RFAnalyzer are both Android based SDR applications and rtl_tcp is a server which allows both apps to connect to a remote RTL-SDR over a network connection.
To set this up, Khanfar first sets up OpenSSH on his Windows PC which allows a secure remote connection to the PC. On his Android device he then installs MacroDroid and RaspController. MacroDroid is an app that help you automate tasks on your Android device, and RaspController is an app designed for remotely controlling a Raspberry Pi, but also works on Windows via the SSH connection. These apps are then setup so that an SSH connection to the Windows PC is automatically opened whenever SDRTouch is run. From within the SSH connection rtl_tcp is then started.
Full text instructions are available in the video description.
Automate MacroDroid with RTL_TCP through OpenSSH under Windows 10
Over on YouTube SignalsEverywhere/Harold is back with a new video tutorial that shows users how to set up a SDR# SpyServer with an RTL-SDR dongle. SpyServer is a program included with SDR# that allows you to access your Airspy or RTL-SDR dongle remotely through the internet or local network connection. Thanks to it's compression techniques and that it does most processing on the server side, it requires significantly less network bandwidth compared to a raw IQ server like rtl_tcp.
In the video Harold first shows how to access the SpyServer network in SDR# which consists of many remote SpyServers that have been made accessible to the public for free. He then goes on to explain how you can set up your own SpyServer by simply editing a text config file. He notes that you may need to perform port forwarding on your router if you wish to make the server publicly accessible.
RTL SDR Spyserver Remote SDR Setup Tutorial (on Windows)
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.
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.
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.
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)
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.
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.
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
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.
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 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.
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.