Nothern Utah WebSDR Logo - A skep with a Yagi Northern Utah WebSDR
High radio audio sources for the PA3FWM WebSDR using FIFO sources from the RX-888.

Overview

Traditionally, ALSA or some other sound system has been used for the 16 bit signal path into the PA3FWM WebSDR.  At the Northern Utah WebSDR, we have developed a number of tools - including "sdrplayalsa" and "fastloop" - that provide a path into the ALSA sound system from this hardware from SDRPlay hardware such as the RSP1a/b.  As the Linux sound systems are typically limited to 768 kHz, this has been the bandwidth limit for the PA3FWM WebSDR.  This information does not apply to the 8 bit "RTL-SDR" signal path.

While a bit klunky and hair-pulling, the ALSA sound system is very flexible, allowing you to duplicate an I/Q stream from receivers to be sent to multiple places if desired (e.g. CW skimmer in addition to the WebSDR) if you wish - but this isn't always necessary.  Additionally, if using "fastloop", a kernel update will typically "break" it, requiring it to be recompiled/reinstalled - but if one turns runs a CLI (console-only, no GUI) version of Ubuntu, removes SNAP and turns off automatic updates, this isn't so much of a problem.

More recently, other receive hardware has become available - namely the RX-888.  The "ka9q-radio" software has been optimized for use with devices like the RX-888 and is capable of ingesting the entire HF spectrum and outputting I/Q streams of arbitrary bandwidths on arbitrary frequencies.  The RX-888 - unlike similar devices like the Red Pitaya - interface via USB3 which means that it can sustain a high enough data rate to represent this spectrum in its entirety, without compression.

As it turns out, the PA3FWM WebSDR software does not require the source of 16 bit I/Q data to be an audio device - a "file" will do, specifically a FIFO device, completely circumventing the need for ALSA or any other Linux-based sound interface.  What's more, since the use of a FIFO is not subject to the 768 kHz "speed limit" of the audio system, higher rates are possible - including 1536 kHz.

Note:  This page won't describe the installation or configuration of ka9q-radio in detail but rather the details needed to interface with ka9q-radio after multicast streams have been defined.

For more information see:
 Getting the multicast data

Presuming that you have already set up ka9a-radio, it's possible to pipe the I/Q data from the multicast stream to a FIFO device - and then into the PA3FWM WebSDR.

For example, consider the following line:

    mkfifo ~/websdr/fifo/fifo-80m

This will create a "file" called "fifo-80m" (e.g. "80 meters") in a sub-folder called "~/websdr/fifo".

We can then dump data from our multicast source into this "file" as follows:

    pcmcat websdr_768pcm.local -s 3700  > ~/websdr/fifo/fifo-80m

The above line does the following:
 Comments:
The definition of multiple channels being defined in the "radiod@xxxx.conf" file (where "xxxx" is your custom name of your .conf file) as follows:


Configuring the PA3FWM WebSDR

In the "websdr.cfg" file we would refer to our FIFO device on the "device" line where we would have formerly referenced the audio device, as in:
band 80m
centerfreq 3700
device /home/websdr/fifo/fifo-80m
samplerate 768000
gain -25
swapiq
hpf 0
noiseblanker 30
antenna dipole
extrazoom 1

An explanation of the parameters:

Additional information:

To prevent drop-outs, it may be necessary to add some buffering to the FIFO.  A useful too for this can be "mkbigfifo" found at this GIT:  https://github.com/biowdl/mkbigfifo.  Of course you will need to have the appropriate version of Python on the computer.

The "mkbigfifo" utility would be used to create the FIFO as follows:
./mkbigfifo.py -s 65536 ~/websdr/fifo/fifo-80m &

This would define a FIFO with a 64k buffer as defined in the "mkbigfifo" documentation.

It's also possible to use "stdbuf" to invoke a buffer in the pipe as in:

    pcmcat websdr_768_80-pcm.local -s 3750  | stdbuf --output=64k dd bs=64k > ~/websdr/fifo/fifo-80m

Whether or not one would need either of the above buffering methods depends on how "busy" your machine will be - and the amount of buffering.  

Putting it into a script:

The above does not include a sample script to start the FIFOs and the "pcmcat" instances.  When you do this, be sure to include at least the following:
pkill -f "mkbigfifo.py"

This should kill all running "mkbigfifo" instances.
rm -f ~/websdr/fifo/fifo-*

This will remove the existing FIFOs.
killall -q pcmcat

This will kill all instances of "pcmcat".  

The above assume that you wish to kill ALL instances of "mkbigfifo" and "pcmcat" on your computer:  If you want to selectively stop specific processes (e.g. the need to start/stop a specific band, if you have them running elsewhere) you'll have to define them explicitly.

Finally, I would recommend a "sleep 1" (to pause a second) between each invocation to allow processes to start.

Concerns when using receive hardware that "inhales" the entire HF spectrum

On this page we have discussed using the RX-888, which can operate at up to 130 megasamples/second and cover from LF through 6 meters.  While this is technically possible, there are a few practical concerns that also apply to ANY receive hardware that does full-spectrum direct sampling across the HF spectrum including the KiwiSDR, Red Pitaya and anything else.

Practically speaking, most users run the RX-888 at about half the maximum sample rate (typically 64.8 MHz) but this means that the built-in Nyqyuist filter (set for 60 MHz) is not properly effective:  The addition of a 30 MHz low-pass filter is strongly recommended in this case.  In any case, it is also recommended that there be effective filtering to prevent ingress of FM broadcast band signals no matter what sample rate you choose for your RX-888.  
 As noted above, operating the RX-888 at 130 MHz will allow it to cover 6 meters, but it will be extremely deaf.  If you wish to use the RX-888 for only 6 meters then a simple RF preamplifier will be adequate, but if you wish to receive HF and 6 meters simultaneously you'll likely need to construct custom hardware to handle the 6 meter signal path separately from the HF signals and combine the two at the input of the RX-888.

Signal dynamics and gain

It may be argued that 16 bits is simply insufficient to handle the dynamics of all signals from across the HF spectrum over a wide range of propagation and environmental conditions.  The use of the "shelving filter" to selectively attenuate low HF frequencies more than high HF frequencies is one technique to maximize utility, but here are a few other things to consider - whether you are using an RX-888 or not:
 Whatever your receive hardware may be, you should do the following tests:
 Remember:  With any receive system, having just enough gain is as much as you need - having excess gain will serve only to reduce the capability of the receiver's handling of many strong signals simultaneously and degrade performance.

Comments:
Planning FFTs for band 3... done.
, Can't set audio data format to 16 bit little-endian.
, Can't select 2 input channels.
, Can't set fragmentsize.
, Can't set input sample rate to 768000.

Despite this, the WebSDR will start and produce the expected results - if everything else is configured appropriately!
Conclusion:

This gives, in a nutshell, the methods that may be used to obtain >768 KHz of coverage on a PA3FWM WebSDR - and also how to avoid using any ALSA or sound system devices.

This is primarily useful for interfacing with "ka9q-radio" where any number of arbitrary receivers of may be defined:  If other virtual receivers are needed, adding them to ka9q-radio will impose minimal additional CPU overhead.  This method may also be used with "sdrplayalsa" and other software where "pipes" or similar may be used to move data.
* * * * *

Acknowledgment:  I would like to thank Rostislav, UW5EHX for suggesting this method and noting also that it works at 1536 kHz.



Additional information:
 Back to the Northern Utah WebSDR landing page