Northern
Utah WebSDR Receiving equipment Using the SDRPlay "RSP" receivers on a WebSDR
The need for more bandwidth:
In the beginning, the Northern Utah WebSDR used only two different types of receivers:
The RTL_SDR dongle.
These ubiquitous devices are capable of operating from below HF
into the low microwave range - and they are also pretty cheap:
Around $30 for a decent-quality device. The downside is
that these have little filtering and only an 8 bit analog-to-digital
converter meaning that they are very limited in terms of how well they
can simultaneously handle both weak and strong signals. Despite
these limitations, they can cover a reasonable bandwidth (typically up to about 2 MHz)
making them reasonable choices to cover larger swaths of amateur bands
- provided attention is paid to filtering and signal levels.
There are several article describing the use of the RTL-SDR at the Northern Utah WebSDR:
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.
The "Softrock".
These receivers essentially convert a portion of the HF spectrum
to audio, using computer sound cards to digitize the signals present.
With good-quality sound cards and attention to proper gain
distribution and filtering, these can offer very high performance over
a wide variety of band conditions. Because the digitization is
done using 16 bit sound cards, they can handle a much wider range of
signals simultaneously and can offer much better performance in the
amateur bands. The downside is that affordable sound cards
operate only up to 192 kHz, requiring several of these receivers to
completely cover many of the HF bands in their entirety.
There are several articles describing the use of Softrock receivers at the Northern Utah WebSDR:
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.
Figure 1:
The RSP2pro and RSP1a receivers Click on the image for a larger
version.
Newer options
Since the Northern Utah WebSDR went online, a number of newer devices
capable of providing wider bandwidth have become available for
reasonable price - namely from suppliers like AirSpy, SDRPlay, and the
FunCube Dongle folks. For the most part, the capability of these
devices are more or less equal in terms of performance as they all use
similar techniques to capture a segment of the HF spectrum - and they
do it in the same way that the older "Softrock" receivers did:
Use a local oscillator to convert a slice of the spectrum to
"audio" baseband (but this "audio" could go up to several megahertz!) and then digitize it.
Unlike lower-cost hardware like the RTL-SDR dongle, all of these
devices include various types of filtering, from that applied at the
antenna port to limit the impinging signals to the general frequency
range of interest (e.g. passing only a portion of the HF spectrum, blocking AM/FM/DAB signals, etc.)
to filters applied to the baseband after the frequency conversion to limit that applied
to the analog-digital converter. Additionally, they all have
means by which the amount
of signal applied to the analog-to-digital converter can be controlled
- usually via adjustment of gain and/or attenuation. Typically,
these devices can also capture much more than the 192 kHz of an audio
sound card, and some can also exceed the 2-ish MHz bandwidth of an RTL-SDR dongle
while doing so with more than 8 bits of resolution.
While the higher bandwidth is nice, the most important aspects to us
were better filtering, being able to adjust signal levels and
higher
analog-to-digital resolution. With none of the options mentioned
above are capable of directly digitizing 16 bits like the "Softrock +
Sound card" method, having batter filtering the ability to adjust
signal
levels allows the constant adaptation to current band conditions to
make the most of the existing capabilities.
Taking a commercial transceiver - the Icom IC-7300 - as an example, it
has "only" 14 bits of analog-to-digital conversion, but "on the air" it
performs admirably - far better in most of the ways that matter to the
typical operator than even the "best" radios of the 80s and 90s.
The reason that it can do this is that it has a large number of
filters preceding its analog-to-digital converter - and it constantly
adjusts the gain and attenuation along the signal path between the
antenna and the converter to prevent overload from strong signals as
much as practical, but also to keep signal levels as high as they can
be maintained without causing overload. Even though the IC-7300
has different architecture than the receivers being discussed (e.g. it is "Direct-sampling" whereas those that we are discussing use frequency conversion before digitization) the needs are the same: Filtering and managing of signal dynamics.
The SDRplay
As readers of this page will have observed, we chose the SDRPlay RSP1a
- mostly for reasons of price and availability - the latter being a
concern at the time we purchased them (late 2021). As mentioned before, we considered the others (notably AirSpy and Funcube)
but with similar architecture and overall performance, they didn't hold
a huge advantage. Additionally, the SDRPlay has the availability
of an API (Application Programming Interface) that allowed us to write our own programs to "talk" to it. While it is unfortunate that this API is not open source (and as such, there are issues that we cannot directly address ourselves) it has been "good enough" for our needs.
While some of the other options have better RF signal path filtering
than the SDRPlay RSP1a, that was irrelevant to us as we already have in
place band-pass filtering specific to each amateur band - both to
protect the original "Softrock" receivers from signal from elsewhere in
the HF spectrum, but also because they provide a significant degree of
lightning protection since they greatly limit the amount of energy that
could pass from a nearby strike: Because the WebSDR is remote, we
simply cannot run up there, unscrew the coax cable and "throw it out
the window" every time a black cloud rolls by.
Interfacing with the PA3FWM WebSDR
The PA3FWM WebSDR software has only two usable "input" types:
Via "RTL-TCP". This
is a TCP-IP-based socket that was included later in the development of
the WebSDR software to allow the use of the inexpensive RTL-SDR dongles
via the "rtl_tcp" utility. This utility makes the data from the
dongle - and control of it - possible via a TCP interface, usually done
as a local "loopback" device, but it could be connected to another
computer on the LAN. This interface can operate at least through
2 MHz making it quite suitable for wider-bandwidth receivers, but it it
is limited to only 8 bits of depth.
Via sound card interface.
The "sound card" interface - typically via ALSA - is native to
Linux and it handles 16 bits - but it has specific limitations of
sample rate hard-coded into the kernel which is, on modern
distributions, 768 kHz. In theory, it should be possible to
increase this, but doing so would require modification, compilation and
installation of a non-standard sound kernel on the system.
Because the use of the 8 bit RTL-TCP was a "non-starter", we
concentrated on the sound card interface. Testing indicated that
the PA3FWM WebSDR software operated properly at 768 kHz (and likely 1536 and 3072 kHz - but the kernel limitations apply here) so we developed our own set of drivers and utilities to make this happen:
sdrplayalsa - As
the name implies, this bridges between the SDRPlay API and the ALSA
interface - but it can be used to direct the raw I/Q samples from the
SDRPLay to "STDOUT" so that other utilities/processes may be applied - more on this later.
The "sdrplayalsa" utility has also be tested with the RSP2 and RSP2 pro receivers (because they were surplus to previous requirements - both models have been discontinued) and been found to work well. We have yet to do testing with the discontinued RSP1 or newer models.
fplay - This is the same
a "aplay", but patched to to allow it to operate at 768 kHz: It
would seem that while the kernel can handle 768 kHz, not all of the
standard utilities have been patched to accommodate.
fastloop - This is a
modified version of "snd-aloop" - a utility that allows the creation of
a "virtual" sound card. This simplifies the means by which the
raw I/Q samples from the receiver are placed into the ALSA system and
then used - as an audio device - by the WebSDR server.
Additionally, this can replicate the streams, making the raw I/Q
data available to other applications as needed.
For more about "fastloop", see the page "Configuring high-rate audio loopback devices" - Link
With the use of the above utilities, the PA3FWM may be operated to at
least 768 kHz, allowing single-receiver-per-band coverage of every amateur band
below 10 meters in their entirety using the 16 bit signal path.
Other tricks
Once you have a receiver interfaces as above using the sound card
interfaces, there exists the possibility of doing other things as well:
Duplicating the raw I/Q stream. As mentioned above, once you have the raw I/Q (receiver signal)
data from a receiver - whether it is from an SDRPlay or something else
- you might want to be able to do something else with it, allowing
multiple uses of the same receiver hardware. For example, if you
wish to run a CW Skimmer or have a narrower passband to receive FT-8 or
WSPR transmissions, this may be done as the following articles describe:
"Duplicating receiver I/Q data streams using ALSA and asoundrc" - Link
This article describes how you can use the rather esoteric
".asoundrc" to configure the loopbacks to split audio/data streams to
additional virtual devices. These devices could then be used as
the source for signals to be sent to other programs - or even other
computers.
"Using CSDR for auxiliary receivers on a WebSDR System" - Link This article talks about how you can take some of these other streams (as created described in the above article)
and reprocess them into lower bandwidth as needed. This article
gives an example as to how such a stream could, itself, be streamed
across a network to another computer - perhaps for use with a CW
Skimmer - or something else!
Using a single SDRPlay to receive more than one band on a WebSDR.
The SDRPlay receivers can receive up to about 6 MHz of spectrum
while still maintaining their 14 bit resolution - and since many HF
bands are less than 6 MHz apart, one can use a single unit to receive more than one band as described in this article:
"Receiving on multiple bands using a single SDRPlay (or similar) receiver, stream splitting and csdr" - LinkThis article describes how to receive both 80 and 60 meters using a single
SDRPlay receiver and feed this to a WebSDR. Also covered are some
caveats related to this having to do with appropriate selection of
sample rates and the filters built into the SDRPlay, the need for
appropriate filtering on the antenna input to reduce the probability of
overload and images, and managing of signal dynamics.
Conclusion
The SDRPlay receiver can be used to provide reasonable performance in
terms of covered bandwidth and the ability to handle the signals
present within the covered range on a WebSDR system. As with any
SDR, one should pay close attention to the signal dynamics (e.g. gain/amplification settings) as well as appropriate filtering of signal on the RF input to maximize performance under a wide variety of conditions.
Additionally, one can leverage a single receiver to provide multiple
outputs which can include anything from being able to cover more than
one amateur band at the same time or providing the raw I/Q data from
the receiver to other applications, eliminating the need for having
another (redundant) receiver to cover the same bit of spectrum.
Pages about other receive gear at
the Northern Utah WebSDR:
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.
RTL-SDR Dongle-based receivers
- Described here are the "not high performance" receivers using the
ubiquitous 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 receiver'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.
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 ka7oei dot com.
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
