Nothern Utah WebSDR Logo - A skep with a Yagi
User notes/observations

The "ka9q-radio" software is a work in progress and lacks many amenities - notably a "pretty" GUI - but this does not detract from its current usefulness and power when it comes to processing large chunks of spectrum.

Please DO NOT construe any of the comments below as gripes/criticisms/complaints:  The author is fully aware that there is a lot of work to be done with regard to improving functionality, providing consistency, adding/refining features.

This page contains my observations and comments related to aspects that I've found that should be looked at for clarification, improvement, and revising as deemed appropropriate.

Meanwhile, this page can call attenation to some of these issues so that users can avoid pitfalls or - better yet - contributed to ka9q-radio to improve it.

What follows, in no particular order, are random comments/observations related to the use of KA9Q-Radio.

Configuration files may be overwritten when updates are done.

At the time of writing (20230614) if you update ka9q-radio from the git and do "make" and "make install" you will overrite the configuration files that come with ka9q-radio.

This issue is understood by the author and is on the "to-do" list to fix.

Inconsistencies related to the use of the FFT "wisdom" files.

As noted by the author of ka9q-radio in the /docs/ file there are issues with how the FFT "wisdom" file (a file that contains optimizations of the Fast Fourier Transform for your computer hardware) created/accessed/used - please read this document if you have not already done so.  FFTW3 is the heart of "radiod" - the main program that does the "magic" of ka9q-radio.

Somewhat related, there are other utilities that use FFTW3 that may have issues with using an existing FFT wisdom file.  For example, the "modulate" utility will always create a new wisdom file when it is started (causing a delay of between 5 seconds and several minutes - depending on your processor speed).  Normally, such a wisdom file is created only once, but this program doesn't see to "know" about the existing wisdom file and simply recreates it every time it's invoked.

There is no way to completely disable the squelch in FM/PM modes

The best that can be done is set the squelch thresholds to "0" or a negative number.  The documentation mentions setting the parameter "squelch-open" to something like -1000, but this only seems to work for synchronous AM reception, not FM/PM.

What this means is that if you are using the pm or fm demodulator, the squelch will always be enabled as the defaults are 8 dB SNR to open the squelch and 7 dB SNR to close it (e.g. 1 dB hysteresis).

Remember:  Unless a signal is present on the frequency and the squelch is open, radiod will not even produce a multicast stream.  If, for example, you are using the "control" program and have defined, say, ten FM frequencies to be used, you will see nothing at all from any of the ten virtual receivers until/unless there is a signal from one of them - and even then, you'll see data from only those frequencies with signals present.  Please note that the muting of the PCM data stream when the squelch is close is NOT a bug, but this behavior - and the inability to completely disable the squelch (for testing, measuring SINAD of a receive system, listening for vestiges of extremely weak signals) - can be initially confusing.

Using "powers" to obtain FFTs from multicast streams from "radiod" seems to be unstable and/or kill parts or all of "radiod".

If an analysis is done, it seems to "kill" the virtual receiver.  Example:  Using "radiod@hf.conf" with the rx888d, if one does an FFT analysis on the 5 MHz WWV, that particular multicast sub-stream will stop and not restart.  (Ubuntu 22.04)

If too many bins are requested using the configuration mentioned above, "radiod" throws a segment fault and stops.  (Ubuntu 22.04)

"show_sig" always crashes with "buffer overflow detected"

Example:  Using "radiod@hf.conf" with the rx888d will always cause this.  (Ubuntu 22.04)

"Monitor" does not mute new sessions

While the "M" command in monitor will mute all current sessions, new sessions (e.g. those that appear after the "M" command has been issued) will NOT be muted.  If you are running monitor and have a speaker turned up, but have all sessions muted, you will still hear audio from a new session when it comes up.

"rtlsdrd" does not use .config files.

At the time of writing (20230614) the "rtlsdrd" program uses only command-line arguments, not a .conf file.  It also does not have a related ".service" file.

"rtlsdrd" does not support direct "Q" input.

At the time of writing (20230614) the "rtlsdrd" program does not support the direct "Q" input for reception on HF.  This is a hardware feature present on many RTL-SDR dongles (e.g. "RTLSDR Blog V3") that allows reception from <1 MHz through 30 MHz by bypassing the onboard Raphael R820T tuner.  This capability is useful, despite the limitations of the RTL-SDR (e.g. 8 bits, no AGC, need for filtering to avoid alias responses).

"rtlsdrd" does not support manual gain control on the frequency converter

At the time of writing (20230614) the "rtlsdrd" program does not support the setting of manual gain on the R820T converter.  

It is useful to set the gain of the RTL-SDR manually in the following scenario:  In many metropolitan areas, there can be repeaters with signal levels that are >-50 dBm.  As the AGC action of the RTL-SDR will naturally set the gain to maximum in the presence of strong signals, when a signal greater than approximately -65 dB appears in the passband, the receiver will briefly overload prior to the AGC action occurring.  This causes two effects:
It would also be useful to limit how high the AGC gain could go in the absence of other signals.  In practice, the manual gain could be set for the user's RF environment emperically - by observing when the strongest local transmitters (e.g. repeaters) are active and observing the A/D's peak "dbFS" reading using the control program.

Additional information:
 Back to the Northern Utah WebSDR landing page