Friday, October 3, 2025

How to download WSPR and FT8 logs from a WEB-888 SDR

Since firmware version v2025.0119 the Web888 is able to log FT8/4 and WSPR decode information to the messages file of the OS. Because a reboot or a simulated reboot, i.e. a power failure will remove any log file from the Web888, I use the following to store the log onto a different host. Additionally I'm also able to further process the log, but that's a different story.
I use a Raspberry Pi (RaPi) as my storage system however, any *nix type system, including the "Fruity MAC" or the "Shattered Windows" (with the *nix add on) could be used by following the below steps. 

Note: Many ways lead to Rome as they say, and this is only one of the many ways this can be achieved, YMMV!

Prerequisite:

  • A little knowhow of how to abuse a keyboard.
  • A little knowledge about some form of *nix (MAC-OS, Linux, etc.).
  • A Terminal program (Putty, MobaXterm, xterm).
  • POSIX *nix commands.
  • ssh
  • ssh-keygen
  • the IP-Address of your Web888.

The step we will take to create the system,
    1. Create Password less access.
    2. create a key
    3. copy key to Web888
    4. modify Web888 boot image
    5. create file store
    6. test system
    7. automate system
Note: I will use the following syntax throughout to help distinguish between commands and command echos.

This is a command you type at (into) the terminal, you can also copy and paste.

And the below is a command echo,

Ok, well done grasshopper.

Create Key

Let's log in to our *nix system with our prefered Terminal application.
Since we are connecting to the Web888 via ssh will will create a set of ssh-keys to enables us to do so.The ssh-keygen application is the tool for us to set this up.

/usr/bin/ssh-keygen -t rsa -b 4096 -C "VK5HW"

Let me quickly explain, the -t specifies what type of key to create, the -b means how big/long the key should be and the -C is a comment field. You can use the comment to add your own callsign or any other comment you wish to the key.
After you pressed the [ENTER] key, you will be greeted with the following text:
Generating public/private rsa key pair.
(Patience is a virtue) you need to wait a little before you'll see  
Enter file in which to save the key (/home/hw/.ssh/id_rsa):
We will accept the default (/home/hw/.ssh/id_rsa) and press the [ENTER] key.
Now the next is the secret ingredient for password less access.
Enter passphrase (empty for no passphrase):
Yep, you guessed it, we hit [ENTER] as we do not want a passphrase (password)! And so the next question is answered exactly the same!
Enter same passphrase again:
Hit that [ENTER] key again.
Your identification has been saved in /home/hw/.ssh/id_rsa
Your public key has been saved in /home/hw/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:some blah here VK5HW
The key's randomart image is:
+---[RSA 4096]----+
| some blah here  |
+----[SHA256]-----+

Let's quickly check,
ls  ~/.ssh/*rsa*
/home/hw/.ssh/id_rsa  /home/hw/.ssh/id_rsa.pub

Two files have been created and we need to install the id_rsa.pub, which is our public key, onto the Web888.

Copy the Key to the Web888

Were are still in our Terminal session and the next task is to set a shell variable with the IP-Address of your Web888's.
ipa=<your Web888's IP-Address>

Note: We will use this shell variable throughout the setup!

Next is a rather long command, which is actually multiple commands strung together which will handle all the required tasks e.g., setup, copy and to set the appropriate file permissions in one swoop.
cat ~/.ssh/id_rsa.pub | ssh root@$ipa "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Note: Make sure the shell variable ipa has been set!

You'll be greeted with this prompt:
root@<your Web888's IP-Address>'s password:
Because it asked so nicely you should give it the password (changeme), hit [ENTER] and the message Connection closed by <your Web888's IP-Address> port 22 will be displayed on the screen. That's it, no more passwords.

Let's check:
ssh root@$ipa "ls  ~/.ssh"
authorized_keys

With that out of the way let's make sure that our modification of the Web888 firmware survives a reboot.

Modify the Web888 Boot Image File

From our Terminal program ssh to the Web888,
ssh root@$ipa
Welcome to Alpine!

The Alpine Wiki contains a large amount of how-to guides and general
information about administrating Alpine systems.
See <https://wiki.alpinelinux.org/>.

You can setup the system with the command: setup-alpine

You may change this message by editing /etc/motd.

Noticed that the Web888 did not ask for a pesky password!

Let's note the Boot Image File size,
ls -l /media/mmcblk0p1/web-888.apkovl.tar.gz
-rwxr-xr-x    1 root     root         13718 Sep 30 00:22 /media/mmcblk0p1/web-888.apkovl.tar.gz

And then check the status of the boot image file,
lbu st
A root/.ssh
A root/.ssh/authorized_keys

As we can see the two files which we created, .ssh and .ssh/authorized_keys have not been added to the boot image file. To add them we commit those files using the command,
lbu ci
And lets check if the commit has worked,
lbu st

And ... nope nada. We get nothing back from the status command if all went well. And to make sure that the boot image file has really been modified we check,
ls -l /media/mmcblk0p1/web-888.apkovl.tar.gz
-rwxr-xr-x    1 root     root         14402 Oct  3 14:53 /media/mmcblk0p1/web-888.apkovl.tar.gz

and see that the timestamp and the files size have changed!

Our job here is done so logout of the Web888,
exit
Connection to <your web888's IP-Address> closed.

It is now time for a cold drink (Beer?). Hard part is done.

Create File Store

Note: Make sure that you are at your local host.

Next we create the file store which is really only a directory at a place near you, you can call it whatever you want, I will call it web888.
mkdir -p ~/web888 

Done!

Test the System

Well, to test the system we will download a message file. I have created a script which will make the download a bit easier. But for demonstration and for testing I show you the individual commands.
  1. Create a copy of the messages file 
  2. Zero/empty /var/log/messages 
  3. Download the log file
  1. ssh root@$ipa 'cp /var/log/messages /var/log/log'
  2. ssh root@$ipa 'cat /dev/null > /var/log/messages'
  3. ssh root@$ipa 'cat /var/log/log' | grep "user\.info" > ~/web888/log_$(date +%Y%m%d"_"%H%M).txt
And we check,
ls ~/web888/log_20251004_0048.txt
/home/hw/web888/log_20251004_0048.txt

and check if our downloaded file has actual data in it,
cat ~/web888/log_20251004_0048.txt | more
Oct  2 13:48:00 web-888 user.info : 00:03:45.107 ..23456789A.     4        WSPR DECODE:  UTC  dB   dT      Freq
 dF  Call   Grid    km  dBm
Oct  2 13:48:00 web-888 user.info : 00:03:45.124 ..23456789A.     4        WSPR DECODE: 1346 -13  0.1 10.140111
 -1  VK7TW  QE37  1057   30 (1.0 W)

Looking good.
The download script can be found here.

And that is it! You should now be able to download the messages (log file) from your Web888 to your local system. The next step is for the tiny bit more advanced users aka the lazy ones like me. This digs into the *nix scheduler which is used for the automation of the download process.

Automate System

Since I'm rather lazy I prefer to automate something as mundane as downloading files. So to automate the download we use a *nix tool called cron. Cron uses a table called a crontab. The following should help you understand crontab. A crontab entry, or a cron expression looks like this,

<minute> <hour> <day-of-month> <month> <day-of-week> <command>

For example the below cron expression is scheduled at 3 minutes past the hour,i.e. it runs at least once every hour and it will run the script /home/hw/web888_transfer.sh.

To list (-l) the crontab use,

crontab -l
3 */1 * * * /home/hw/web888_transfer.sh "192.168.1.40" "/home/hw/web888/log40_$(date +%Y%m%d"-"%H%M).txt" >> /home/hw/tmp/transfer.log 2>&1

and to edit/modify the crontab table we use,

crontab -e

Note: if you are using the crontab -e command for the first time it might ask you what editor you want to use. Now I can't help you with that choice, I do however use vi but ymmv.

Navigate to the bottom of the file [SHIFT-G].
Next type [SHIFT-A], the message 
-- INSERT --
will pop up. You can now type or copy and paste the following,
3 */1 * * * /home/<your username>/web888_transfer.sh "<your web888's IP-Address>" "/home/<your username>/web888/log_$(date +%Y%m%d"-"%H%M).txt" >> /home/<your username>/web888/transfer.log 2>&1

Note: You need to change <your web888's IP-Address> to the actual IP-Address of your Web888, the shell variable does not work here.

Press [CTRL-C] to stop the editing process and then press [SHIFT-ZZ] (not a typo it is double Z)

You'll be greeted with,
crontab: installing new crontab

And that's it. Done and dusted.

Note: You need to download the web888_transfer.sh file into your home directory and make it executable. The following command will make the web888_transfer.sh user executable, 

chmod 700 ~/web888_transfer.sh

Please note that you are free to mangle any of the above to suit your needs. This is something that should work and point you into the right direction. Since I use two Web888 my setup/schedule/script is/are a bit different.

Good luck, and if I've made a(ny) mistake(s) (highly possible) drop me a note and I'll rectify it.

Oh, and a final word! Don't forget that you have to do steps 2 & 3 and maybe the UPDATE below, after you upgraded the OS (firmware) of the Web888. 

UPDATE:

I forgot that the newer *nix's don't allow cron to be used by users so you might need to add your user account to the cron.allow file. To solve this run the below from your login,

sudo sh -c 'who am i | cut -d" " -f 1 > /etc/cron.allow'

And then check,

cat /etc/cron.allow 
<your user name>

And we most likely need to restart the cron daemon. For that we issue this command,

sudo service cron restart

and the check,

sudo service cron status
● cron.service - Regular background program processing daemon
     Loaded: loaded (/lib/systemd/system/cron.service; enabled; vendor preset: enabled)
     Active: active (running) since Sat 2025-10-04 19:30:08 ACST; 7s ago
       Docs: man:cron(8)
   Main PID: 32363 (cron)
      Tasks: 1 (limit: 4915)
        CPU: 15ms
     CGroup: /system.slice/cron.service
             └─32363 /usr/sbin/cron -f


Appendix

A few examples of how to process the log file.

Show all WSPR decodes:
cat web888/sdr40.log | grep "WSPR DECODE" | grep -v " UTC " | awk '{print $1,$2,$3,$12,$13,$14,$15,$16,$17,$18,$19,$20,$21,$22}'

Oct 3 23:20:01 2318 -18 0.3 21.096153 1 VK4GAW QG62NS 1657 23 (200 mW)
Oct 3 23:20:01 2318 -2 0.4 7.040137 0 VK3GOD QF23 583 23 (200 mW)
Oct 3 23:20:01 2318 -26 0.2 21.096146 0 VK4WGR QG62 1629 0 (1000 uW)
Oct 3 23:20:01 2318 -7 0.0 14.097032 0 VK2OP QF69 1452 23 (200 mW)
Oct 3 23:20:02 2318 -13 0.2 14.097101 0 KO4VJV EL89UG 16140 43 (20 W)
Oct 3 23:20:02 2318 -15 0.1 28.126183 -1 WA7X DM49 14017 30 (1.0 W)
Oct 3 23:20:03 2318 -15 0.2 14.097012 0 VK2QQ QF67GT 1338 23 (200 mW)
Oct 3 23:20:03 2318 -18 0.1 28.126169 1 VK6JJJ PH16 2910 23 (200 mW)
Oct 3 23:20:03 2318 -21 0.2 28.126101 0 K5DNR EM13 14984 30 (1.0 W)
Oct 3 23:20:04 2318 -21 2.2 28.126160 0 W3PM EM64 15898 37 (5.0 W)
Oct 3 23:20:04 2318 -22 0.1 28.126087 1 AA7US DM41 13683 23 (200 mW)
Oct 3 23:20:05 2318 -23 0.2 28.126019 1 AD2Q EN81 16371 30 (1.0 W)
Oct 3 23:22:01 2320 11 0.5 18.106102 -2 VK4AAN QG61AH 1475 30 (1.0 W)

Show all FT8 decodes:
cat web888/sdr41.log | grep "FT8 DECODE:" | awk '{print $17" "$18,$19,$21,$20,$12,$13,$14,$15,$16}'

Fri Oct 3 2025 23:33:00 14074.750 KT4DM EM78 -14 16166km
Fri Oct 3 2025 23:33:00 18100.778 WA6VZN FM19 -13 16865km
Fri Oct 3 2025 23:33:00 24916.606 BG8KUB OL39 -15 7956km
Fri Oct 3 2025 23:33:15 24917.353 JA3OOK PM74 -12 7800km
Fri Oct 3 2025 23:33:15 28076.541 JH1BTY PM95 -11 7902km
Fri Oct 3 2025 23:33:30 18101.684 PY3FOX GF49 -14 12601km
Fri Oct 3 2025 23:33:30 18102.344 K5TIA EL29 -11 15004km
Fri Oct 3 2025 23:33:30 28075.403 7L4JWS PM96 -14 8014km
Fri Oct 3 2025 23:33:30 28076.106 RC0JD PO33 -13 9967km
Fri Oct 3 2025 23:33:45 18101.547 JA2YSO/P PM85 -12 7904km
Fri Oct 3 2025 23:33:45 24917.247 W2XX DM26 -13 13569km
Fri Oct 3 2025 23:33:45 24917.494 N0FW EM79 -9 16181km
Fri Oct 3 2025 23:33:45 28076.934 JA8NRS QN12 -11 8692km

Show all FT8 decodes from JA's

cat web888/sdr40.log | grep "FT8 DECODE:" | awk '{print $17" "$18,$19,$21,$20,$12,$13,$14,$15,$16} ' | egrep " J[A-Z][0-9][A-Z][A-Z][A-Z]| J[A-Z][0-9][A-Z][A-Z]"

Fri Oct 3 2025 23:31:15 28076.878 JI1ISA PM95 -13 7902km
Fri Oct 3 2025 23:31:45 21076.228 JK3HFN PM75 -10 7911km
Fri Oct 3 2025 23:31:45 21076.888 JI2VWY PM85 -13 7904km
Fri Oct 3 2025 23:32:00 28076.619 JA0IAA PM97 -9 8125km
Fri Oct 3 2025 23:32:15 18102.459 JF2DEJ PM85 -7 7904km
Fri Oct 3 2025 23:32:45 24915.581 JA2MAX/P PM95 -11 7902km
Fri Oct 3 2025 23:33:15 28076.541 JH1BTY PM95 -11 7902km
Fri Oct 3 2025 23:33:15 24917.353 JA3OOK PM74 -12 7800km
Fri Oct 3 2025 23:33:45 18101.547 JA2YSO/P PM85 -12 7904km
Fri Oct 3 2025 23:33:45 28076.934 JA8NRS QN12 -11 8692km

Show all 40m FT8 decodes
cat web888/sdr40.log | grep "FT8 DECODE:" | awk '{print $17" "$18,$19,$21,$20,$12,$13,$14,$15,$16} ' | grep " 707.\.... "

Fri Oct 3 2025 21:13:00 7076.325 EA2A IN92 -13 16479km
Fri Oct 3 2025 21:13:45 7074.347 EB4SM IN80 -14 16637km
Fri Oct 3 2025 21:14:45 7074.256 B97LRZ/P AE63 +1 4624km
Fri Oct 3 2025 21:15:30 7075.100 IZ7LDC JN80 -12 14967km
Fri Oct 3 2025 21:16:00 7075.866 PE5ZWC MF78 +11 5812km
Fri Oct 3 2025 21:20:00 7075.094 DF2RQ JN57 -13 15551km
Fri Oct 3 2025 21:20:45 7075.634 YC1GCM OI33 -15 4566km
Fri Oct 3 2025 21:43:45 7076.169 EA7KPT IM67 -15 16954km
Fri Oct 3 2025 21:54:45 7076.775 VK6WX OF85 -10 1969km
Fri Oct 3 2025 23:08:30 7076.259 9T5NJE/R HN63 -16 18503km

Monday, April 28, 2025

Digital Pre-Distortion (Puresignal)


Linearity

Let's briefly talk about the linearity of a Power Amplifier (PA), which states that the output of such amplifier increases linearly with the increase of the input signal.  This basically means that if we have a PA with a stated gain of 10 dB, and if we put 1W into the amplifier we should see an output of 10W. Unfortunately, this isn’t an ideal world. Todays Transceivers use transistors in the PA stage, which are active devices and inherently nonlinear. Now if we use PAs in their linear region, then the output power is relatively proportional to the input power. However, the downside of this approach is that the PA is generally used in a very inefficient state in which most of the power provided is being lost as heat. We often want to use PAs at the point where they begin to compress. What this means is that if the input power is increased by 3 dB and the PA output power only increases by 1dB, the PA is operating at the  non-linear region.


Pic.1 Input Signal vs Output Signal

As soon as the PA approaches the saturation point and enters the non-linear region, the interference increases. To sum it up, when an amplifier is fed with a multi-tone signal at its input, it amplifies all the signals and in the process will generate unwanted signals (distortion).


Pic.2 A PA used in its NON-Linear region

Digital Pre-Distortion

Most of us understand that IMD is an unwelcome and an undesired by-product of any amplifier. And fortunately there is this method to reduce IMD called Pre-Distortion. Pre-Distortion or PD basically works by making our rf-amplifiers more linear by (pre-)distorting the input signal to the amplifier. Pre-distorting the input signal in such a way as to offset the amplifier distortion at the output. Basically this means that we are able to correct the output to behave very much like an ideal amplifier, well close to an ideal amplifier anyway.


Pic.3 Amplifier Linearity without Pre-Distortion, Ideal vs Measured


As we can see from Pic.3 the PA is going into compression fairly early ,i.e. the PA is mostly working in the non-linear region. However, at Pic.4 compression starts very late, as such the we can see that the PA characteristics follow the ideal for qute a while.


Pic.4 Amplifier Linearity with Pre-Distortion, Ideal vs Measured

Please note, that in addition to the amplitude distortion (Pre-Distortionthere is also phase distortion (the amplifier phase shift varies as a function of signal amplitude) which also must be corrected to achieve significant reductions in IMD. 

The two graphs below show us the Phase relationship when Pre-Distortion (PD) is used. Pic.4 without PD and Pic.5 with PD applied.
Pic.4
Pic.4

Pic.5

Todays compute power of Software Defined Radios (SDR) can easily be used to calculate the required corrections required for PD. These corrections are then applied to the digital transmit samples to create a near perfect output signal. 

NOTE: Digital Pre-Distortion is also known as "Puresignal" (PS), as implemented by Dr. Warren Platt in the WDSP library. 

PS continuously monitors and corrects the output signal of the rf-amplifier either the internal on inside the radio or an external one. To be able to do so, the software implementation requires a second digital receiver and, if an external rf-amplifier is going to be used in the PS loop, a suitable sensor/sampler (TAP) which will feed a low power signal into a second digital receiver for further processing in the software. This method is called Adaptive Pre-Distortion, as it adapts continuously to the changes in the output signal. 

Pic.6


The above is a simplification of what is going on in the PS loop. The correction is actually performed in the Software (WDSP) and the loop is run in the digital domain of the SDR. 

Do's and Don'ts 

As mentioned above if we use an external amplifier and want to use PS we need a sample of the signal after the amplifier i.e., the signal which is going out towards the antenna. Depending on the sampler/tap used, additional attenuation might be needed to be inserted into the feedback to make sure that the receiver is not going to add additional distortion products to the signal and, of course to protect the sensitive front end of that second receiver.


NOTE: MAKE SURE THAT YOUR FEEDBACK IS ALWAYS SUFFICIENTLY LOW (ATTENUATED) SO IT DOES NOT DAMAGE YOUR HARDWARE.

  • It is very important that the feedback level does NOT create an ADC Overload situation.
  • However, to achieve the best PS results, the feedback level must be as CLOSE as practical to ADC Overload.
  • On my ANAN 100D ADC overload occurs at approximately ‐11dBm (about 180 mVpp).  
  • Again I can't stress it enough DO NOT CREATE an ADC overload condition.

PA Memory Effects

There is this phenomena in RF-amplifiers called Memory Effects. I try to explain this as best as I possible can. What this means is that the amplifier gain and phase are not only a function of the current input signal but also a function of past input signal(s), i.e. the amplifier remembers the past. These effects can be temperature and/or bias (PWRS) related. This is most prominent using SSB. The signal into the amplifier changes with speech pattern of the operator and so we have strong signals and weak signals into the amplifier. Suppose that a strong signal sends the active device(s) in the amplifier into a hot situation thereby briefly changing its gain and other characteristics. The amplifier will remember this state/characteristics until it cools sufficiently down again. However, in the meantime a number of weaker signals arrive at the amplifier however, they have been predistored for a different state of the amplifier. The end result is a PS issues. This is also true for bias and the supply voltages. Which can also change the gain and other characteristics of the amplifier. 

Having used PS with a 13.8V 400W - 8dB gain linear-amplifier with voltage supplied from a 60A PWRS, I've detected some memory effects running the amplifier at about 380W output. Dropping the input by 25% solved that issue. There was no issue with the supply voltage, so I assume the issue was more related to heating of the amplifier. I did not add additional cooling, which might have solved that issue. However, using amplifiers with high voltage power FET(s) or LDMOS devices I have not detected any memory effects (YMMV).

So a few points to take away from this to minimise memory effects:
  • Make sure to monitor the temperature of the amplifier. Using amplifiers with more headroom to keep the amplifier running cool or adding additional cooling should keep memory affects away.
  • It goes without saying that enough headroom in the PWRS is also required to avoid voltage sag.
  • Sufficient heat dissipation of all parts.

Puresignal Correction Bandwidth

Another point to consider when operating PS is, the PS correction bandwidth. 
For PS to be able to correctly compute correction, all IMD products need to be within the bandwidth of the receiver used to receive the feedback of the amplifier. PS can only correct what it can "see" within the bandwidth of the channel. The sample rate dictates the bandwidth of the receiver and since this is set in the firmware to be 48ks, the correction bandwidth would be 48kHz. 
However, we would need to consider a bit of filter roll‐off and so the correction bandwidth would really be more like 40 kHz e.g., +/-20kHz from the center frequency.
For most of us that is not an issue however, for some this could become an issue. PS will NOT work well with very dirty signals e.g., signals which are dirty by overdriving the available hardware.


APPENDIX

  • The current fav is to use a Hermes Lite, which has about 5W pep output, then add a low voltage intermediate amplifier, before finally driving a tube or a low gain high-power solid state amplifier. If you managed to read all of the above you would have garnered a good understanding now of why that might be fraught with problems. An easier solution would be to forget about the intermediate amplifier and to use a high gain solid state amplifier.

  • The effects of Digital Pre-Distortion (Puresignal) (no external amplifier)
2 tone signal without DPD/PS

2 tone signal with DPD/PS

Voice signal without DPD/PS

Voice signal with DPD/PS

  • Digital Pre-Distortion as implemented in Direct Sampling SDR.

  • Digital Pre-Distortion as implemented in WDSP (Puresignal)



Tuesday, April 15, 2025

A very quiet (EMI) 5V SM-PWRS

My 5V rail supply, a home build job using a 5V step-down regulator which is being fed of one of my 12V rails is starting to hit its limit at about 40W. If I start up an additional Raspberry Pi the thermal protection activates and the regulator shuts down. Bugger.
Time for a new supply. I have an old (>25 years) AT switch mode power supply (SMPS) which had at one stage been put into service as a bench supply to supply +-5V and +-12V for projects. Since I have upgraded my bench supply this unit was sitting in a box ready to be ....

Anyway cutting a long story short I decided to use this SMPS as the unit to supply the shack with 5V. Now this unit is not the best when it comes to EMI and so I rummaged through my store and found a few items to make the supply as noise free as possible.
Below is the design of the whole supply. This AT-SMPS is a 200W unit. With a rating of 20A for the 5V rail (100W), about 60W more then the current supply. I'm now able to run a few more Raspberry Pi churning away in the shack.

The AT-SMPS has been stripped down to its bare bones and only the 5V rail is being used. Since I already have enough 12V power available in the shack I did not bother with the 12V rail.

All parts fitted nicely into the original case. Here are a couple of photos of the modification.



Here we see the filtering for the fan, a 220µF and a 0.1µF capacitor and a 10Ω resistor to slow the fan down a bit.



And the 5V output stage with the 135µH choke, the 2200µF capacitor and the 0.1µF capacitor to frame/chassis ground.



This is the little Schaffner FN610, a 10A single stage line filter. 10A is a bit overkill but is was the best size to fit into the case. Since the SMPS already had a single stage input filter I hope that an additional single stage would be enough.



Next I started to setup the test bench to see if I managed to quieten the unit down. 



This is a picture of the noise the SpecAn is picking up with only the mag-probe attached. Note the big spike in the middle at 148.7MHz is one of the local pagers. This pager is causing me endless grief. Working on a solution currently, though. 
Note, the Power supply is switched off.



The above picture shows the probe attached to the power cord of the SMPS.
The next picture is with the power supply switched on and the probe attached to the 5V rail.



Note: No load attached to the 5V rail.

The below shows the noise voltage as measure on the 5V rail with the mag-probe.




The next picture is with the probe attached to the 5V rail, SMPS switched on and a load (LED globe) attached. 


We can see that we have a bit of noise from about 13 MHz on wards. However, it is still less than 85 dB down. But we also can see that below 1 MHz  noise has increased, so let's zoom in, to have a better look.



So from about 200 kHz we see a steady increase of noise to about -18dBm at 10kHz. So the VLF spectrum will be still a bit noisy. However, from 200 kHz to 1 kHz the noise is less than -80 dBm and from 1 kHz the noise is below -90 dBm. So I'm happy with the result.


And the noise voltage between the negative rail and the frame ground measure with a 10x probe.


Conclusion


The VLF/ELF noise might be reduced further if a FN610-3 would be use as this unit has 4.5 time more induction than the FN610-10. Reducing the FAN speed has quieten the wind noises so the power supply is also acoustically quiet. The next few days will show if it is as good as the old 5V regulator (or better).

And yes, "Hot Glue" keeps everything in place.

NOTE: This can also easily be applied to a 12V SMPS or the 12V rail in any of the AT-SMPS. Make sure that you use appropriate electrolytic capacitors though (min 16V better 25V).

Appendix



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.