Northern
Utah
WebSDR

Nothern Utah WebSDR Logo - A skep with a Yagi 		Using "KA9Q-Radio"




Notice:

KA9Q-radio has undergone recent changes to improve efficiency and performance.  One aspect of this is that the current version found at ka9q's github rolls the interfacing of the receiver hardware directly into the main "radiod" processor rather than having external, hardware-specific modules that interface the raw samples via multicast.

What this means is that these pages currently refer to the old KA9Q-radio regime rather than the new integrated versions of radiod.  

These pages will be updated with information related to the newer version as I have time to do so.

The "ka9q-radio" is a different sort of SDR program suite, its strongest point being that it can simultaneously receive a large number of frequencies from a single piece of SDR hardware with modest computing hardware - no GPU required!

This pages provides a reference describing the use and operation of ka9q-radio - both the internals, with different types of acquisition hardware (receivers) and applications. 

Pages related to the installation and configuration of "ka9q-radio":
Using KA9Q with receive hardware:
 There is also support for AirSpy, HackRF and FunCube hardware:  The above are articles based on hardware to which I personally have direct access for testing.


Other applications for KA9Q-Radio:

Additional page(s):
Important:

This document represents an effort on my part to understand the operation of "ka9q-radio" and is not intended to be authoritative.

As such, this is a work in progress and will certainly contain many "blank spots" and errors.  What it is intended to do is to help the new user along and start to get the "feel" of how the pieces go together.

Please read EVERY document in the /docs directory of the "ka9q-radio" git - and refer back when you see something you don't understand!

What is "KA9Q-Radio" - and why is it different from other SDR programs/suites?

One of the advantages of SDRs is the capabilityof receiving multiple signals at the same time - but this is typically exploited only in a limited fashion.  The limit of this capability is a combination of both the bandwidth of the acquisition device (e.g. how much spectrum the device is inhaling) and also the processing capability of the host computer.

Up to this point, it's the latter point that has limited the usefulness/capability of many wide-bandwidth SDRs:  It is typical for each "instance" of a receiver used by a user to have to process data from the high-bandwidth acquisition stream - which may be several megasamples.  Because each per-user instance requires so much processing, this can make a multi-user receiver system "un-scalable" - that is, each user requires a significant amount of CPU processing.

In 2006, an article was published  1  that described what might be a mathematical "shortcut" when it came to processing large amounts of data.  Without going into detail, the common method for many receirs where only a single instance is required is to crunch the full bandwidth data to yield - at least in an amateur radio application - only a narrow bandwidth - perhaps a few kHz for an SSB or FM signal or even a few 10s of kHz for a waterfall.  Rather than "throwing away" much of this number crunching, it is leveraged so that for each additional instance of needing narrowband data, the already-processed data is utilized.  This method is used in the KA9Q-radio program.

As an example:  If the "csdr"  2  utility is used on, say, an RTL-SDR with 2 MHz of bandwidth, a Raspberry Pi4 is capable of only handling 4-8 simultaneous receivers before all available CPU cycles are used:  This is one of the reasons why the open-source "OpenWebRX" server isn't particularly scalable to a large number (e.g. dozens) of users.  Conversely, the PA3FWM WebSDR server  3  (which is closed source) likely (unconfirmed!) uses the techniques noted in Footnote #1 to allow hundreds of users on the same hardware platform as an OpenWebRX server that may be only to handle a half-dozen or so.

Using the aforementioned method in reference #1, a Raspberry Pi4 running ka9q-radio can simultaneously decode every FM channel in the same 2 MHz bandwidth simultaneously with processing power to spare!

KA9Q-radio is open-source and it may be found here:  https://github.com/ka9q/ka9q-radio/ - and the instructions for compiling it along with a list of dependencies may be found here:  https://github.com/ka9q/ka9q-radio/blob/main/INSTALL.txt

For more information about installing and using ka9q-radio see the Installing the KA9Q-Radio package page - link.


What ka9q-radio is, and is NOT!
 Currently, ka9q-radio has a number of included utilities for packet/APRS monitoring, decoding of WSPR and FT-8, recording audio, decoding CW, listening to wideband (broadcast) FM - and more uses are being thought of all of the time.

What hardware will it support?

At the time of writing, the following hardware is directly supported by applications included in the ka9q-radio repository:
 In theory any device that can produce a stream of I/Q (complex) or "Real" sample data can be used to feed ka9q-radio.  More specifically, since the main signal processor program in ka9q-radio (e.g. "radiod") uses multicast data as its source, any device that can be made to stream its sample data - along with the appropriate metadata - may be used making ka9q-radio essentially hardware agnostic.

Because the intent of ka9q-radio is to offer significant optimization in the processing of large amounts of signal data to yield a potentially large number of demodulated channels, it is useful to minimize hardware abstraction that can result in increased processing overhead, and this philosophy allows ka9q-radio to ingest and process over 130 MHz of 16 bit real samples from an RX-888 Mk2 on a modest Intel i5, 8-core, 3.4 GHz processor you yield hundreds of virtual receivers.  While it would be possible to successfully handle smaller amounts of data even with the added overhead of abstraction - say, via the SOAPY interface - this has not (yet) been done.

Because ka9q-radio is open source, if you have the ability to add support for specific hardware, you are encouraged to do so!

How much data will it process?

At present, the practical limit of bandwidth supported by ka9q-radio is mostly that of the input device and the amount of available CPU power.  Here are a few examples:


A bit about multicast in ka9q-radio and why it's used:

Unless you have dealt with distributing IP-video/audio or data around a local physical plant - or via a "broadcast" type distribution system (e.g. one-to-many distribution via a satellite network for media and files) you may not have dealt with multicast before.  Using UDP datagrams, it is considered to be an "unreliable" transport - but this simply means that unlike a "connected" TCP/IP socket, there's no acknowledgement - or guarantee - that data from the sender arrives at the recipient.

To those unfamiliar with broadcast-type networks this might seem like a terrible idea at first, it is actually quite useful for "local" distribution of such data, where the work "local" refers to some sort of network (LAN, within a physical plant with practically unlimited interconnected bandwidth - or a broadcast type system such as satellite) where one can reasonably guarantee that the network is robust enough to convey the data with negiligible (or acceptable) data loss.  Additionally, the "unconnected" nature reduces overhead due to the lack of acknowledgments - and most obviously because of the "one to many" broadcast nature of this protocol, this means that any number of "listeners" can use the same data without incurring additional network loading by doing so.


"You don't have a hundred sound cards"

Conventionally, a receiver could "receive" only one - maybe two channels - but with ka9q-radio there is the potential of receiving hundreds of channels simultaneously of various bandwidths and demodulation methods - but if one does that, how do you distribute such data?  While one could, in theory, have some sort of connected service that would offer an individual channel per TCP connection, another way to do this is with multicast - that is, send the demodulated data via unconnected UDP to all listeners on the local network.

Rather than have one multicast stream (address) per receiver, it also makes sense to be able to group like or related signals into streams.  Let's take a look at a few lines from "radio@hf.conf" - one of the configuration files supplies with ka9q-radio:

[WWV]
data = wwv-pcm.local
mode = am
freq = "2500k 5000k 10000k 15000k 20000k 25000k"

[WSPR]
# Bottom of 200 Hz WSPR segments on each band. Center is 1500 Hz higher
# sample rate must be 12 kHz as required by wsprd
data = wspr-pcm.local
freq = "136k000 474k200 1m836600 3m568600 3m592600 5m287200 5m364700 7m038600 10m138700 14m095600 18m104600 21m094600 24m924600 28m124600"

Within this .conf file, multiple receivers can be defined - and in the "WWV" section we see that we have defined receivers for 2.5, 5, 10, 15, 20 and 25 MHz using AM - and in "WSPR" section we see that we have defined WSPR receivers for each of the channels using upper-sideband demodulation - the "default" mode being specified in the "global" section of the .conf file earlier.

Rather than having one multicast stream for each of these channels, they may be organized into groups - and in this case, the multicast stream for the WWV receivers are associated with with the name "wwv-pcm.local" will contain sixaudio streams - each corresponding with the frequencies while the streams associated with the WSPR receivers are associated with the name "wspr-pcm.local".  In other words, there is one stream for each group of receivers.  Depending on your needs and preferences, you can construct your .conf file to have as many audio channels as you like conveyed by a single multicast stream, have one multicast stream per audio channel, or some combination of the two.



Other references:

About KA9Q-Radio:
 Another paper about the "Overlap-Save" downsampling method:


References:

1 - Mark Borgerding, “Turning Overlap-Save into a Multiband Mixing, Downsampling Filter Bank”, IEEE Signal Processing Magazine, March 2006. https://www.iro.umontreal.ca/~mignotte/IFT3205/Documents/TipsAndTricks/MultibandFilterbankd.pdf

2 - The csdr tools by HA7ILM may be found here:  https://github.com/ha7ilm/csdr This represents a "toolbox" of signal processing engines that can do things like filter, decimate, shift, demodulate, convert formats, provide AGC and more.  These tools may be useful for additional filtering of signals.

3 - The PA3FWM at the University of Twente in the Netherlands uses an A/D converter that streams raw data via an Ethernet interface to a computer that uses graphics-card processors to do the heavy-lifting.  See these pages for more information:  http://websdr.ewi.utwente.nl:8901/  and http://www.pa3fwm.nl/projects/sdr  P.T. de Boer, PA3FWM, provides a version of the WebSDR software that is similar to that operating at the University of Twente, but does not utilize GPU cores and bespoke hardware and is therefore more limited in bandwidth - but it still is extremely economical with its CPU power in servicing many users - even on computers of limited processor power allowing many times the number of users compared to OpenWebRX.  While I have no direct evidence that it does, I suspect that the PA3FWM WebSDR uses the technique described in Reference #1 to allow its very efficient use of CPU power to service many users simultaneously.

Additional information:
 Back to the Northern Utah WebSDR landing page