Northern
Utah
WebSDR

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

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!

For more information about ka9q-radio, go here:

Using KA9Q-Radio - link

This page has much more information about the internal workings of ka9q-radio and other examples of its use.


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

Hardware requirements:

This article describes using the RX-888 (Mk2) SDR which can operate at a sample rate exceeding 120 MSPS, implying a serial data rate well above 3 Gbps.  What this means is that for the RX-888 a USB3 port is required with the RX-888 being connected directly to it rather than through a USB hub.  Additionally, mid-high range Intel i5, i7 processor is necessary to operate the RX-888 at or above 60 MSPS - the rate at which it can inhale the entire LF, MF and HF spectrum.

As noted elsewhere in this document, ka9q-radio will also work with other popular SDR hardware:  These other receivers typically operate at lower bandwidths and may not require a USB3 interface or as-powerful processing - but the discussion of the use of these other devices is not covered here.  (To Do:  Another document giving a brief overview using these other devices.)
Additional installation instructions:

Also, be sure to read this file:  https://github.com/ka9q/ka9q-radio/blob/main/docs/notes.md as it contains information about configuring multicast and the local DNS needed to resolve the hostnames.

After installing and building ka9q-radio, run the following commands (sudo may be required):

 mkdir /var/lib/ka9q-radio                          Note:  This may fail if it already exists
chown <username> /var/lib/ka9q-radio               Substitute the user name under which you are running "ka9q-radio"

It may be worth verifying that /var/lib/ka9q-radio/wisdom is "owned" by the user running "ka9q-radio"

Also make sure that this directory - and the wisdom file - belong to the same group under which you are running "ka9q-radio" using "chgrp".  If, when starting "radiod" you see an error related to the wisdom file it probably has to do with access to it.

Connecting the RX-888

Comment:  Until the firmware has been loaded by the driver it will not enumerate as a USB-3 device.

FFT "wisdom" file:

Once you have installed ka9q-radio, execute the following to optimize the operation of the FFTW3 algorithm.  The data that this produces - the "wisdom" file - is specific to every computer and running this optimizes performance on the hardware that you are using.

time fftwf-wisdom -v -T 1 -o wisdom rof500000 cof36480 cob1920 cob1200 cob960 cob800 cob600 cob480 cob320 cob300 cob200 cob160

NOTE:  This may take many minutes - or even hours to run, depending on your computer hardware.

Once this is done, take the resulting file - "nwisdom" - and place it in /etc/fftw - but back-up the previous version that was there!

For more information about this, see:  https://github.com/ka9q/ka9q-radio/blob/main/docs/FFTW3.md
Also recommended:

It is recommended that you also install "Avahi" for local DNS name resolution of the multicast streams using the name rather than the IP address - one method being to do:  snap install avahi

After this is installed, enable it by typing:   sudo systemctl start avahi-daemon.service - and then verify that it is running by typing:  sudo systemctl status avahi-daemon.service

The use of this will be discussed later.

To Do:  See if there is a way to install Avahi using "apt install" rather than Snap as it is desirable to uninstall Snap as it can operate in the background and "break" an already-working system - particularly after a reboot.

IMPORTANT - Back up your .conf files!

As of the time of this writing (June, 2023) the default configuration files WILL BE OVERWRITTEN every time you do an update/make of ka9q-radio.  Both the files in the home "~/ka9q-radio" and "/etc/radio" directories can be overwritten.

What this means is that if you modify the original configuration files (e.g "/etc/radio/rx888d.conf", "/etc/radio/radiod@hf.conf" - and those in the "ka9q-radio directory) you will LOSE those modifications when you do an update.

When you make changes to ANY configuration file, be sure to save a copy elsewhere, and be prepared to restore it after you do updates.

It is on the list of future updates to change this behavior.



The "magic" of "ka9q-radio":  One input/multiple outputs:

In the simple case, let us presume that you have a single SDR of some sort: KA9Q-radio supports several receivers, including the RTL-SDR, HackRF, AirspyHF, Funcube Dongle, SDRPlay devices and the RX-888 - and more may be added in the future as this is open-source.

Let us suppose that you wish to receive audio from, say, 22 frequencies simultaneously - all WSPR frequencies on the LF, MF and HF bands (14 frequencies - including two each on 60 and 80 meters), all WWV signals (2.5, 5, 10, 15, 20 and 25 MHz), all CHU frequencies (3.330, 7.85, 14.66 MHz) the purposes of propagation monitoring.  Conventionally, one might configure 22 audio channels in ALSA/Pipewire/Pulse and while this is possible, it gets cumbersome:  What if you also wanted to monitor the FT-8 and FT-4 channels as well - adding at least another 20 audio streams?

A usable work-around would be to convey these demodulated audio streams via multicast.  This means of propagating data via UDP dates back to at least the late 1980s and is widely used to convey video streams over LANs:  In this case, we could use this transport method to loop data to the same computer to which the receiver is connected - but we could also send this same data to one or more computers on the same LAN, each one taking the data that is relevant to its needs.

While this means of transport is elegant in its simplicity, it does have a few caveats:

Using KA9Q-radio:

IMPORTANT:  This document - as is KA9Q-radio - is a work in progress and will evolve.  I (the author of this document) am learning the various aspects of this utility as well and errors, misunderstandings and omissions are surely going to appear.  Please consider this document to be a first step in getting acquainted with this software.

Comment:  Various pieces of KA9Q-radio may be configured to start/operate as a service - but at the time of this writing, I could not get this to work reliably and is a work in progress.

Example:  A multi-channel receiver using the RX-888 MK2

The RX-888 MK2 is a relatively inexpensive SDR that is capable of operating at up to at least 120 MSPS, allowing it to cover from VLF through the 6 meter band simultaneously.  It also contains a converter that allows a chunk of higher frequencies (30MHz-2GHz) to be covered as well.  This receiver is a successor to the RX-666 and RX-888.  For the purposes of this discussion, we'll only consider its use in "baseband" mode - that is, direct sampling of the 0-60 MHz spectrum.  (It is unknown by the author of "rx888d" will work with the RX-666 and "non MK2" version of the RX-888:  It probably will, within limitations - but this remains to be tested.)

Other devices are/have been available that can cover all of HF - namely the KiwiSDR, Red Pitaya and a few others - but these have leveraged the use of FPGAs (Field Programmable Gate Arrays) to do the massive, parallel processing required to inhale and process this data.  An alternate scheme - instead of an FPGA - would be to use GPU (Graphics Processors) cores to do lots of parallel processing - a scheme employed by the University of Twente WebSDR  4  .  While simultaneously processing many dozens (or perhaps hundreds) of discrete "receivers" is not possible using the brute-force method using "csdr" as described above, it is far more possible with today's higher-power processors (Intel i7 and i9) without the need of GPU cores leveraging the techniques employed in KA9Q-radio.

Rather than using Ethernet hardware as is done at the University of Twente to convey the raw receiver data a long distance across CAT-5 Ethernet cable, the RX-888 uses multi-gigabit capability of the USB3 interface.  Presuming that the host computer has well-implemented USB3 hardware, it should be able to handle the nearly 4 gigabits/second of serial data from the RX-888 running at well over 60 MSPS.

Starting the receiver:

Presuming that an RX-888 (MK2) is plugged into a USB3 port on a reasonably-powerful computer - a higher-end Intel i5 or medium-high end Intel i7 is suitable - the following line will start the receive portion:

From the directory containing the complied binaries, execute the following line:

./rx888d g5rv &

This will start the "rx888d" binary using the "g5rv" configuration contained within the file "rx888d.conf" - the "&" at the end will cause this to run in the background.  Taking a look at this file we see the configuration of the RX888 hardware itself - and the name of the configuration which appears to be "g5rv" - likely after the antenna with which KA9Q was testing:

If you get an error:

If you get an error - such as "Error or device could not be found, try loading firmware rx888_init() failed" unplug the USB connection to the RX888, wait 5 seconds, and try again.

If you get an error that might lead you to believe that there is an issue connecting the device via the USB port, go to the Troubleshooting the USB connection section of this page.

 Starting rx888d as a service:

The above shows "rx888d" running as a program, but it may be started as a service with the line:

sudo systemctl start rx888d@g5rv.service

To determine success, do the following:  sudo systemctl status rx888d@g5rv.service - or you could also look at "top" or "htop" to verify that it is running.

To terminate the service, do:

sudo systemctl stop rx888d@g5rv.service

Comment:  As of 13 May, 2023 the above command may not work until and unless you have manually started and stopped rx888d from the command line (e.g. "./rx888d g5rv &").  There appears to be an issue related to a missing dependency (perhaps an alias, dependency or environment variable) that prevents the service from starting unless it has been previously run (and stopped again) from the command line - this issue is being investigated.


Once you have successfully started rx888d

Presuming that you have gotten rx888d running - either from the command line or as a service - it's worth examining a bit about the configuration.

The configuration for the rx888 may be found in the file rx888d.conf  - but note that the working version of this file will be found in /etc/radio  - so if you make any changes, you'll need to do so there, likely requiring sudo to edit it.

Note:
You can find a copy of "rx888d.conf" in the local directory (e.g. "~/ka9q-radio") but be aware that this is not used by default and changes to this "local" file will not be reflected in the operation.

Let's examine the contents of and example rx888d.conf file below:

[g5rv]
# ka9q customized
description = "G5RV RX888"
firmware = SDDC_FX3.img
samprate = 64800000    ;  2^8 * 3^4 * 5^5
# needs fftw3 wisdom and/or fft-threads >= 4 and some buffer tuning
# seems to lose data in the network path
# forward FFT for 129,600,000 Hz, 20ms and overlap = 5 is 3240000
#samprate = 129600000    ;  2^9 * 3^4 * 5^5
iface = eth0               ; force primary interface, avoid wifi
status = rx888-status.local
data = rx888-pcm.local
ssrc = 10
;gain = 1.5 ; dB
gain = 10 ;dB - near floor of NF curve, still not too high for my G5RV
gainmode = high ; higher gain range

In the above we see, among other things:
Verify that "rx888d" is running using the "top" or "htop" utility - or do "ps aux | grep rx888d"

Once RX888d is running:

With rx888d running, we need to set up our receivers which are invoked using "radiod" along with a configuration.  Consider the following:

./radiod radiod@hf.conf &

The above will invoke "radiod" using configuration file "radio@hf.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

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

The first - and required - section is the "global" section which contains the following:

[global]
overlap = 5
blocktime = 20
input = rx888-status.local
samprate = 12000
mode = usb
status = hf.local
fft-threads = 4

Breaking this down:
Let's take a look at one of the sub-sections:

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

This defines an output multicast stream that contains individual WWV demodulation channels on the six WWV/H frequencies using AM.  Since defined the "default" rate of 12 kHz in the [global] section, this is what will be used.

It's worth noting the "data" section:  As with the "rx888d.conf" described above, the name here is hashed to create an IP multicast address (e.g. 239.x.y.z).  Because this address is a hash of the name given here (e.g. "wwv-pcm.local") this address will always be the same if the name remains the same.  At present, the easiest way to determine the IP address used is to carefully watch the output when radiod is started:  This (voluminous) text will include the name of the sub section ("WWV" in this case)  and the multicast IP address - which would be "239.188.31.156".  Typically, the numerical address would not be used, but rather the host name "wwv-pcm.local" would be resolved by the DNS.

As mentioned above, a single multicast stream can carry multiple audio channels using the SSRC to identify/use the sub-stream for a particular receiver - and in the above we see that we have defined the use of six frequencies on which we will receive WWV simultaneously.  By default, the SSRC will be the frequency with any non-numeric characters removed.  What this means is that contained within the "239.188.31.156" multicast stream, ssrc 2500 has the audio from 2.5 MHz, ssrc 10000 has the audio from 10 MHz, and so-on.  As defined in the "global" section, the default audio sample rate is 12 kHz for each of the receivers.

Note:
If we wish to override the default SSRC as defined by the "frequency number" we can add the line "ssrc = X" where "X" is a 32 bit unsigned value defining the SSRC.

In another sub-section we see:

[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 5m287200 7m038600 10m138700 14m095600 18m104600 21m094600 24m924600 28m124600 50m293000 144m488500"

Note:  You may put comments in the definition by starting the line with the "hash" symbol (" # ").  This may be used to indicate for other users (or the "future you") what you had in mind for this section, or you could have multiple versions of a particular line, using the

This section shows the implementation of of at least one WSPR receiver on every band from 2200 through 2 meters using the default sample rate of 12 kHz and (also) the default mode of USB as defined in the "global" section.  

In this case, upon invocation of radiod we see that the multicast address for "wspr" is 239.72.42.12 and in the above, we see the individual SSRC values based on frequency:  The value of "136000" is for 136 kHz, "7038600" is for 7.0386 MHz and so-on.  Because the default mode and sample rate set in the "global" section is USB and 12 kHz, respectively, this is what will be carried on the multicast stream.

Note:

To do:  Determine how to identify and use the individual multicast streams

     - The "data" string in radio.conf is hashed to produce the 239.x.y.z multicast IP address:  According to ka9q-radio.md this name is in an SRV DNS record of type _rtp._udp
    - Note that the multicast IP addresses appear in ARP tables of neighboring machines



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 rx888d 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 239.188.31.156  - or you could use the stream name, as in:  monitor wwv-pcm.local

We know from the output to screen when "radiod" started that "239.188.31.156" - and from the contents of "radiod@hf.conf" from the "WWV" section that the name of the stream is "wwv-pcm.local"  represent the multicast for the WWV receivers (plural!) and upon this invocation we will see a screen like this:

KA9Q Multicast Audio Monitor: 239.188.31.156
                                                                 ------- Activity -------- Play
  dB Pan     SSRC  Tone Notch ID                                 Total   Current      Idle Queue
  +0   0    15000             WWV                                    5         5             104
  +0 -25    20000             WWV                                    5         5             104
  +0  25     5000             WWV                                    5         5             104
  +0 -38     2500             WWV                                    5         5             104
  +0  13    25000             WWV                                    5         5             104
  +0 -13    10000             WWV                                    5         5             104

If all goes right, you should hear audio from the speaker containing all six WWV channels so do not be surprised if it sounds very noisy.  To control these, press the "h" key to get a list of options - the most relevant for the current discussion shown below:
 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".


Getting a specific audio source from a stream

While it is possible to use other tools to extract a audio from a multicast stream (To Do:  Discuss other methods in this or another document) the "pcmcat" tool allows you to do so.  Taking the example of the WWV receivers again, consider the following line:

./pcmcat 239.188.31.156 -s 10000 | aplay -r 12000 -c 1 -f s16_le

If you have installed "Avahi", you could alternatively have used the line:  ./pcmcat wwv-pcm.local -s 10000 | aplay -r 12000 -c 1 -f s16_le
If all goes well (e.g. rx888d and radiod are running) you will hear the 10 MHz WWV audio.

In the above we see the multicast IP address for the WWV receivers - but following the "-s" parameter we see the "ssrc" - in this case "10000" representing 10 MHz (or another number if we had used the "ssrc" parameter when we defined the receiver).  Following this we see that we have piped - via STDOUT - the audio to "aplay", specifying a sample rate of 12 kHz (-r 12000), a monaural source (-c 1) and the format of our audio (-f s16_le) which is 16-bit signed, little-endian.

If desired, you could pipe the raw audio somewhere else - perhaps to a file - or use SOX to write it to a .wav file, instead as this example:

 ./pcmcat wwv-pcm.local -s 10000 | sox -t raw -r 12000 -b 16 -c 1 -L -e signed-integer - out.wav

This will record the 10 MHz WWV receiver, via "STDOUT" from pcmcat to the file "out.wav".

To make it record for 2 minutes, the following will work:

timeout 120  ./pcmcat wwv-pcm.local -s 10000 | sox -t raw -r 12000 -b 16 -c 1 -L -e signed-integer - out.wav

Within ka9q-radio is another utility called "pcmrecord" that can record every virtual receiver within a group defined in the radiod.conf file simultaneously (e.g. all six WWV signals could be recorded at once.)  For more about "pcmrecord", see the page  ka9q-radio command overview - Link.


Mode definitions

For more details about the "mode.conf" file and the parameters within it, see the page:  Configuration files in KA9Q-Radio - link.

In the configuration file for "radiod" (e.g. "radiod@hf.conf") we see the use of modes such as "am" and "usb" but you might wonder how these are defined.  The answer to this lies in the file "modes.conf" where we see - in each individual section  - the definition of of how this mode is defined in terms of sample rate, actual method of demodulation, filter bandwidth, etc.

While many of the common "modes" are included in "modes.conf", you can define and add your own mode:  Perhaps you need an upper-sideband receiver centered on 1500 Hz that is 400 Hz wide for WSPR - you could do that!

As an example how these are defined, consider the [am] section of "modes.conf":

[am]
demod = linear
samprate = 12000
low = -5000
high = 5000
recovery-rate = 50
hang-time = 0
envelope = yes

 Now, consider the [cwu] (upper-sideband CW) section:

[cwu]
demod = linear
samprate = 12000
low =  -200
high = +200
shift = +500
hang-time = 0.2
Now, a "non-linear" mode:

[fm]
demod = fm
samprate = 24000
low =  -8000
high = +8000
deemph-tc = 0
deemph-gain = 0
threshold-extend = no ; don't interfere with packet, digital, etc

Contrary to common parlance, the mode amateurs use on VHF and UHF and call "FM" is really phase modulation - but "fm" is operationally identical to "pm" if, during transmit, the audio is pre-emphasized (boosted) at a rate of 6dB/octave and then de-emphasized (filtered) at the same rate on receive.  "True" FM is used for digital modulation such as that used for D-Star, C4FM, etc.

Finally, "pm" - the receive mode that is appropriate for typical amateur "FM" operation on the VHF/UHF bands:

[pm]
demod = fm
samprate = 24000
low =  -8000
high = +8000
squelchtail = 0
threshold-extend = yes ; PM assumes voice mode, so enable this

For this, the "squelchtail" is specified in the number of "blocks" (defined in the main receiver definition - typically 20 milliseconds) so a value of "0" would mean no squelch tail.  For this, "threshold-extension" is turned on (OK for voice - not recommended for any sort of data) and for +/- 5 kHz deviation, the same +/-8000 Hz (16 kHz) bandwidth is used.  It's worth noting that de-emphasis when using "demod = fm" is on by default, making it appropriate for the "pm" mode used by amateurs on the VHF and UHF bands.

For more information about the parameters found in "modes.conf" and other files refer to:

Receiving wspr on multiple bands simultaneously

Among other things contained in radiod@hf.conf are (most of) the LF, MF and HF WSPR frequencies.

From the invocation of "radiod" we know "239.72.24.12" to be the multicast address of all of the WSPR decoded audio (this address will be the same unless the "data" entry in the "wspr" section is changed).

Consider the following line:

./wspr-decoded 239.72.24.12 &

Or, if Avahi is installed, the line:  ./wspr-decoded wspr-pcm.local &

Presuming that wsjtx has been installed this will cause audio files to be collected in subdirectories of "ka9q-radio" named with the tuned frequencies along with other files such as "ALL_WSPR.TXT".

NOTE:  "wspr-decoded" is hard-coded for 2-minute WSPR transmissions:  It is not directly suitable for other related modes such as FST4W or modes with other than 2-minute intervals, but it could be modified to do so.

For arbitrary-length modes and to apply audio to multiple processes, it might make more sense to use "pcmcat" (described above) to directly obtain an audio stream that can be used to create .wav files.  Multiple instances per band could be called to simultaneously create 2, 5, 15 and 30 minutes files - the only penalty being a commensurate increase in CPU and RAM usage.


Troubleshooting RX-888 USB connectivity.

If you are still getting errors that might indicate that there is something amiss with the USB interface, make sure that you have a proper USB3 "Type B" cable.  This cable - which should have come with the RX-888 - looks like a printer cable, but it has an extra protrusion that is used to convey the extra connections needed for USB3:  A "standard" USB cable will not work properly.

To do more troubleshooting, do the following line:

sudo dmesg | grep -i rx888

If the RX888 has been enumerated and the firmware has been loaded, you should see something like:

usb 2-4: Product: RX888mk2

The "2-4" portion tells which USB port/interface to which it has connected - and the fact that the system "knows" that it's an "RX888" at all implies that we have successfully loaded the firmware.

Further examination may be done by "grep"ing the USB port.  Taking port 2-4 as the example from above, we can do:

sudo dmesg | grep -i 2-4

And we should see something like this:

usb 2-4: new SuperSpeed USB device number 2 using xhci_hcd
usb 2-4: New USB device found, idVendor=04b4, idProduct=00f1, bcdDevice= 0.00
usb 2-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 2-4: Product: RX888mk2
usb 2-4: Manufacturer: sdr prototypes
usb 2-4: SerialNumber: 0009030300983617

Of particular importance is the line containing "new SuperSpeed USB device" indicating that it has negotiated using full USB3 speeds - an absolute necessity for full-spectrum HF reception.

As you attempt to start "rx888d" - if you get an error along the lines of "Error or device could not be found, try loading firmware" you may need to add some UDEV rules as follows:

In /etc/udev/rules.d/99-rf103.rules put the following lines:

SUBSYSTEM=="usb",ENV{DEVTYPE}=="usb_device",ATTRS{idVendor}=="04b4",ATTRS{idProduct}=="00f1",MODE:="0666"
SUBSYSTEM=="usb",ENV{DEVTYPE}=="usb_device",ATTRS{idVendor}=="04b4",ATTRS{idProduct}=="00f3",MODE:="0666"

* * *

If you got nothing from the above "sudo dmesg | grep -i rx888" statement it might mean that the firmware hasn't been properly loaded into the RX-888's USB interface - or that the RX-888 has been unplugged and plugged in again.  Loading firmware can be done only by starting the RX-888 driver successfully:  Until this is done, it will show up as an "ordinary" USB device, not as an RX888.

Prior to the firmware being loaded successfully, we can do the following steps to verify that the hardware is there:

Do:

sudo dmesg | grep -i cypress
If the RX-888 is connected, you should see something like:

usb 1-8: Manufacturer: Cypress

The "usb 1-8" portion tells us that it is currently enumerated on USB port/device 1-8.  If you see more than one entry like the above, it might be that you have connected more than one RX-888, or possibly that you have more than one device using the Cypress chipset:  If so, disconnect the RX-888 and run the line again an see what disappears - and if something does, that will be the RX-888.

Now, if we do:   lsusb | grep -i cypress we might see something like:  

Bus 001 Device 003: ID 04b4:00f3 Cypress Semiconductor Corp. FX3 micro-controller (DFU mode)

This line tells us that it's awaiting download of firmware

Once you have started "rx888d" - either as a program or a service - and successfully loaded the firmware the RX-888 should enumerate properly.




For more information about ka9q-radio, go here:
Using KA9Q-Radio - link

This page has much more information about the internal workings of ka9q-radio and other examples of its use.




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/MultibandFilterbank.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 - IGMP (Internet Group Management Protocol) is used to set up "local" groups of hosts.  In the context of this article, a "group" might be a number of hosts that require multicast data from a source on specific portions of the network, but not everywhere.  The ability to compartmentalize where multicast data is sent can prevent it from flooding to other devices on the network.  See the article:  https://en.wikipedia.org/wiki/Internet_Group_Management_Protocol  

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

TO DO:




Additional information:
 Back to the Northern Utah WebSDR landing page