VK5HW AR musings

Thursday, March 20, 2025

SNLR, a better way to give a signal report

Or why a 59 report is really meaningless!

A NOTE first: I've labeled this SNLR (Signal to Noise-Level Ratio) so as not to step on our purists feet. We could just call it SNR as it really a basic form, in an Amateur Way, of Signal to Noise Ratio.

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 (SNLR), 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 SNLR 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.

The Importance of SNLR

SNLR (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 SNLR means that the signal is much stronger than the noise, making it easier to decode and work with. On the other hand, a low SNLR 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 SNLR 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 (NL) of 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 (for instance, S4 as in my case).

Next we tune to a channel with a transmission and from the below we can see I've tune to a station which has an S9+10 average signal level.

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)

click to view larger file

So, to calculate the SNLR:

Convert both the received signal strength and the noise level into power levels (dBm).
Calculate the difference between the received signal and the noise level (e.g., SNLR = 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:

SNLRdB = (Signal-LeveldBm) - (Noise-LeveldBm)

SNLR = (-63) - (-103)

SNLR = 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 S6 (-91 dBm), the SNLR would only be 18 dB.

While still a reasonable SNLR, 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 SNLR instead of S-Meter Values

More Accurate Representation of Signal Quality:

SNLR 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 SNLR, 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 an 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, a power level increase of 6dB should in principal add 6dB to the SNLR. Remember bigger SNLR = better signal quality.

Challenges

SNLR requires additional measurements:

To report SNLR, 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 SNLR are still subjective:

While SNLR 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 or SNLR doesn't provide the full picture. Shifting to SNLR 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 SNLR 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 SNLR could additionally be displayed.

Appendix

SNLR Calc

HSP = Human Signal Processor (normally found between the ears)

Tuesday, January 21, 2025

How to log FT8 and WSPR to a system log on the WEB-888

The new Version (v2025.0119) has the ability to write to the system log (Thanks Howard).

NOTE: Depending on the storage size of the used SD-Card, the log file could fill up all usable space. This could impact on system performance and might lead to a stale system.

To enable FT*/WSPR logging to the system go to the Admin interface (http://<your web-888 IP-address>:8073/admin) and select the Extensions Tab.

Select either WSPR or FT8 (left grey area),
Then set the “Log decodes to syslog” [Yes|No] field to Yes.

As soon as this has been set to yes the system will log to the system log (/var/log/messages).

To check, we can either use the Web-console (Admin interface) or ssh to the web-888 via our favoured ssh-client (I use MobaXterm).

To check if the data is written to the log file.

web-888:~# grep "user.info" /var/log/messages

Jan 21 08:23:31 web-888 user.info : 00:56:31.207 0123456789AB 8 FT8 DECODE: 10137.728 DK9FE JO40 -10 15695km Tue Jan 21 08:23:15 2025
Jan 21 08:23:31 web-888 user.info : 00:56:31.312 0123456789AB 8 FT8 DECODE: 10137.984 IW1CKR JN45 -13 15692km Tue Jan 21 08:23:15 2025
Jan 21 08:23:32 web-888 user.info : 00:56:31.780 0123456789AB 6 FT8 DECODE: 18100.725 JE2GEG PM85 -8 7904km Tue Jan 21 08:23:15 2025
Jan 21 08:23:34 web-888 user.info : 00:56:33.975 0123456789AB 7 FT8 DECODE: 14075.550 BD4VOJ PM01 -11 7681km Tue Jan 21 08:23:15 2025
Jan 21 08:23:46 web-888 user.info : 00:56:46.075 0123456789AB 5 FT8 DECODE: 21075.144 JK4WKO PM54 -6 7831km Tue Jan 21 08:23:30 2025
Jan 21 08:23:46 web-888 user.info : 00:56:46.079 0123456789AB 5 FT8 DECODE: 21075.638 JI1ILB PM96 -10 8014km Tue Jan 21 08:23:30 2025
Jan 21 08:23:59 web-888 user.info : 00:56:59.277 0123456789AB 1 WSPR DECODE: 0822 4 0.2 14.097102 0 VK4TMT QG62 1629 23 (200 mW)
Jan 21 08:23:59 web-888 user.info : 00:56:59.396 0123456789AB 1 WSPR DECODE: 0822 3 0.2 14.097134 0 VK4NE QG62 1629 23 (200 mW)
Jan 21 08:23:59 web-888 user.info : 00:56:59.599 0123456789AB 1 WSPR DECODE: 0822 -14 0.2 14.097073 0 MW0KST IO81 16507 37 (5.0 W)
Jan 21 08:24:00 web-888 user.info : 00:56:59.753 0123456789AB 1 WSPR DECODE: 0822 -15 0.2 14.097018 0 G8MCD IO91 16373 23 (200 mW)

Since we are now writing to the log file constantly it is best to make sure that the log file is being kept at a manageable size. To do so we set up syslogd to roll the log file every so often. For demonstration I’ve setup the syslog configuration file to roll after it reaches 100 kB in size. This size depends on your environment and size of the SD-Card. This is a requirement for your system and as such the roll over size needs to be determined accordingly.

There are approximately 150 Bytes per line so that should help compute your daily log growth. If the system writes 10 messages per second at an average of 150 Bytes we get about 13 MB a day.

On my system I have set the log size to 10 MB (10240). This however, can be tailored to individual requirements with up to 99 log files (-b 99) YMMV!

To set this up follow these steps:

ssh to the web-888
and change into the config directory

cd /etc/conf.d

create a backup of the original syslog configuration file

cp syslog syslog.orig

create a new config file based on log size requirements (-s x) and how many logs we like to keep before overwriting the first (/var/log/messages.0) file (-b z). In the below example I use 100 kB size and rotate up to 7 logs.

echo "SYSLOGD_OPTS=\"-s 100 -b 7\"" > syslog

check if we got it right

cat syslog

SYSLOGD_OPTS="-s 100 -b 7"

restart syslog

rc-service syslog restart

and check if we are logging to the log file

grep "user.info" /var/log/messages

And as we can see from the below, the log file rolls over at 100 kB.

web-888:~# ls -l /var/log/messages*

-rw-r----- 1 root wheel 41316 Jan 21 12:02 /var/log/messages

-rw-r----- 1 root wheel 102543 Jan 21 11:51 /var/log/messages.0

-rw-r----- 1 root wheel 102542 Jan 21 11:10 /var/log/messages.1

If you like to see a constant flow of messages use the following command. However, do not use this command in the WEB-Console window. [CTRL]+C doesn’t seem to work and as such the console becomes unusable and you need to restart the web server.

web-888:~# tail -f /var/log/messages

The following commands can be used to extract data from the log for further processing:

web-888:~# grep "user.info" /var/log/messages > /dev/shm/user.info

web-888:~# grep "FT8 DECODE" /var/log/messages | sed -e 's/.*FT8 DECODE: \(.*\)2025.*/\1/' > /dev/shm/ft8

web-888:~# grep "FT4 DECODE" /var/log/messages | sed -e 's/.*FT4 DECODE: \(.*\)2025.*/\1/' > /dev/shm/ft4

web-888:~# grep "WSPR DECODE" /var/log/messages | grep -v " WSPR DECODE: UTC" | sed -e 's/.*WSPR DECODE: \(.*\))*/\1/' > /dev/shm/WSPR

These commands will write all WSPR/FT8/4 messages into shared memory, from which we can now copy the data to other systems for further processing.

NOTE: The system log files WILL be removed when a system reboot is being initiated, that includes a power failure! You will need to make sure to backup your data!

UPDATE: 20250226

To make the changes stick, i.e. survive a reboot etc. we need to commit the changes to the boot config file. See the Alpine Wiki for more info.

The lbu command allows us to make changes to the boot configuration.

Check the status:

web-888:~# lbu st
U etc/conf.d/syslog
web-888:~# ls -l /media/mmcblk0p1/web-888.apkovl.tar.gz
-rwxr-xr-x 1 root root 13527 Feb 26 15:04 /media/mmcblk0p1/web-888.apkovl.tar.gz

Commit the change

lbu ci

Check to see if the backup worked

web-888:~# ls -l /media/mmcblk0p1/web-888.apkovl.tar.gz
-rwxr-xr-x 1 root root 13529 Feb 26 15:08 /media/mmcblk0p1/web-888.apkovl.tar.gz

Reboot the system:

web-888:~# sync;reboot

After the reboot check that your syslog configuration is as expected.

web-888:~# cat /etc/conf.d/syslog
SYSLOGD_OPTS="-s 100 -b 7"

Friday, September 13, 2024

A model of my 40m Delta Loop

At my QTH it is rather difficult to have dipoles strung up at a decent height. As I have had quite good success with horizontal loops (see my old Lazy-D) I decided to install a slopping Delta Loop at this QTH. From what I can tell the antenna is working quite nicely and I am able to make the radio happy with the internal tuner on the following bands, 40, 20,17,15,12,10 and 6m. Now it is not a WONDER antenna however, it does the job for me (YMMV).

Installation details:

Feed point is 14m above ground (1.5m hockey stick above roof).
The end corners are about 5m above the ground.
Feedline, the first 3m are a commercial Ladderline (labeled 450Ω but it might be closer to 390/400Ω), then 20m of LMR-400, 3m of RG213 and 0.8m of RG8 from the ATU.
The antenna is strung to face towards the East, at approx 110°.

As I also use this antenna as a RX-antenna for ELF/VLF I have removed the BALUN and only use a few chokes on the coax-feedline. Below is a drawing of the antenna.

40m radiation pattern:

As we can see, nothing really to talk about it. Pretty good for NVIS and with a bit of luck, e.g. very good to excellent propagation I might work a little bit of DX.

20m radiation pattern:

On 20m we can see two lobes. One to the East with a nice bit of low angle gain into the East which would help to work short path into the Americas and long path into Europe. However, the high angle lobe seems to be also quite good.

17m radiation pattern:

Even though the VSWR on 17m is not that great, the inbuilt Auto Transmatch (ATM) manages to get the SWR down enough for the Radio and Amplifier to be happy. Losses due to SWR are low enough and don't cause any issue. Looking at the pattern we can see that we have very similar coverage as for 20m. And, as it is for 20m, there is still a high angle lobe.

15m radiation pattern:

Now on 15m we can see that the high angle lobe has disappeared and that there are quite a few usable lobes. There are East and West lobes, with the East lobe quite low and strong, but also quite narrow. Additionally the North and South ones are quite broad with a nice bit of gain.

12m radiation pattern:

As for 17m, the VSWR on 12m is not that great. However, the ATM is able to keep the Radio or Amplifier happy. SWR losses are nothing to worry about. The radiation pattern is very similar to the 15m pattern with noticeable nulls in the North and South lobes. Again, lots of good gain into the East and reasonable gain into the other hemispheres.

10m radiation pattern:

Unfortunately on 10m the pattern starts to create lots of lobes with good low angle gain lobes into the East and West. However, the coverage for North and South is not that great. Lobes are high and not much gain in them.

6m radiation pattern:

Well 6m, what can I say. We can see quite a lot of narrow lobes albeit with good gain.

And yes, I can use the antenna on 6m and have made contacts into Western Australia (VK6), Northern Territory (VK8), Queensland (VK4), New South Wales (VK2) and Japan (JA) however, they have been far and few.

The antenna has been modeled with real ground (poor) to give me an indication of what I can expect at my QTH. However, it is not a true indication of the actual radiation pattern, there is a House behind the antenna (to the west) which will change the characteristics of the antenna performance especially into the westerly direction.

As with every antenna the impedance (Z) changes with height, soil conductivity and of course surroundings. This will dictate what type of Feedline and or BALUN one would/should/could use, there is no silver bullet. I do use an Antenna Analyser (VNA) to learn what the actual Antenna System (Antenna + Feedline) Z at my installation is, e.g. what my ATM would be presented with. This does help me to use what feedline and/or BALUN etc. I would use to configure the antenna-system to my requirements e.g. adjusting the antenna at a frequency of 7.2MHz to create easier matchable impedances for the additional Bands/Frequencies I would like to operate on.

According to my previous model of a Delta Loop used as a Horizontal Loop (LAZY-D) the Z was approx. 100 +j10Ω at resonance, which would mean that a 2:1 BALUN would be the right choice to get a good 50Ω match.

Compared against the previous installation, this model tells me that I could except the Z to be > 200Ω which would indicate that a 4:1 BALUN would be needed to get a good 50Ω match.

If you'd like a bit more information on Delta Loop antennas, a good educational read is the work of W4RNL (SK). His notes on Delta Loops can be found here.

So to wrap it up, the block does not lend itself for the installation of a multiband dipole type of antenna (G5RV or ZS6BKW) so the next best thing for me was to grab something out of my box of tricks and go back to an old, but proven concept.

I didn't really wanted to add an VSWR prediction chart but due to multiple requests, here is a quick SWR plot of the modeled antenna:

Here are some SWR plots whilst I was still using a 1:1 BALUN. And a view of how the antenna performs can be found here.

Tuesday, July 30, 2024

Excessive Single Side Band Transmission, also know as ESSB or eSSB.

There seems to be an increase in the transmit bandwidth range for SSB communications, which traditionally operates within a narrow-band of approximately 3 kHz. Now if we go with a 3 khz “Voice channel” for Single Side Band (SSB) then the Transmitted Bandwidth, let's call it the TxBW, should fit into the range 0-3000 kHz.

However, I’ve noticed more and more operators use a TxBW of 4 kHz or more. This is often referred to as Extended Single Side Band (ESSB) which I have seen to extend in some instances even to 5 kHz and more. The claim to fame is HiFi Audio.

Now Amateur Radio is an experimental hobby, so this, on the surface, shouldn’t irk anyone, shouldn’t it? However, I frequently encounter ESSB operators on 20 and 40m talking to operators who have not modified their station for ESSB communications, i.e. a station with a TxBW 5 kHz to a station with a 3 kHz Receiver Bandwidth, lets call that RxBW.

So what seems to be the issue?

Let's say a QSO is conducted on 14.229 MHz, one operator uses a TxBW of 2.9 khz and the other uses a TxBW of 2.4 kHz. Signal are good with about S7 both ways. Since this is conducted using the Upper Side Band and, if we apply a Voice Channel spectrum of 3 kHz the used frequency spectrum for that QSO is from 14.229 – 14.231 MHz (not quite but let's stick with 3 kHz). Stations operating on 14.232 MHz should not have any issues operating. However, let's assume one of the operators is operating at a TxBW of 5 kHz. This situation would infringe stations operating on 14.232 MHz quite badly. Another example would be if a DX station is calling on 14.232 MHz and I would like to work that station. However, I will be unable to do so due to the excessive TxBW of the ESSB operator (14.229 - 14.234 MHz).

Anyone see an issue here? Well, I do! However, the question is does the ESSB operator see the issue? From my experience most ESSB operators do not.

So why use 5 kHz TxBW whilst conducting DX contacts. Aren't we trying to share the limited frequency spectrum between all Amateurs? There is certainly NO benefit to the station receiving the ESSB station.

Frequency spectrum during “openings” are crowded and transmitting with a 5 kHz TxBW during these opening does not show any courteousey towards other spectrum users.

The above shows an Australian Operators transmission with a TxBW of 5 kHz and the DX station using a less than 3 kHz “Voice Channel”. I will assume that the DX stations RxBW would not be more than it's TxBW.

NOTE: I’m referring to the TxBW and not the Intermodulation Products (IM) or “splatter”, e.g. the light blue “hair or whiskers” on either side of the signal, which are obvious related but are not discussed here.

This is even more frustrating on the 40m Band, as there are more an more local stations operating with a TxBW of greater than 4 kHz.

Now Amateur Radio is an experimental hobby and experimenting with a TxBW > 3 kHz does fall under this category. So, yes I believe in experimenting but this is not experimenting, this is not understanding the implication of excessive TxBW. And believe me I’m all for experimenting. However, I am quite happy with a 2.4 kHz well balanced audio TxBW which would influence the use of an appropriate RxBW.

Additionally I believe that these operator would not know how much "real" power they are transmitting. If we talk about 400W PEP, then the average output power would be rather LOW.

NOTE: I also observed that these type of operators seem to drop their TxBW to 3 kHz during Contests!?! Yet they seem to believe that during crowded DX sessions it is OK to use 5 kHz or more TxBW. Isn't that a bit hypocritical?

Since Amateur Radio is a self regulating hobby it might be about time to add a frequency spectrum for those inclined to use ESSB. I believe this has been done for certain other modulation schemes (AM/FM/DIGITAL).

Saturday, July 13, 2024

ICOM IC-7610 S-Meter Tracking

Having been checking the S-Meter for my prefered software solutions (SDR) I thought it might be a good time to also (re)check the S-Meter in my ICOM IC-7610. The setup is the same as for the previous two checks. Below is the result of my checks for my IC-7610. A quick graph of how well my ICOM IC-7610 S-Meter is tracking using the IARU Standard of 6dB steps (6dB/S-Unit).

Setup:

Signal generator: XG3
Level: -34.8dBm @ 13.8V
Att: HP-355C & HP-355D (38dB for approx. -73dBm level)
Frequency: 14.175MHz

Result:

Table 1

Graph 1

The graph shows a pretty linear S-Meter for the IC-7610 down to S4 with a 6dB step per S-unit. The above graph is based on the measurements at 14.175 MHz (20m) with the PreAmp off. However, enabling either preamp we can see from Table 1 that the measurements deviate quite a bit. So for the times that I'd use either of the preamps I need to do a bit mental arithmetic. My measurements show a 6dB increase for PreAmp 1 and a 10dB for PreAmp 2. But please note, even though the data in Table 1 looks spot on, the measured values are rounded up or down to the nearest integer. However, we are talking about an Amateur device not a professional Field Strength Meter. So I'm quite happy with the result.

Here are some older 40m graphs.

Graph 2

Graph 3

Graph 4

Below is my cheatsheet for S-Unit vs dBm vs µV.

Graph 4

CLICK on a graph for a better view.

NOTE: Even though the above graph is displayed with 3dB steps, it is 6dB per S-Unit!

Adjusting the S-Meter for HDSDR

Since ICOM has released Firmware v.1.42 for the IC-7610 the I&Q port is working again. This opened up the possibility to use HDSDR (Sampling rate of 1.92MHz with an effective Bandwidth of 1.66MHz) again. Since I still had the S-Meter check setup "set up" from the "Adjusting the S-Meter in Thetis" I decided to check and adjust, if need be, the HDSDR/IC-7610 combo.

The setup is basically the same as for Thetis, except the SDR in this case is an IC-7610.