Northern
Utah
WebSDR
 |
Using "KA9Q-Radio"
as a multi-channel
monitor and logger for 2 meters
Preliminary
|
What this page is about
The ka9q-radio software - with reasonable computing power - can monitor hundreds
of frequencies simultaneously, irrespective of frequency and mode:
All that is required is that your front end device is capable of
covering the frequencies of interest - and your computer having enough processing power helps too!
Also included with ka9q-radio is the ability to record multicast streams to .wav files and what this means is that whatever you are monitoring could, if you so-choose, be recorded automatically.
What is described on this page not only allows one to monitor every
2 meter FM channel simultaneously, but also record and log those
channels - this using a modestly powerful Intel i5, 8 core processor,
an $120 SDRPlay RSP1a, and ka9q-radio.
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!
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.
Note also that current versions of ka9q-radio may not directly support
the SDRPLay hardware owing to its drivers not being open-source.
|
For more information about ka9q-radio, go here:
This page has much more information about the internal workings of ka9q-radio and other examples of its use.
First, what is "KA9Q-Radio" - and why is it different from other SDR
programs/suites?
One of the advantages of SDRs is the capability of
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. Usually 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 considered to be a mathematical "shortcut"
when it comes to processing large amounts of data. Without
going
into detail, the "traditional" method for producing a single virtual
receivers 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 -
and if multiple receivers are required, it's necessary to "re-crunch"
the large amount of raw input data for each, individual receiver even
through that mathematical operation for each receiver is expensive in
CPU time and nearly identical. A far more efficient method -
potentially one that is many hundreds
of times more efficient, depending on how much "economy of scale" was
done - would be to do the "expensive" number crunching just once and
then use that already-processed data to synthesize each, individual
receiver - and it is this
method, generally referred to "Overlap and Save" - that is used by
KA9Q-Radio.
As an example of the "former" method: 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 salable to a large number (e.g. dozens) of
users. Conversely, the PA3FWM WebSDR server (which is closed source)
likely (unconfirmed!)
uses same the techniques as KA9Q-Radio - which are 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 "Overlap and Save" method in reference #1, a
Raspberry Pi4 running ka9q-radio can simultaneously decode every
FM channel in
the same 2 MHz bandwidth simultaneously
with plenty of 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
Installing ka9q-radio
Information about the installation of ka9q-radio may be found on the page: ka9q_radio_installation
Using ka9q-radio with the SDRPlay RSP1a
This page assumes the use of an SDRPlay RSP1a and for information about how that is installed and used, see the Using "KA9Q-Radio" with the SDRPlay RSP1a page.
You are not limited to using the RSP1a, however - this may also be done with the following hardware:
- The RX-888 Mk2. See the page Using "KA9Q-Radio" with the RX-888 for more information.
- At the time of this writing the program used with the RX-888 Mk2 does not support the use of its internal frequency converter
Additionally, some Airspy and Funcube SDR hardware is also supported by ka9q-radio.
Configuring the radio hardware
In this example we will be using the SDRPlay RSP1a. This
hardware is relatively inexpensive - around US$120 at the time of
writing - and it has several advantages over the cheaper RTL-SDR dongle:
- It will sample at 14 bits.
The RTL-SDR can only sample with 8 bit depth. If you are in
a metropolitan area or live within a few 10s of miles/km of a repeater,
just that signal, by itself, can exceed -50dBm. As the usable
dynamic range of an RTL-SDR is only around 55 dB at best this means
that with AGC enabled, weak signals will simply "disappear" when a
strong signal appears - and this situation is worse when multiple
signals are present.
- In other words, the SDRPlay can monitor very weak signals while simultaneously dealing with strong ones.
- It has higher sample rate capability. The RSP1a will sample a bit higher than 6 Msps with full 14 bit resolution meaning that the entire
North American 2 meter band can be monitored at the same time whereas
the maximum bandwidth of an RTL-SDR dongle is typically just north of 2
Msps.
- It has better filtering.
The RSP1a has band-pass filtering which, for monitoring 2 meters,
will reduce signal from other sources. Additionally, it has
built-in notch filters for FM and AM broadcast and the European "DAB"
signals which are around 200 MHz - which for operation in the U.S. can
reduce signal level from VHF commercial transmitters (e.g. paging, community repeater, National Weather Service).
Let us consider a file called "sdrplayd.conf", reproduced below in its entirety:
[rsp1a_test]
description = RSP1a
serial = 2255031F98
samprate = 5000000
lna-state = 1
#if-agc = yes
if-att = 50
iface = lo
; default
loopback interface, avoid wifi don't go on the LAN
status = rsp1a-status.local
data = rsp1a-pcm.local
rf-notch = 1 ; enable FM BCB notch
am-notch = 1 ; enable AM BCB notch
dab-notch = 1; ; enable DAB notch (160-230 MHz) - because we can
frequency = 145997000 ; locks tuner when manually set
Taking a line at a time:
- [rsp1a_test] - This is the name of our configuration: You can have multiple configurations within this .conf file - perhaps for different receiver hardware (if you are running multiple instances of "radiod" for reception on multiple bands) or for experimentation.
- descirption = RSP1a - This description shows up in some of the metadata/statistics and is useful for helping you know what you are looking at.
- serial = 2255031F90 - This should be changed to the serial number if the SDRPlay device that YOU are using.
- By identifying a specific serial number you can individually configure and use separate
SDRPlay devices simultaneously. Being able to do this is
especially helpful if you have specific antennas and/or filtering for
different bands feeding multiple devices.
- samprate = 5000000
- Here we specify the sample rate to be 5 Msps. This is
enough to cover the entire U.S. 2 meter band and it will cause the
RSP1a's internal 5 MHz filter to be automatically selected by the
driver as well.
- It is important to note that with the RSP1a, the only
hardware bandpass filter bandwidths available are 200, 300, 600, 1536,
5000, 6000, 7000 and 8000 kHz so even if you needed only a 3 Msps rate
to cover the European 2 meter band (144-146 Mhz) you would probably want to use the 5000 kHz filter and sample at
5 MHz anyway to avoid aliasing.
- lna-state = 1 - This parameter defines how the LNA (Low Noise Amplifier) and its attenuation is configured. An lna-state of 0 is the highest gain and is appropriate for VHF and UHF (but NOT HF!) and allows sub-microvolt sensitivity.
- A value of "1" with the RSP1a reduces the gain and
sensitivity somewhat, but sub-microvolt signals with >=12 dB SINAD
are still copiable.
- See the SDRPlay web site and the devices' data sheets (and the documentation for the API) for more information about how "lna-state" values affect gain and noise figure.
- #if-agc = yes - This line, if un-commented (by removing the "#") would enable the AGC.
- For monitoring it is preferrable to disable the AGC as
with it, the gain would be ratcheted up rather high when no signals
were present - but when a strong signal did appear, the A/D converter would be briefly overloaded, causing a "click" on all other monitored frequencies. It is possible to tweak the AGC to prevent that, but it is probably better to manually set the gain.
- if-att = 50 - This sets the IF attenuation to 50 dB.
- The IF attenuation is after the LNA, but before the A/D converter so its attenuation has relatively little effect on absolute receiver sensitivity, but it does affect how much signal reaches the converter.
- In on-bench testing, an "lna-state" setting of 0 and an
"if-att" setting of 50 allows the reception of 2-meter signals of below
1 microvolt (-107 dBm) with better than 12 dB SINAD.
- By setting the "if-att" value while using the "control" program to monitor the A/D signal level (described later in this document) when the "maximum" amount of RF is present at antenna terminals (e.g. multiple local repeaters are keyed up) it is possible to set the attenuation to attain maximum sensitivity while avoiding overload by these signals.
- iface = lo - This sets the multicast data interface to "lo" for "loopback".
- IMPORTANT note about multicast on your local network:
- If the parameter "iface" is set to "etho0" you will send multicast data across your network. Not all devices (particularly WiFi) will "play nice"
with multicast data - and on a wired network, your devices may be
blasted with multicast data which may cause them to suffer - especially
if any of them are running at 10 Megabits.
- Set the "iface" parameter to "lo" to prevent your LAN from being bombarded with Multicast data
- Because ka9q-radio uses multicast data to convey the raw signal data (and for control/monitoring) we could use "etho0" (the default Ethernet device)
instead of "lo" for the loopback. If this were done it would be
possible to broadcast this same data on the Ethernet port where - on
the same LAN - another computer could also intercept it and use the same data. This has several implications:
- Have one computer to which the SDR hardware is connected and another computer doing the processing.
- Have the one computer with the SDR hardware and doing the processing, but make that data available to another computer on the LAN as well for additional processing.
- Since - for our purposes - there will be just one computer doing the processing and handling the SDR, we'll set it to "lo".
- Note: In
this example, a 5 Msps sample rate the multicast data will have
approximately 100 Mbps bandwidth of multicast data if you were to send
it across a LAN.
- status = rsp1a-status.local - This is the metadata multicast address for this receiver hardware used for monitoring and control.
- data = rsp1a-pcm.local - This is the pcm (sample) multicast address for this receiver hardware.
- rf-notch = 1 - This enables the FM broadcast band notch - which is probably a good idea for 2 meter reception.
- am-notch = 1 - This enables the AM (mediumwave) notch. This is probably not an issue with a typical 2 meter antenna, but it's shown enabled here as an example.
- dab-notch = 1 - This enables the DAB notch. DAB (Digital Audio Broadcasting) is a service (mostly in Europe) that operates in the 200-230 MHz range.
- It is shown enabled here as this filter will reduce signals from transmitters just above 2 meters which can include paging (yes, there is still some of that), business and possibly-strong signals from your local National Weather Service transmitter.
- frequency = 145997000 - This sets the "center" frequency at 145.997 MHz, very near the U.S. 2 meter band.
- A frequency of 3 kHz below the center of the U.S. 2 meter
band was chosen as it was desirable to monitor 146.000 MHz. While
this frequency should NEVER be used for terrestrial (non-satellite)
purposes, it is often the case that people aren't aware that operating
on this frequency will cause half of their 15+ kHz wide signal to
"splatter" into the satellite sub-band.
- Because the SDRPlay uses a frequency converter in front of
the A/D, there is a narrow "hole" in the response at zero Hz. If
this "hole" lands right on the carrier of a signal, it will cause
distortion, but by moving it slightly off-frequency where any signal is
likely to be centered this issue can be avoided.
The above is all that we need to configure our RSP1a to cover all
of 2 meters, so we are ready to invoke "sdrplayd" to interface with it
and "make data" as follows:
sdrplayd -f <config _file> <configuration>
Or:
./sdrplayd -f sdrplayd.conf rsp1a_test &
Looking at this line:
- ./sdrplayd - Invoke the driver program "sdrplay". The "./" means that we use the local copy of the binary in our current directory (e.g. "~/ka9q-radio").
- -f sdrplayd.conf -
The "-f" parameter tells us to use our our local version of our
configuration file called "sdrplayd.conf" which is described above.
- rsp1a_test - This refers to the header [rsp1a_test] in our sample "sdrplayd.conf" file above and the configuration information below it.
- As noted earlier, we can have several configurations within a single .conf file where we could refer to different configurations of the same hardware or even multiple SDRPlay receivers, each with their own serial number and instance of "sdrplayd".
- & - We end our line with "&" so that it will run in the background.
Comments:
- It is also possible to run "sdrplayd" as a service: Configuration of this is beyond the scope of this document.
- If you do this be sure to configure the "sdrplay.service" file as appropriate to use your configuration files.
- The combination of setting lna-state to 1 and the if-att value to 50 results in sensitivity capable of receiving a signal with 12 dB SINAD well below 1 microvolt (-107 dBm).
- At this setting the full-scale A/D conveter signal level (e.g. the total of all signals reaching the converter)
around -40 dBm. In a populated area with multiple 100 watt
repeaters within a few 10s of miles/km a total signal power of this
amplitude is possible with a good antenna, low-loss feedline and the
coincidence of multiple transmitters being active at the same time.
If you get an error:
Pay close attention to the errors that you might get. Typical causes of errors are:
- Is the SDRplay device plugged in? It's worth checking!
- Not specifying the exact serial number of the the SDRPlay device. You must specify this exactly!
- Omitting a required field. Our example above shows a reasonable minimum of parameters required to configure an SDRPlay device.
- Invalid value within a field. Perhaps you put something wrong in a field?
Once sdrplayd is running:
With sdrplayd running, we need to set up our receivers which are invoked
using "radiod" along with a configuration. "radiod" is the heart of ka9q-radio
as it does the work of processing the massive amount of data coming in
from our receiver hardware. Even on a modest processor it is
capable of simultaneously demodulated hundreds of individual receive channels in a mix of frequencies, bandwidths, sample rates and modes.
As with the receive hardware itself, a configuration file is used to set things up and here we will use "sdrplay.conf". (Notice that this is named "sdrplay.conf" not "sdrplayd.conf").
Consider the
following:
./radiod radiod@2meters.conf &
The above will invoke "radiod" using a configuration file called
"radio@2meters.conf" and if we peer into this we'll see which frequencies
are configured - and the various receive mode. Multiple
definitions of receive frequencies and modes may be included in various
named sections. For more detailed information, see: https://github.com/ka9q/ka9q-radio/blob/main/docs/ka9q-radio.md
Our example "radiod@2meters.conf" file:
Our "radiod@2meters.conf" file used by "radiod" is used to define the virtual
receiver(s) that we might want. Let's take a look at a minimum
configuration:
The first - and required - section is the "global" section which
contains the following:
[global]
input = rsp1a-status.local
status = 2m.local
Breaking this down:
- input- This is the
name of the stream, defined in the "data" statement seen
in "sdrplayd.conf". This is the metadata stream from "sdrplayd"
and it is used to convey the sample rate, but depth, center frequency
and the other parameters of the raw A/D data from the receiver.
- status
- This defines the stream containing (what else) but the
status of this radiod instance - that is, it contains information about the individual receivers that we will be defining.
This represents the minimal configuration in the [global] section of the "radiod" configuration file, using defaults values for blocktime, overlap, etc. (see the discussion about "radiod" on other pages.)
Let's take a look at the sub-sections located after the [global] section:
[2m RPT output]
mode = pm
data = fmrpt_out-pcm.local
freq = "145m190 145m210 145m230 145m250 145m270 145m290 145m310 145m330 145m350 \
145m370 145m390 145m410 145m430 145m450 145m470 145m490 \
146m620 146m640 146m660 146m680 146m700 146m720 146m740 146m760 146m780 \
146m800 146m820 146m840 146m860 146m880 146m900 146m920 146m940 146m960 146m980 \
147m000 147m020 147m040 147m060 147m080 147m100 147m120 147m140 147m160 \
147m180 147m200 147m220 147m240 147m260 147m280 147m300 147m320 147m340 \
147m360 147m380"
[2m RPT input]
disable = yes
mode = pm
data = fmrpt_in-pcm.local
freq = "144m590 144m610 144m630 144m650 145m670 145m690 145m710 145m730 145m750 \
145m770 145m790 145m810 145m830 145m850 145m870 145m890 \
146m020 146m040 146m060 146m080 146m100 146m120 146m140 146m160 146m180 \
146m200 146m220 146m240 146m260 146m280 146m300 146m320 146m340 146m360 146m380 146m400 \
147m600 147m620 147m640 147m660 147m680 147m700 147m720 147m740 147m760 \
147m780 147m800 147m820 147m840 147m860 147m880 147m900 147m920 147m940 \
147m960 147m980"
Here we have two sections that define a number of
frequencies. In the top section called [2m RPT output] we define
the output frequency of every 2 meter repeater pair. We can also see from the line "mode = pm" we are using the FM demodulator with audio de-emphasis (which is the amateur standard worldwide). Finally, we see the line "data = fmrpt_out-pcm.local" where this defines the multicast address of the stream that will convey the audio of all of these channels.
In the bottom section - [2m RPT input] - we have a similar listing - this time with the corresponding repeater input
frequencies. In this case we have included the line "disable =
yes" to disable every receiver in the [2m RPT input] group as an
example as to how to disable entire sections.
Note that in the above, long lines are broken up using the backslash
"\" character to make one line - all frequencies being contained in
quotes. Alternately, multiple "frequency" lines could be used,
noting that the valid prefixes are "freq", "freq0" (with a zero), freq1, freq2 and so on through freq9. You can use only one of these eleven "freq" prefixes in each section.
The above does not include other frequencies of interest, such as those
used for simplex operation - but these may be included with additional
sections. Be wary of including frequencies on which packet
operation occurs (e.g. APRS, those around 145.01 MHz) unless you really want to listen to (and record) such activity.
Note:
I live in an area with 20 kHz channel spacing on 2 meters so the frequencies listed above reflect what is in
use. The above lists should be modified to reflect the frequency
use in your area.
A word about ssrc and frequency descriptions:
The "ssrc" (Stream Source Identifier) value - which is used to identify a component of a multicast stream containing pcm data - is
automatically derived from the frequency value by removing everything
but the digits - but its exact representation will depend on how you
defined the frequency in the relevant radiod ".conf" file.
For example, here are some sample frequency descriptions - all for the same frequency of 14.234 MHz - but with DIFFERENT ssrc values:
- 14234000 - SSRC = 1234000
- 14m234 - SSRC = 14234
- 14m2340 - SSRC = 142340
- 14234k - SSRC = 14234
- 14234k000 - SSRC = 14234000
As you can see, it is imperative that your frequency definitions are consistent.
There are some "gotcha's", however. Let's presume
that you have defined several frequencies with exact kHz boundaries -
perhaps a repeater output - but then you find out that there's a
repeater running 2.5 kHz deviation on 145.1375 MHz. Previously,
you may have defined frequencies like 146.520 MHz (the U.S. national simplex frequency) as
"146m520" which results in an SSRC of "146520". which has six digits.
The possible issue arises when you define the frequency of
145.1375 MHz as "145m1375" which has an SSRC of "1451375" which is seven digits.
The to most obvious options are:
- Define all 2 meter frequencies with 100 Hz accuracy so that all SSRC values will have seven digits
- Just keep track of what you have done knowing that your
"id.txt" list will have 2 meter SSRCs with both 6 and seven digits.
There is functionally nothing wrong with this, but you'll have to
remember that if you happen to sort by frequency, it will end up in the
wrong place!
"fftwf_export_wisdom_to_filename"
errors when starting radiod
If you see the errors "fftwf_export_wisdom_to_filename" produced by
"radiod" when it is starting, that does not
mean that it won't work properly, but it likely will not be as
CPU-efficient as it could be as the FFT "wisdom" needed to optimize
operation of the algorithm is missing. To help resolve this -
and
potentially reduce CPU utilization - do the following: sudo chown
<username> /var/lib/ka9q-radio/wisdom -
substituting for <username> the name of the user under
which you are running ka9q-radio.
Getting audio
output (to speakers):
Being able to "hear" the demodulated audio is a
quick
and easy way to verify that everything is working - even if this isn't
likely to be the main purpose to which ka9q-radio would be put.
At this point it is recommended that you place a .wav file on
your test system and then use "aplay" to test the speaker: If
your filename were "music.wav", simply do: play music.wav and
if all goes well, you should hear it play: If not, read the
next section, below.
Having verified via "top" or "htop" that sdrplayd and radiod are running,
you can test it via a local speaker if you like but note that unless
you need an analog audio output of some sort, it is not even necessary to have
any audio playback devices on your system - but it's a nice
tool to have. If your computer has a sound card, connect a
speaker to it and do the following: "aplay -l":
You should see a list of available devices such as the
following:
****
List of PLAYBACK Hardware Devices ****
card
0: PCH [HDA Intel PCH], device 0: ALC662 rev3 Analog [ALC662 rev3
Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
You may see other devices, particularly if you have an HDMI or similar
monitor that can convey audio - but the above is typical of an analog
audio output device on a motherboard.
What to do if you see "No
audio device" when you try to play your local audio file (e.g. "music.wav")
If you do not see
any available sound cards - but you know
that one is present (a
plug-in card, on the motherboard), it may be that you have
been the victim of a quirk recent versions of Linux (e.g. Ubuntu 22.04) where
parts of the the sound system seem to "go away" at random - likely after a
reboot/update. To repair this, try the procedure at the very
top of this page: http://www.sdrutah.org/info/high_rate_loopback_websdr.html
to re-load/restart the audio devices once again.
If you get an error like "play WARN alsa: can't encode 0-bit Unknown or not applicable"
This is a vexing problem to many trying to use their sound cards on recent version of Ubuntu and it seems to be related to pulseaudio and/or pipewire. If you get this error - and audio does not play, try disabling pulseaudio:
systemctl --user stop pulseaudio.socket
systemctl --user stop pulseaudio.service
After doing the above, try playing the audio file again: It may work now, even if you still get the "can't encode 0-bit Unknown" error.
If you get an error related to pipewire and a report that no device is
available - despite "aplay -l" showing devices, you may need to
uninstall pipewire. This is done using the following commands:
systemctl --user unmask pulseaudio
systemctl --user --now disable pipewire-media-session.service
systemctl --user --now disable pipewire pipewire-pulse
systemctl --user --now enable pulseaudio.service pulseaudio.socket
sudo apt remove pipewire-audio-client-libraries pipewire
Once you have
a working audio path
Once you have verified that an audio device is present and will play
the audio file that you have put on the computer, consider the
following command:
monitor fmrpt_out-pcm.local
This will play - to local speakers the audio of every active frequency using the multicast address of "fmrpt_out-pcm.local". In the example above, these are all of the frequencies in the section beginning with [2m RPT output].
We know from the output to screen when "radiod" started and from the contents of "radiod@sdrplay.conf" from the
"[2m RPT output] section that the name of the stream is "fmrpt_out-pcm.local"
represent the multicast for the 2 meter receivers (plural!) and upon
this invocation we will see a screen like this:
KA9Q Multicast Audio Monitor: fmrpt_out-pcm.local
------- Activity -------- Play
dB
Pan SSRC Tone Notch
ID
Total Current Idle Queue
+0 0
147120
K7JL Farnworth Peak
(SLC)
899
899
121
+0
-25
147260
AC7O Promontory Pk.
(Ogden)
254
254 1:46 0
+0 25
147180
K7JL Hidden Peak
(Alta)
849
849
47 0
+0
-38
146620
W7SP Farnsworth Peak
(SLC)
91
91 2:08 0
+0 13
147040
K7DAV Antelope Island
(Farming
0
0 53:54 0
+0
-13
147300
N7DAV (North Salt
Lake)
22
22 3:18 0
+0 38
146840
N7PCE Jordan Valley Hosp.
(Wes
45
45 7:38 0
+0
-44
146880
KD0J Salt Lake Comm. College
(
3
3 44:10 0
+0 6
145490
K7JL Promontory Point
(Ogden)
15 15
29:57 0
+0
-19
146980
W7EO Delle Peak
(Tooele)
10
10 3:34 0
+0 31
145390
23
23 103
+0
-31
145450
WB7TSQ Butterfield Peak
(SLC)
11 11
25:58 0
+0 19
146900
KE7EGG
(Ogden)
12
12 1:13:41 0
+0 -6
146700
KC7IIB Ensign Peak
(SLC)
5
5 22:24 0
+0 44
145290
K7UB Brigham
City
0
0 22:27 0
+0
-47
146760
W7SP Lake Mountain
(Orem)
23
23 8:18 0
+0 3
146780
K7UVA Lake Mountain
(Orem)
22
22 1:37 0
+0
-22
145370
1
1 2:35 0
+0 28
147340
K7UCS West Mountain
(Payson)
19
19 1:28 0
+0
-34
147220
K7UB Riverside
(Tremonton)
32
32 58
0
+0 16
147280
K7UCS Lake Mountain
(Provo)
20
20 1:26 0
+0 -9
145430
K7UB
(ATK)
7
7 1:03 0
The columns, in order:
- dB - This is is the "volume control for the channel.
- pan - The being
output is two channel and this determines from which audio
channel(s) the audio is coming: Negative is left, positive is
right.
- tone - This is the frequency of the subaudible tone.
- notch - This indicates if the notch filter for the tune frequency is enabled
- ID - This is a user-defined identification from the file id.txt - see more about that file below. Updates to this file take effect when monitor is (re)started.
- The items in the example above are from a version of id.txt that I edited to include local repeaters.
- In the Activitiy column we have:
- Total - The number of seconds that this channel was active since monitor was started
- Current - The number of seconds that this channel has been active during the current period of signal detection (e.g. squelch being open).
- Note: The "current" and "total" times are usually the same
indicating that this parameter is not actually what it seems to be or
isn't working as expected.
- Idle - The number of minutes and seconds since the last activity from this channel. This field will be blank if the channel is active.
- Play Queue - This shows the current buffer level (queue) for the current channel. It will be non-zero if the channel is active.
IMPORTANT:
- The "fm" and "pm" modes in ka9q-radio have the squelch ENABLED by default.
- UNLESS a signal is present on a given frequency you will not hear audio. Additionally, the audio from the receiver will not be streamed at all unless the squelch is open.
- What this means is that if you have no signals present (e.g. no antennas connected) you will see nothing from the monitor program.
- If your list happens to include linked repeaters you may hear echoes or odd phasing effects (including audio cancellation) due to delays in the audio between the transmitters.
If all goes right, you should hear audio from the speaker from EVERY frequency that is active.
In other words, if there are a dozen different repeaters active and
being received, you will hear a dozen different audio sources. Fortunately, you can control chaos so from within the monitor program, press the "h" key to get a list of options
- the most relevant for the current discussion shown below:
- ↑
↓ - Select prev/next session
- ⤒ ⤓
- Home/End select first/last session
- ⇞ ⇟
- Page up/Page down select prev/next session page
- d
- Delete session
- r
- Reset playout buffer
- m
- Mute current session
- M
- Mute all sessions
- u
- Unmute current session
- U
- Unmute all sessions
- A
- Toggle start all sessions muted
- - +
- Volume -1/+1 dB
- ←
→ - Stereo position left/right (pan)
- v
- Toggle verbose display
- h
- Toggle help display
- q
- Toggle quiet mode
In other words, you can move up/down between receivers to
select that on which the controls (keys)
will operate.
When you first do this, it's recommended that you hit the "M" key (uppercase) to mute
ALL
receivers - and then use the up/down arrow to select which one(s) you
wish to hear and then hit the "u" (lowercase)
key to unmute that receiver. You can then use the plus and
minus keys to adjust the volume, left/right arrows to pan (move between speakers),
etc.
To exit monitor hit "CTRL-C".
Comments:
- If the "M" command is used to mute all sessions, this will NOT apply to new sessions that appear (e.g. sessions that appear after the "M" command has been issued will NOT be muted.)
- When adjusting the volume, use the +/- key at the top of the keyboard (below the function keys) rather than those on the numeric keypad.
The "id.txt" file
Note: Unlike other configuration files, this resides in the same directory from which "radiod" is called.
This file contains a list of frequencies or more precisely, a list
of SSRC values with an accompanying description in the format on each
line - and this is how we populate the ID column seen in the display produced by the monitor program, above.
# <your comment here>
<ssrc> <description>
The format couldn't be simpler! Comment lines begin with a hash (#).
The possible "gotcha" is the ssrc values. As noted above, it helps to be consistent!
Antenna/signal level considerations
As with any receiver, the gain must be set properly and when you have a
wideband device that is inhaling a fairly large chunk of spectrum, this
is even more important as it is not just one signal that could overload the receiver, causing distortion and intermodulation products but the total signal power of ALL signals that fall with the passband of the receiver.
In our example of sdrplayd.conf
above we set the bandwidth to 5 Msps - which will automatically cause
the selection of the 5 MHz filter in the SDRPlay which means that all signals +/- 2.5 MHz from the center frequency will reach the analog-to-digital converter.
For example, consider the settings of lna-state and if-att in the sdrplayd.conf file we discussed earlier:
- The combination of setting lna-state to 1 and the if-att value to 50 results in sensitivity capable of receiving a signal with 12 dB SINAD well below 1 microvolt (-107 dBm).
- At this setting the full-scale A/D conveter signal level (e.g. the total of all signals reaching the converter)
around -40 dBm. In a populated area with multiple 100 watt repeaters
within a few 10s of miles/km a total signal power of this amplitude is
possible with a good antenna, low-loss feedline and the coincidence of multiple transmitters being active at the same time.
Here are a few considerations when setting gain and lna parameters:
- Set the gain/amplification only as high as absolute necessary.
There is nothing at all to be gained if the gain/lna configuration is set higher than is required to hear weak signals other than overload and distortion.
- Enable the FM broadcast filter.
In the sdrplayd.conf file we have enabled the FM broadcast filter just to reduce the total amount of energy in the RF signal path.
- Enable the DAB filter. This is also enabled in the sdrplayd.conf file to reduce signals in the 160-230 MHz area which can include the NOAA NWS (Weather) transmitters.
Determining/monitoring signal levels
The control program -
while primarily intended to allow adjustment of the virtual receivers
in terms frequency, bandwidth, mode, gain, bandwidth, etc. it also
provides useful data about the signal level applied to the A/D
converter and may be used to determine the appropriate gain in the
antenna signal path to prevent/minimize overload.
This program may be invoked as follows:
control <pcm multicast name> -s <ssrc>
As in:
control 2m.local -s 146620
Details:
- 2m.local - This is the name of the metadata multicast stream defined in our example file radiod@2meters.conf file on the data line in the [global] section.
- -s 146620 - This ssrc represents the frequency 146.620 MHz
When invoking this program you can select any ssrc that exists within the .conf file to see the statistics of the A/D converter even if that frequency is not active - but if that frequency is active, you'll see information specific to it.
Take this screen shot as an example:
Near the top and center there is a column labeled RSP1a (this is the "name" field in sdrplayd.conf) and below it the gain is shown as being 50 dB, which is also our if-att selection as well. The line below this - "A/D -6.3 dBFS" - tells us that our A/D converter is a bit more than 6 dB below full scale and is likely to be experiencing occasional overloads.
A bit below this is the line "Input -59.1 dB" which
actually refers to the amount of signal our virtual receiver is seeing
from the in-frequency signal. It is possible - if AGC is disabled
and the RF signal path parameters affecting the level ("lna-stata" and "if-att" in the case of the "sdrplayd.conf" file) to correlate this value with the absolute power level of that signal in dBm.
For more information about the control program see the page ka9q-radio command overview - link.
Making recordings automatically
With multiple receiver operating concurrently it is possible to make recordings (logs) of everything that is received using the pcmrecord utility.
Consider the following command line:
./pcmrecord -v -s -m 0.25 -t 20 -d ~/recordings/2m fmrpt_out-pcm.local &
Breaking it down:
- /pcmrecord - This utility will record to .wav files every audio stream on the multicast address - in this case "fmrpt_out-pcm.local"
- -v - Verbose mode (Optional). This is useful for debugging as it will send to STDOUT information whenever a recording is started/stopped.
- -s - This will create subdirectories for the individual .wav files using the ssrc of the audio source (e.g. receiver) as the name of the directory.
- Example: If the ssrc of a receiver on 146.620 MHz is
"146620", recordings from that frequency will go in a the subdirectory
specified by the -d parameter.
- If "-s" is not specified, all files will be placed in the directory specified by the -d parameter.
- -m 0.25 - This sets the minimum
duration of a file in seconds. If there is just a burst of noise
or a very fast "kerchunk" and the file is less than this setting in
duration, it will be deleted.
- -t 20 - Recording timeout in seconds. This will stop the recording after the stream (and thus signal)
has disappeared for 20 seconds and then close the file. This
timeout is used for preventing the creation of many, many small files
during a QSO.
- -d ~/recordings/2m - This cause the recordings (and their subdirectories if the -s parameter is specified) to be placed in a directory called "~/recordings/2m".
- Comment: You may have to manually create the director(ies) specified with the -d parameter.
- fmrpt_out-pcm.local - This is the multicast data stream containing the audio of the frequencies to be recorded.
- In our example "radiod@2meters.conf" file this is the address in the data field of the [2m RPT output] section.
- & - Placed at the end of this line, pcmrecord will run in the background.
What will happen
Whenever a signal appears on one of the frequencies
belonging to the multicast data stream, a recording will be created.
This file will be written in the ~/recordings/2m/<ssrc> directory with the filename with the ssrc and time in UTC embedded in the form of <ssrc>k<yyyy>-<mm>-<dd>-<hh>T<mm>:<ss.s>Z.wav
For example, if a receiver monitoring 146.620 MHz detects a
signal at 0045:39.5 UTC on June 18, 2023, the resulting file would be:
~/recordings/2m/146620/146620k2023-06-18T00:45:39.5Z.wav
This file will be a 1 channel, 16 bit, 12 ksps .wav file.
Notes:
- The recordings are stopped/started because the
PCM stream associated with a frequency will start and stop as the
squelch opens and closes. For this reason, recordings that are
automatically started and stopped with signals can be done only using
the FM modes (FM and PM) and not SSB.
- If you wished to have separate recordings monitoring the repeater inputs, one would invoke another instance of pcmrecord using the multicast address of those frequencies. In the radiod@2meters.conf example above, that address would be "fmrpt_in-pcm.local"
Warning:
It is entirely up to the user to devise a means by which the number of .wav recordings is limited as pcmrecord
will continue until your drive space is full. As such it is
recommended that recordings be placed on a different device than the
operating system to prevent the system from crashing should its drive
space be consumed.
Conclusion:
By putting together several pieces in ka9q-radio it is possible to not only monitor multiple frequencies at the same time. Additionally, a recorded (audio) log of all of these frequencies can be automatically made. If desired, it is possible to configure a system where every FM channel on one or more band is recorded and logged when there is activity.
I'll leave it up to you to figure out why you might want to do this.
For more information about ka9q-radio, go here:
This page has much more information about the internal workings of ka9q-radio and other examples of its use.
TO DO:
- Show how the above pieces may be run as a service.
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