Utah WebSDR Operating a WebSDR receiver at
384 or 768 kHz using the 16 bit signal path
The "traditional" types of receivers used with the PA3FWM WebSDR server are:
Typically using the Linux ALSA interface, these are essentially
sound cards, typically coupled with a "SoftRock" type receiver to
provide RF conversion to raw, 16 bit I/Q "audio" data.
RTL_TCP Devices. These devices - typically RTL-SDR USB dongles using the RTL_TCP driver providing an 8 bit I/Q signal path.
Covering the HF bands with a WebSDR:
For best performance, the best option - to date - has been to use the 16 bit audio (ALSA)
interface - but this is limited to the rate of available audio devices
- typically 192 kHz, meaning that any amateur band wider than this would
require multiple receivers to provide complete coverage. For
example, complete coverage of 80 meters requires three such receivers
while 40 and 20 meters require two - and coverage of 15 and 10 meters
becomes increasingly problematic! The fact that the WebSDR
software has, at the time of this writing, support for only eight
"bands" means that coverage of just the non-WARC bands from 160 through
10 meters would require at least two servers.
The 8-bit RTL_TCP path and its limitations:
To get around this many WebSDRs use the RTL_TCP path which can provide
up to 2.048 MHz of coverage - but with this signal path supporting only
eight bits, a problem of signal dynamics arises, particularly on HF.
There are several ways to mitigate - but not solve - this
Using an upconverter.
Many users convert the HF spectrum to VHF where the inexpensive
RTL-SDR dongle can process the inputted signal through its R810T tuner
chip where a modicum of bandwidth filtering can be applied and AGC (Automatic Gain Control) within the driver can help prevent signal overload.
Use outboard AGC and filtering. An alternate method - used at the Northern Utah WebSDR (see the article "An AGC block for RTL-SDR receivers") uses an outboard AGC with fairly "strong" RF filtering in front of an RTL-SDR running in "direct" mode (or a downconverter, in the case of bands above the RTL-SDR's ADC Nyquist frequency of 14.400 MHz) .
Use an outboard receiver such as the RSP1a.
There exist drivers that interface with the SDRPlay RSP receivers
that interface with the WebSDR's "RTL_TCP" interface, and AGC can be
invoked using those drivers.
While the use of an AGC can help, it doesn't get around the problem of
limited dynamic range of the 8-bit path: When a strong signal is
present within the passband, the gain must be reduced to prevent
clipping of the A/D converter - but this can cause weaker signals to be
submerged into the noise - which could be a combination of receiver
noise and the noise caused by the action of the A/D converter itself
when a signal cannot be represented by a sufficient number of bits.
Despite this limitation, an 8-bit signal path can work remarkably
well under poor-to-moderately good HF band conditions, but when very
strong signals coexist with with weak signals on the same band - as
will more likely be the case as conditions on the higher HF bands
improve with increased solar activity - the limitations will become
The 16 bit ALSA path:
The only other usable path available in the WebSDR software is via the
audio interface. Typically, ALSA is used as it is "closest" to
the hardware (compared to the PulseAudio interface)
and has less overhead and latency than any other of the inputs -
including the RTL_TCP interface. At first glance, it would seem
that this path would be limited to 192 kHz due to the availability of
hardware that operates up to this rate, but this isn't the case:
Several years ago - apparently prior to 2016 - the ALSA interface
was patched to provide up to 768 kHz of throughput, possibly to
accommodate specialty signal acquisition devices. Not
surprisingly, audio cards with 768 kHz interface - if they exist at
all, are rare and expensive.
At this point, the question might be asked: Does the WebSDR
software itself support rates higher than 192 kHz, even if there are no
devices that operate at that rate?
The answer is yes. The PA3FWM WebSDR software can operate at 384 and 768 kHz with 16 bit data via the ALSA interface.
It appears that the WebSDR server may not support intermediate rates between 192, 384 and 768 kHz (e.g. 256, 352, 512 kHz). It isn't clear if this is an issue with ALSA or the WebSDR itself - but it appears to be the latter.
Operating higher than 768 kHz would appear to require - at the
very minimum - patching of the ALSA core and recompiling, something
that we have not attempted or investigated.
Getting >192 kHz data into the WebSDR:
While the ALSA core on modern Linux systems (specifically Ubnuntu 18.x and 20.x - I can't personally guarantee the same of any other Linux versions/distros)
can operate above 192 kHz, many of the ancillary programs cannot do
this and they must be patched. Specifically, the loopback
interface ("aloop") and the playback ("aplay")
programs must be modified to permit these higher rates. The
signal path for feeding data into the WebSDR via ALSA from an SDRPlay
RSP receiver, as an example, is as follows:
RSP API -> Interface Program -> STDOUT -> aplay -> Loopback Interface -> WebSDR
A bit of explanation is warranted at this point:
The "Interface Program". This interfaces with the SDRPlay RSP API (Application Program Interface) to configure the receiver (set frequency gain, bandwidth, sample rate, etc.)
and pulls the raw I/Q samples from the receiver hardware via the API.
We are currently testing an early beta version of this program
which is being called "sdrplayalsa" - see below for more information.
STDOUT. This is
just a means of spewing data - of any sort - from one interface to
another. In this case, the "Interface Program" sends the raw I/Q
data via STDOUT.
aplay. This is the
generic Linux audio player which can take the audio input from about
any source - typically a file - but it can also capture audio data via
STDOUT. In this case, it's used as a go-between to get the audio
from STDOUT to the ALSA interface, providing buffering as well as
sample conversion, if necessary..
ALSA has a peculiar device called a "loopback" which is useful to
us as it allows audio to be inputted into one audio device and have it
appear on another. This is useful to us as it allows us to a
loopback to provide a virtual sound card by which the WebSDR itself can
be configured to input this data.
A few comments:
It would theoretically be possible to write a driver to interface
with the RSP API to make the RSP device appear as a sound card.
At least for the purposes of development, this path was not taken
owing to its potential complexity. An advantage of the Loopback
interface is that once configured, it simply exists, regardless of
whether data is being fed into it. If a sound card device driver
were created to emulate a sound card, the WebSDR software would likely
require restarting if that sound device were to suddenly not exist - something that might occur if one needed to restart or reconfigure the receiver driver/hardware for some reason.
It is also possible to eliminate the "STDOUT" step altogether,
putting the I/Q data directly into the loopback interface. We
have are currently experimenting with doing this, but are having
trouble with under runs and other buffer-related problems. We can
probably solve this issue, but in the meantime, using "aplay" works
The two elements above that need to be modified are "aplay" and the
"loopback". These are both parts of the ALSA sound system and as
of the time of writing, both have built-in limits that prevent the use
of rates higher than 192 kHz. Fortunately, these are easily
patched: We have come up with an alternate version of each
fplay - This is the
"fast" version of "aplay" with the speed limit removed. This is
given a different name from "aplay" even through it is, in all other
ways, identical, to avoid confusion between it an the original.
fastloop - This is a
modification of the "snd-aloop" module called "snd-fastloop" that can
be installed and configured to automatically run upon system startup.
This is configured exactly as one would configure "snd-aloop".
As with aplay, it is differently named to differentiate itself
from the original version. Since it is a different program, one can configure both "snd-aloop" and "snd-fastloop" to operate concurrently.
"How do I do this?
The instructions on how to patch and use "fplay" and "snd-fastloop"
will be forthcoming soon. We are still putting finishing touches
on the "sdrplayalsa" program to assure stability and usability, but if
you are interested in "early beta" testing, use the contact information
If you are interested in seen this code in action, please visit the
Northern Utah WebSDR where the SDRPlay RSP1a is being used as the
receiver on the following bands:
80/75 meters on WebSDR #1
40 meters on WebSDRs 1 and 4
20 meters on WebSDRs 2 and 4
15 meters on WebSDRs 2 and 4
10 meters (lower portion) on WebSDRs 2 and 4
"Will this work with receivers other than the SDRPlay?"
While we do not have other receivers on hand to try, we do expect that any receiver from which you can get raw I/Q samples at one of the standard rates (e.g. 192, 384, 768 kHz)
could be used with this method: The means by which one would do
this would depend on the specific hardware and its audio interface.
It's possible that the Soapy interface could be used, but this has not (yet) been investigated.
As noted above, the "sdrplayalsa" driver works not only with the RSP1a,
but also the RSP2 and RSP2pro. It has not been tested with the
RSP1 or RSPduo.
More to follow.
For general information about this WebSDR system -
including contact info - go to the about
For the latest news about this system and current issues,
visit the latest news
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