Receiver Equipment - Northern Utah WebSDR

Northern Utah WebSDR
Receiving equipment and software

What is here

This page discusses both hardware and software used at the Northern Utah WebSDR as well as SDR-related topics.

In the first section we talk about the hardware - and some of the software - used at the Northern Utah WebSDR with topics ranging from the receive hardware itself, RF filtering, limitations of different types of hardware, and how to make hardware with limited capability (e.g. the RTL-SDR) work as well as it possibly can at HF.

In the second section we discuss other means of getting signals into the PA3FWM WebSDR software that provide high performance and wider bandwidth than would otherwise be possible. Specifically, the use of the SDRPlay receivers and how we can process signals and input them to the WebSDR. Additionally, we touch on alternate (open-source) drivers that can be used with the SDRPlay hardware as well as how one can leverage other software (e.g. "csdr") to cover more than one amateur band with a single SDRPlay receiver.

In the third section we discuss the ka9q-radio package. This extremely powerful package - almost unknown to the amateur computer at the time of this writing - allows the creation of many (hundreds!) of virtual receivers across a very wide bandwidth (an entire VHF or UHF band - or even the entire HF spectrum) with modest hardware - no GPU required. We expect that the principles used in ka9q-radio will, in the future, find wider adoption once its utility is discovered and understood - these both being reasons why these pages exist.

Hardware and software at the Northern Utah WebSDR

A number of different types of receive gear is and has been used at the Northern Utah WebSDR and the job of this equipment is to take off-the-air RF signals and present them to the WebSDR servers in an appropriate format. Because of the wide signal dynamics present when receive signals off the air, consideration must be given to these varying conditions in terms of filtering, signal level adjustment, and the choice of the gear itself - all while being aware of the limitations of this gear and accommodating it as much as is practical.

The articles below reflect the use of different types of gear over the years that the Northern Utah WebSDR is in operation. Some of the gear described below has been depracated/replaced with something more modern or capable - usually to acheive greater frequency coverage with a single receiver - but the discussions of the designs and techniques are still relevant.

Softrock Receivers - This page describes the "High Performance" receivers that use "Softrock" direct-conversion receivers and sound cards. These receivers cover limited bandwidth (up to about 192 kHz) but have excellent weak and strong signal handling properties.

LF/MF reception using the Softrock receivers - The Northern Utah WebSDR's coverage includes the "new" 2200 and 630 meter amateur bands and these are received via modified softrock receivers.

The use of the SDRPlay RSP1a (and others) for WebSDR use - This page describes the use of the SDRPlay RSP1a (and similar) as a "front end" of a WebSDR. Also discussed is how one receiver may be used for two or more bands simultaneously and how the raw I/Q data could also be shared with other applications.

RTL-SDR Dongle-based receivers - Described here are the "not high performance" receivers using the ubilquitous RTL-SDR dongles. These receivers cover up to 2 MHz of bandwidth, but their limited A/D bit depth (only 8 bits) means that they can suffer from too much and/or too little signal input - often depending on band conditions. Included on this page is information about how to make the most of these as well as helping to manage when multiple RTL-SDR dongles are used on a Linux-based system.

RF Downconverter for RTL-SDR receivers - While there are RTL-SDR dongles that contain built-in upconverters to allow reception across the entire HF spectrum, this may not be the best way to do it. When receiving frequencies at or above the Nyquist frequencie(s) on HF, one can downconvert to lower frequencies and get good results, all described on this page.

An AGC block for RTL-SDR receivers- Because RTL-SDR dongles have only 8 bits of A/D, their dynamic range is limited. While one can adjust the gain to fit their useful signal range "window", HF band conditions change constantly, making it impossible to keep one of these receivers's limited dynamics optimized. Preceding an RTL-SDR dongle with proper filtering and an AGC circuit can make the best of these devices.

RF Distribution and filter system - Absolutely essential to any receive system is the means by which RF is distributed - and filtered, the means by which this is done at the Northern Utah WebSDR being described on this page.

WebSDR #4 receive system - On a separate antenna, WebSDR #4 has its own RF infractructure that includes filtering and amplification.

RF System frequency response plots - During a recent site visit, the frequency versus amplitude response of most of the signal paths were analyzed in-situ.

Higher sample rates on the WebSDR's 16 bit Signal path:

Recently (as of November, 2021) we have switched many of our receivers to higher-bandwidth 16 bit receivers, allowing us to cover most of the HF bands (160-12 meters) with a single receiver instance, rather than having to split an amateur band according to the 192 kHz limit of typical sound cards (e.g. 3 receivers for 80, 2 each for 40 and 20, etc.) This takes advantage of the fact the the PA3FWM WebSDR server can, in fact, be used at 384 and 768 kHz to cover more spectrum on a single "band".

We are doing this with patched drivers and custom code to allow the interfacing of the SDRPlay RSP1a receiver into the Linux ALSA sound system, but this could, in theory, be used with any hardware that is capable of producing a 384 or 768 kHz raw I/Q stream.

We are in the process of documenting this "upgrade" and the following article(s) are available:

Operating a WebSDR receiver at 384 or 768 kHz using the 16 bit signal path - This provides a brief overview of how one might go about increasing the coverage of a signal "band" on a WebSDR server to 384 or 768 kHz on the 16 bit signal path.

Observations from using an SDRPlay RSP1 on the HF bands - An RSP1a - its performance and operating characteristics - were analyzed on the workbench and on the air and here are some notes based on what was observed.

Configuring high-rate audio loopback devices - One of the features of Linux is the ability to configure virtual sound cards. Doing so adds flexibility when sending audio (including raw I/Q streams from the receiver) from a particular device driver into another program, whether it be a WebSDR server and/or another application that might use this same receive stream. This page describes one way of setting up such loopback devices, and how to build a patched version of the loopback module that is capable of operating up through at least 768 kHz.

Creating "fplay", a version of the Linux "aplay" utility, but without the speed limit - While more recent versions of Ubuntu (and likely other) Linux distributions have ALSA kernels capable of sample rates of at least 768 ksps, many of the related utiilties do not - including "aplay". This page describes how to create "fplay", a version of "aplay" that has no such sample rate speed limit - and why this utility is helpful when implementing a "high rate" 16 bit ALSA device like the SDRPlay RSP1a.

Getting I/Q data from the receiver - This page discusses how raw I/Q data may be routed from the receiver and into ALSA. Specifically, it discusses the "sdrplayalsa" utility - code written specifically for the RPS1a, and how/why it's built-in AGC may be used.

Duplicating receiver I/Q data streams using ALSA and asoundrc - Normally, the raw I/Q data from the receiver on a WebSDR goes just ONE place, but wouldn't it be nice if that data could be replicated and used elsewhere for things like analysis, reception of digital signals like FT-8 and WSPR, a CW skimmer, logging or monitoring the health of the receiver system itself? This page describes how it's possible to get the raw I/Q data that you already have and duplicate it, making it available for other purposes to leverage the capabilities of your system?

Using CSDR for auxiliary receivers on a WebSDR System - Dovetailing with the above article, this shows how you can take the raw I/Q stream from your existing receiver and produce a separate narrow-bandwidth receiver - or even a more narrow-banded I/Q stream - to do even more things, such as FT-8 reception and generating an input to something like a CW skimmer.

Using the "libmiricsdr" utilities for reception and on a WebSDR System - As the SDRPlay drivers are not open-source, I looked into using the "libmiricsdr" utilities - notably "miri_sdr" - instead to interface with the RSP1a. This article describes how this would be done as well as a few points relating to (possible) work needing to be done to make the fully usable in this role.

Receiving on multiple bands using a single SDRPlay (or similar) receiver, stream splitting and csdr - This page describes - using the RSP1a as an example - how one may split STDOUT streams from an SDR and process them independently to receive on several bands at once.

Pages about KA9Q-Radio

KA9Q-Radio a software suite that is capable of processing large amounts of raw reciever data efficiently in a manner quite different from your typical "SDR" program. This is Linux (only) software with no GUI, intended primarly to be the "front end" of a system that is capable of handling 10s of MHz of bandwidth simultaneously (with no GPUs!) and hundreds of individual receive channels.

Examples:

A Raspberry Pi4 and an RTL-SDR dongle can be used to simultaneously demodulate every narrowband FM channel in a 2 MHz bandwidth with CPU power to spare.

Throw a bit more CPU power at it (an Intel i5) and you can demodulate APRS, Packet, and log/record every FM channel as well - and if you use a wider-bandwidth receiver like an SDRPlay RSP1a you can cover the entire 4 MHz of the U.S. 2 meter amateur band - plus a few hundred kHz on either side.

A modest Intel i5, quad core computer with an RX-888 running at 64.8 megasamples/second can simultaneously demodulate well over 100 frequency across the entire HF spectrum - which can then be used for demodulation of CW, WSPR, FT-8, SSB, etc.

For more information, see:

Using KA9Q-Radio - Link - This page links to other pages at this web site that describe how to use the various components of KA9Q-Radio as well as other resources related to it.

Notes about installing the PA3FWM WebSDR software on Ubuntu 22.04

The page, "Installing a WebSDR on Ubuntu 22.04 (notes)" (link)contains information about setting up a WebSDR on Ubuntu 22.04. While some of this information is specific to the custom configuration at the Northern Utah WebSDR, it may be of use for "out of the box" and simple configurations. It may be particularly helpful with respect to the installation of dependencies of the WebSDR binary that have since been deprecated.

Additional information:

For general information about this WebSDR system - including contact info - go to the about page (link).

For the latest news about this system and current issues, visit the latest news page (link).

For more information about this server you may contact Clint, KA7OEI using his callsign at arrl dot net.

For more information about the WebSDR project in general - including information about other WebSDR servers worldwide and additional technical information - go to http://www.websdr.org

Back to the Northern Utah WebSDR landing page