Showing posts with label Receiver. Show all posts
Showing posts with label Receiver. Show all posts

Thursday, March 20, 2025

SNR, a better way to give a signal report

Or why I believe a 59 report is meaningless!

Receiving an S9 signal doesn't automatically mean that the signal is clear and intelligible. The S-meter (or signal strength meter) gives us a snapshot of the signal strength, but it doesn't tell us anything about the Noise Level (NL) or the Signal to Noise-Level Ratio (SNR), which are crucial in understanding the overall quality of the received signal. A signal might be strong in terms of the S-meter, but if the noise level is similarly high, then the actual communication may be difficult or unclear. Most of today's operators will add an Audio quality report of 5, to make the report 59 which in amateur jargon means that the received transmission supposed to be of excellent quality e.g., an excellent signal. However, to often we hear stations giving a report of 59 or even 59+ only to go on to request a retransmission. Audio quality reports have a scale from 1 to 5 and are given by the operator. With 5 being excellent and 1 being very poor. This relies heavily on the operators HSP, and as we all have experienced, those "Audio reports are ...." well let's say that those reports are not very reliable.
For instance, if the noise level at the receiving station is S8, and the received signal is S9, the SNR would only be 6 dB. Which would mean that the signal is just slightly stronger than the noise. This could make understanding the transmission challenging, even if it shows up as S9 on the meter. On the other hand, if the noise level is low (say S3) then an S9 signal would be much clearer as the SNR is now 6x better i.e. 36dB vs 6dB. 

The Importance of SNR

SNR (Signal to Noise-Level Ratio) gives us a much better sense of how usable a signal is as it compares the strength of the desired signal to the current background noise. A high SNR means that the signal is much stronger than the noise, making it easier to decode and work with. On the other hand, a low SNR means the noise is almost as strong or stronger than the signal, which can lead to poor communication quality or to a completely unreadable signal.
To calculate the SNR we need two signals, the noise level  and the signal strength of the received transmission, both numbers need to be a power level (dB). And since the levels will be rather small we'll use the Decibel in milli Watts e.g, in dBm.

Determining the Noise Level

Determining the Noise Level (NLof our receiving system is rather easy, all we have to do is tune to a channel where no signal is present and record the S-Value, as shown in the below picture. 


Next we tune to a channel with a transmission and note the recived signal, say S9+10 as depicted below.


Converting S-Values to Power

From the IARU Technical Recommendation R.1:

S1 corresponds to -121 dBm
S9 corresponds to -73 dBm

 And the steps between S-Units are in 6 dB increments. This means:

S1 to S2 = -121 dBm to -115 dBm (6 dB increase)

Above S9 we tend to add a dB value to the S9 value, i.e. 

S9 to S9+10 = -73 dBm to -63 dBm (10 dB increase) 
 
S dbm uV
click to view larger file

So, to calculate the SNR:

  1. Convert both, the received signal strength and the noise level into power levels (dBm).
  2. Calculate the difference between the received signal and the noise level (e.g., SNR = Signal Power - Noise Level).

Using the above values:
Using the above graph we convert the received noise level of S4 to a power level of -103dBm and the received signal level of S9+10 to -63dBm. 
Using the below formula:
 
SNRdB = (Signal-LeveldBm) - (Noise-LeveldBm
  
SNR = (-63) - (-103)
 
SNR = 40 dB

This would mean that the signal is 40 dB above the noise level, which is a strong signal and would be very clear.

Conversely, if the received signal would be S9 (-73 dBm) and the noise level would be S8 (-79 dBm), the SNR would only be 6 dB.

While still a reasonable SNR, it would be somewhat noisier than the 9+10 example, and we might find that we would need to ask for a repeat transmission occasionally.

Potential Benefits of Using SNR instead of S-Meter Values

  • More Accurate Representation of Signal Quality
SNR considers both the signal strength and the noise level, which gives a much clearer idea of the actual quality of the communication link.
  • Increased Context
By reporting SNR, operators would have more information about whether the signal is being received clearly or if noise is impacting communication.
  • Noise Awareness
Instead of just reporting a S9 signal, one could be aware of how much noise is present at the receiving station. This could help with adjusting the transmitting stations output power, e.g. increasing the output from 100W to 400W, which is a power level increase of 6dB and as such should, in principal, add 6dB to the SNR.
 
Remember bigger SNR = better signal quality.

Challenges

  • SNR requires additional measurements

To report SNR, operators would need to be able to measure or estimate the Noise Level  (NL) at their location. This can be challenging if the equipment doesn't provide this information directly. Most modern SDR systems do have the ability to read signal strength as a power or voltage level.
  • S-meter and SNR are still subjective
While SNR is definitely more meaningful than just reporting an S-value, it still depends on the equipment's ability to measure signal strength and noise level accurately. Again, most SDR systems are very accurate.

Conclusion

Reporting 59 without any context of the noise level doesn't provide the full picture. Shifting to SNR as a primary metric would give operators a much better understanding of the quality of the received signal. It would not only account for the signal strength but also how well the signal stands out from the noise in the environment, leading to clearer communication and fewer misunderstandings.

Incorporating SNR reports into amateur radio communication could definitely improve clarity and signal quality perception. Perhaps this is something more operators could adopt in their day-to-day operations.

Most SDR (Software Defined Radio) already have the ability to report the signal strength as a power or voltage level. A few lines of code and the SNR could additionally be displayed.

Appendix

NOTE: The SNR changes with the receiver bandwidth however, for the purpose of a quality/signal report it is not nesseary to include the receiver bandwith. 

Monday, March 11, 2024

Is my NOISE FLOOR (NF) really worse than yours ?

Well, let's answer that question first so you can move on to better things in life. And the answer is:

No it is not, because I use an S-Value indicator (S-Meter) that follows a Standard! The so called 6dB per S-Point (6dB/S) standard!

And that's it, 73 and catch you on the bands (as they say).

Oh, hello you are still here. So, it looks like you would like to know a bit more about this phenomena. Well, then read the below or maybe this "What is your S-Meter Really Displaying".

As far as I know, most Amateur Radios Transceivers from the three main manufactures, ICOM; YAESU and KENWOOD seem to display a 3dB/S scale below S9 (-73dBm). 

So if I read a Noise Floor (NF) of S3 on my S-Meter, which by using the 6dB/S standard would be -109dBm or -2.0dBμV NF.  And my QSO partner, i.e. you, is stating a NF of S2 which, using the applied 3dB/S scale would be a NF of -94dBm or -13dBμV.  

So is my NOISE FLOOR really worse than yours?

Let's have a look at the below two Tables, the left one is scaled in 6dB per S-Value i.e. my S-Meter and the right in 3dB per S-Value like your S-Meter. 

Received Power (Zin = 50 Ω)Signal Strength
S-Value 6dB step
Received Power (Zin = 50 Ω)Signal Strength
S-Value 3dB step
-121 dBm1-97 dBm1
-115 dBm2-94 dBm2
-109 dBm3-91 dBm3
-103 dBm4-88 dBm4
-97 dBm5-85 dBm5
-91 dBm6-82 dBm6
-85 dBm7-79 dBm7
-79 dBm8-76 dBm8
-73 dBm9-73 dBm9

Doesn't that shed some light on this (issue)?

According to the IARU Handbook (Ver 9.0) Paragraph 4.1.3 S-Meter Standards:

  1. One S-point corresponds to a level difference of 6dB.

  2. On the bands below 30 MHz a meter deviation of S-9 correspond to an available power of a CW signal generator connected to the receiver input terminals, of -73dBm.

  3. On the bands above 30 MHz a meter deviation of S-9 correspond to an available power of a CW signal generator connected to the receiver input terminals, of -93dBm.   

It has been a Standard for quite a while, but it seems that it has not been adapted widely.

Signal Level Strength Meter Calibration and IARU Standards


Monday, May 29, 2023

A Multi Frequency WSPRing (whispering) System using KA9Q-Radio

The "KA9Q Radio software suit" is a an ingenious sort of a SDR program suite. It is capable of receiving a huge number of frequencies simultaneously. I believe that this is a unique feature of this applications. It seems to go back to the original *nix philosophy of "small is beautiful" e.g. small well written applications that do one job and do this one job very well. Because there is no graphical ballast, it will perform its task on the most modest comput-hardware. Meaning it will run on a Raspberry Pi system starting with the Pi3. Note, that there is no need for an expensive GPU nor the need to use virtual audio cables or a Soundcard for that matter.

Because of the "multiple frequencies simultaneously" capability I've set up a WSPR receiver for my QTH so that during times that I do not operate I can at least monitor band activity and/or propagation. Initially I will monitor from LF (136kHz) to the end of HF (28MHz). If this is going to workout well I will also start building a system for VHF/UHF.  

Depending on the SDR one is going to use there is a requirement for a fast to really fast USB port. In my case I'm going to use the RX888M2, which needs a really fast USB3 port to stream 32 MHz of bandwidth in one go across the port. However, if I would use my Pluto or RSPdx and any of the TV-Dongles I can get away with a speedy USB2 port and for the SDR-IQ with it max 192kHz a slow USB port will do.

I can't stress this enough, the use of good usb cables is a requirement (not to long and it should have good shielding). Additionally, even though all my cables come with a molded choke, I do add additional choke(s) to all of my cables. I've had good success with that however, if that doesn't help reducing the noise from the USB/PC connection then "these" are apparently very good in suppressing CMC noise (EMI).

Below are the steps that I used to get the system up and running. And I believe that if you follow those steps you will be able to get a working "Multi Frequency WSPR receiving System" up and running in no time.

I've had a spare little PC (NUC) lying around (I7-4765) with 8GB of memory and a 250GB SSD which I bought second hand for about A$250. My installation is based on Debian Version 11.7 (Bullseye) and all following steps are based on this OS. The reason to use the NUC was to have both the SDR and the WSPR decoder running on a single host. The WSPR decoder is chewing up all the available CPU resources. 

If you go with the Pi solution I recommend at least a Pi4-4GB and to install Debian Bullseye.

WARNING: If you are going to use a Raspberry PI as the compute resource make absolutely sure that you have enough current available to support the Pi and the RX888! I use a home made 5V 10A Power-supply which is feed of the shacks 12V rail. I've tried with a powered USB-HUB to no avail!

INFO: I have highlighted text in bold, this is so one can copy and then paste the copied text into a terminal instead of typing everything into the terminal. Don't forget to press <Enter> at the end. Command returns are displayed in courier.

NOTE: sudo didn't work for me out of the box.

There are many ways to fix this issue however, I did it this way:
$ su -
 echo "$(who am i | awk '{print $1}') ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers.d/$(who am i | awk '{print $1}')
chmod 440 /etc/sudoers.d/$(who am i | awk '{print $1}')
# ls /etc/sudoers.d/$(who am i | awk '{print $1}')
 -r--r----- 1 root root 27 May 28 20:21 /etc/sudoers.d/<your username>

So with that out of the way we can now get and install required libraries.

$ echo "
build-essential
libusb-1.0-0-dev
libusb-dev
libncurses5-dev
libfftw3-dev
libbsd-dev
libhackrf-dev
libopus-dev
libairspy-dev
libairspyhf-dev
librtlsdr-dev
libiniparser-dev
libavahi-client-dev
portaudio19-dev
libopus-dev" > /tmp/required

$ for _required in $(cat /tmp/required); do sudo apt install $_required -y; done

If you like to run the system for a while it helps if the stupid hibernation is switched off.

 $ sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target

I find it much easier to work with names rather then with ip-addresses and port-numbers, as such I'd use the Multicast DNS function of the AVAHI Daemon. Your mileage may vary though! 

$ sudo systemctl start avahi-daemon.service
$ sudo systemctl status avahi-daemon.service
 avahi-daemon.service - Avahi mDNS/DNS-SD Stack
     Loaded: loaded (/lib/systemd/system/avahi-daemon.service; enabled; vendor preset: enabled)
     Active: active (running) since Sun 2023-06-11 22:16:53 ACST; 3 days ago
TriggeredBy: ● avahi-daemon.socket
   Main PID: 548 (avahi-daemon)
     Status: "avahi-daemon 0.8 starting up."
      Tasks: 2 (limit: 9342)
     Memory: 1.3M
        CPU: 15.899s
     CGroup: /system.slice/avahi-daemon.service
             ├─548 avahi-daemon: running [sun.local]
             └─566 avahi-daemon: chroot helper

Not needed in the use case.

Check if en_US.UTF-8 language is installed.
First check:
$ locale -a
C
C.UTF-8
en_AU.utf8
POSIX

And if it is missing, run:
$ sudo dpkg-reconfigure locales

This will bring up a graphical-ui (ncurses) selection display. Scroll down until you see en_US_UTF-8, press spacebar to select and then <ok>

Generating locales (this might take a while...)
  en_AU.UTF-8... done
  en_US.UTF-8... done
Generation complete. 
 
$ locale -a
C
C.UTF-8
en_AU.utf8
en_US.utf8 <-- required
POSIX

Now download the source files for the KA9Q radio suit:
$ mkdir tmp
$ cd tmp
wget https://github.com/ka9q/ka9q-radio/archive/refs/heads/main.zip

Extract the downloaded file (main.zip):
$ unzip main.zip
$ ls -l
total 2.4M
drwxr-xr-x 4 hw hw 4.0K May 28 16:15 ka9q-radio-main
-rw-r--r-- 1 hw hw 2.4M May 28 18:16 main.zip

Compile and install KA9Q-Radio applications:
$ export LANG=en_US.UTF-8
$ cd ka9q-radio-main

NOTE: There are two (2) Makefiles, Makefile.linux and Makefile.pi. If you use a RaPi you need to link Makefile.pi to Makefile 

$ ln -s Makefile.linux Makefile 
$ sudo make install

Next we create a "wisdom" file. 

NOTE: Depending on your system this can take a while. Creating a wisdom file on a RaPi took a while. I cooked a meal, ate the meal, check the RaPi .... not yet .... went and watch a movie ... check again and voila done! So be patience grasshopper.

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

Or if you are keen and like to know how long it took to create your wisdom file you could run the below.

$ time fftwf-wisdom -v -T 1 -o /tmp/wisdom rof500000 cof36480 cob1920 cob1200 cob960 cob800 cob600 cob480 cob320 cob300 cob200 cob160
fftw-wisdom: system-wisdom import failed
Planning transform: cob160
Planning transform: cob200
Planning transform: cob300
Planning transform: cob320
Planning transform: cob480
Planning transform: cob600
Planning transform: cob800
Planning transform: cob960
Planning transform: cob1200
Planning transform: cob1920
Planning transform: cof36480
Planning transform: rof500000

real    4m14.131s
user    4m8.088s
sys     0m0.048s

Move the generated wisdom file in to its rightful place.
$ test -s /var/lib/ka9q-radio/wisdom && sudo mv /var/lib/ka9q-radio/wisdom /var/lib/ka9q-radio/wisdom.old
$ sudo mv /tmp/wisdom /var/lib/ka9q-radio/wisdom
$ sudo chown $(who am i | awk '{print $1}').radio /var/lib/ka9q-radio/wisdom

Now its time to install the K1JT's WSPR Application.
$ sudo apt install wsjtx -y

After that is finished it's time ....  to configure/setup KA9Q-Radio for our intended purpose.

There are lots of config files and to work through all off them you'll want/need to read the documentation from here however, since I'm going to use the RX888 to do WSPR only as such I've created a new rx888.conf config file. The # and ; a comment markers. You can either modify this file with a text editor like vi or nano.

Before you copy and paste the next configuration item (below, you need to establish what the active network interface is being named! In the rx888.conf file we has a statement starting with iface. This value is system dependent and you need to find that name before you can progress any further.

On a RaPi it is most likely eth0, but on other systems it could be something else. E.g. on my system it is eno1
You'll be able to check using the following:
ip a | grep "mtu 1500" | grep UP | awk '{print $2}'
eno1: <- This is what the NIC is called on my system

Whatever the above command output shows, you'll might need to change the iface value in the below script. E.g. if it shows eth0 your iface line should read iface = eth0.

The below will create a backup of the /etc/radio/rx888d.conf file first, before creating a new /etc/radio/rx888d.conf file. 

$ sudo mv /etc/radio/rx888d.conf /etc/radio/rx888d.conf.bck
$ sudo cat << __EOF__ > /etc/radio/rx888d.conf
[rx888-loop]
# VK5HW customized
description = "RX888 40m Delta-Loop"
firmware = SDDC_FX3.img
samprate = 64800000    ;  2^8 * 3^4 * 5^5
iface = eth0               ; replace this with your iface name
status = rx888-status.local
data = rx888-pcm.local
ssrc = 10
;gain = 1.5 ; dB
gain = 10 ;dB - close to the Noise Floor, might have to increase
gainmode = high ; higher gain range
__EOF__

Next we need to configure the virtual receivers. These we do with the radiod@wspr.conf file. 
$ sudo mv /etc/radio/radiod@wspr.conf /etc/radio/radiod@wspr.conf.old
$ sudo cat << __EOF__ > /etc/radio/radiod@wspr.conf
[global]
overlap = 5
blocktime = 20
input = rx888-status.local
samprate = 12000
mode = usb
status = hf.local
fft-threads = 2

[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"
__EOF__

That's it folks, we are ready to start KA9Q-Radio! Make sure the RX888 is plug into the correct USB Port and then to be sure to be sure REBOOT the system.
$ sudo reboot

After the reboot, login to the system and start the rx888d(river) using the rx888-loop configuration.
/usr/local/sbin/rx888d rx888-loop &

NOTE: The & indicates that we would like the program (job) to run in the background.

If everything is OK the following output can be seen:
$ Using config file /etc/radio/rx888d.conf
Loading firmware file /usr/local/share/ka9q-radio//SDDC_FX3.img
Firmware already loaded
USB speed: 4
Successfully claimed interface
Samprate 64,800,000, Gain 10.0 dB, Attenuation 0.0 dB, Dithering 0, Randomizer 0, USB Queue depth 16, USB Request size 8 * pktsize 16384 = 131,072 bytes
service 'RX888 40m Delta-Loop._ka9q-ctl._udp' -> rx888-status.local (239.132.105.12) established
service 'RX888 40m Delta-Loop._rtp._udp' -> rx888-pcm.local (239.10.102.92) established
RX888 40m Delta-Loop: iface eno1; status -> 239.132.105.12:5006, data -> 239.10.102.92:5004 (TTL 0, TOS 48, 24576 samples/packet)

If this all looks ok the PC is talking to the SDR and it is time to start the demodulators.
$ /usr/local/sbin/radiod /etc/radio/radiod@wspr.conf &
$ KA9Q Multichannel SDR
Copyright 2018-2022 by Phil Karn, KA9Q; may be used under the terms of the GNU General Public License
Loading config file /etc/radio/radiod@wspr.conf...
Acquired front end control stream rx888-status.local (239.132.105.12)
Acquired front end data stream 239.10.102.92:5004 (239.10.102.92)
Front end sample rate 64,800,000 Hz, real; block time 20.0 ms, 50.0 Hz
fftwf_import_system_wisdom() failed
fftwf_import_wisdom_from_filename(/var/lib/ka9q-radio/wisdom) succeeded
service 'wspr._ka9q-ctl._udp' -> hf.local (239.83.95.156) established
Processing [wspr]
service 'wspr._rtp._udp' -> wspr-pcm.local (239.72.24.12) established
12 demodulators started
12 total demodulators started

Next start start the wspr-decoder:
$ wspr-decoded wspr-pcm.local

And voila we are starting to see decodes:
$ <DecodeFinished>
<DecodeFinished>
<DecodeFinished>
<DecodeFinished>
<DecodeFinished>
<DecodeFinished>
1518 -19  0.7   0.475683  0  VK6LX OF88 30
<DecodeFinished>
<DecodeFinished>
<DecodeFinished>
1518 -17  0.3   7.040113  0  RU0LL PN53 33
<DecodeFinished>
1518 -27  0.4  14.096975  0  WS5L EM13 37
1518 -12  0.2  14.096984  0  WB7AJP CN87 33
1518 -23  0.3  14.097017  0  <KR6RG> DM13EM 23
<DecodeFinished>
<DecodeFinished>

Looking at our home directory we can see that we have a few new directories. These are the directories of the individual virtual receivers where all the WSPR files go.
$ ls -l
total 104K
drwxr-xr-x 2 hw hw 4.0K May 29 00:54 10138700
drwxr-xr-x 2 hw hw 4.0K May 29 00:54 136000
drwxr-xr-x 2 hw hw 4.0K May 29 00:54 14095600
drwxr-xr-x 2 hw hw 4.0K May 29 00:54 18104600
drwxr-xr-x 2 hw hw 4.0K May 29 00:54 1836600
drwxr-xr-x 2 hw hw 4.0K May 29 00:54 21094600
drwxr-xr-x 2 hw hw 4.0K May 29 00:54 24924600
drwxr-xr-x 2 hw hw 4.0K May 29 00:54 28124600
drwxr-xr-x 2 hw hw 4.0K May 29 00:54 3568600
drwxr-xr-x 2 hw hw 4.0K May 29 00:54 474200
drwxr-xr-x 2 hw hw 4.0K May 29 00:54 5287200
drwxr-xr-x 2 hw hw 4.0K May 29 00:54 7038600

Lets have a look what's inside these directories:
$ ls -l 5287200
total 8.7M
-rwxr-xr-x 1 hw hw 2.1M May 28 00:01 230527_1430.wav
-rwxr-xr-x 1 hw hw 1.9M May 28 01:17 230527_1546.wav
-rwxr-xr-x 1 hw hw 1.4M May 28 09:05 230527_2334.wav
-rwxr-xr-x 1 hw hw 2.6M May 29 00:47 230528_1516.wav
-rwxr-xr-x 1 hw hw 2.1M May 29 00:57 230528_1526.wav
-rw-r--r-- 1 hw hw    0 May 28 00:33 ALL_WSPR.TXT
-rw-r--r-- 1 hw hw    0 May 29 00:55 hashtable.txt
-rw-r--r-- 1 hw hw    0 May 29 00:55 wspr_spots.txt
-rw-r--r-- 1 hw hw  452 May 29 00:55 wspr_timer.out
-rw-r--r-- 1 hw hw 2.0K May 29 00:55 wspr_wisdom.dat
$ ls -l 14095600
total 8.8M
-rwxr-xr-x 1 hw hw 2.1M May 28 00:01 230527_1430.wav
-rwxr-xr-x 1 hw hw 1.9M May 28 01:17 230527_1546.wav
-rwxr-xr-x 1 hw hw 1.4M May 28 09:05 230527_2334.wav
-rwxr-xr-x 1 hw hw 2.6M May 29 00:47 230528_1516.wav
-rwxr-xr-x 1 hw hw 2.1M May 29 00:59 230528_1528.wav
-rw-r--r-- 1 hw hw  36K May 28 23:34 all_wspr.bck
-rw-r--r-- 1 hw hw 3.0K May 29 00:57 ALL_WSPR.TXT
-rw-r--r-- 1 hw hw 3.6K May 29 00:57 hashtable.txt
-rw-r--r-- 1 hw hw  45K May 28 23:34 upload.log
-rw-r--r-- 1 hw hw   74 May 29 00:57 wspr_spots.txt
-rw-r--r-- 1 hw hw  452 May 29 00:57 wspr_timer.out
-rw-r--r-- 1 hw hw 2.0K May 29 00:57 wspr_wisdom.dat

In the 14095600 directory we find two additional files, all_wspr.bck and upload.log. These are files that my upload script is producing. The .bck file is an archive of ALL_WSPR.TXT and the .log file is for error checking.

And here is a snapshot view of a decoded dataset:

$ cat 14095600/ALL_WSPR.TXT
230528 1508 -18 -0.91  14.0969794  DP0POL JQ26 37          0  0.12  3  1    0  0  34    33  -120
230528 1508 -15  0.19  14.0969838  WB7AJP CN87 33          1  0.28  1  1    0  0  39    20    16

As it stands you now have a MULTI BAND WSPR DECODING SYSTEM

And now to upload the results to WSPRNet, that is also quite easy. It is  done with a one-liner:

$ curl -F allmept=@ALL_WSPR.TXT  -F call=<your call>  -F grid=<your grid>  http://wsprnet.org/meptspots.php

There is a very similar site, PSKREPORTER which not only has a database for WSPR but for a lot of other digital modes. However, I've not (yet) found a way how to upload my results to that repository.

I have automated this on my system using the *nix cron facility. I first created a script to archive the reports and create a log file for error checking. If you like to use the script, it can be found here

And here is my crontab: (copy the below to your crontab)
1,7,13,19,25,31,37,43,49,55 * * * * ~/scripts/upload_wspr_data.sh VK5HW PF94hk

It basically runs every 6 minutes, a minute after or before a WSPR decode.

Oh, and if you like to see if I received you go to WSPR rocks, which is an excellent tool for mapping, charting and other visualisation. 

So that's basically it. 
PLEASE NOTE, that this is NOT a how to use KA9Q-Radio, rather a quick way to show how easy it is to setup a multiple frequency WSPR receiving system using parts of the KA9Q-Radio suite. 
There are other modes that can be setup and monitored,  if you like to use other modes or even would like to manually tune through the bands and listen you'd need either a sound card or understand how to use "MULTICAST" streaming. The options are not quite endless but ...

Next on the list, get some horizontal antenna for a 2m/70cm/23cm installed and setup a WSPR VHF/UHF receive system. 

Oh and a little bragging ...





Appendix: