Using wider bandwidth receivers with a WebSDR server's 16 bit signal path

Northern 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:

Audio Devices. 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 problem, including:

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.

Comment: The "sdrplayalsa" driver has been tested with the RSP2 and RSP2pro and found to work properly. See the page "Getting the raw IQ data from the receiver " - link - for more information.

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 increasingly apparent.

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.

Comments:

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..
Looback Interface. 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 fine.

Needed modifications:

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 program/driver:

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 below.

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.

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 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

Back to the Northern Utah WebSDR landing page