Enhancing Digital modes with Node Red

For a couple of weeks now I’ve been playing with Node Red to add functionality to my digital mode applications.

To get to know how it all works I initially used Node Red to create a series of dash boards for my servers and virtual machines to show realtime information on CPU temperature, CPU load, memory usage and storage etc.

Node Red Flow to collect information from a virtual machine (VM)

This worked very well and I was soon able to generate the information I needed in a palatable format. This was a great way to get to know Node Red flow building and introduced me to using gauge and graph nodes in flows.

The resultant Node Red Dashboard for one of my Virtual Machines

Once I had mastered creating dashboards for servers/virtual machines (VMs) I then started to investigate using Node Red to plot data from WSJT-X on a map.

I currently use the PSKReporter website to see stations that I hear on a map as WSJT-X sends the data to the site automatically however, this information is always 5mins or more old. For some time I’ve been wanting to see the information realtime as it is received and so I was hoping to be able to achieve this via Node Red.

Node Red has nodes available for a multitude of applications all easily installed via the Manage Palette menu in the flow editor.

I installed the WSJT-X Decode and World-Map nodes and set about building a flow to capture the data and plot it on a world map.

Building a Node Red Flow to decode WSJT-X data and plot it on a World Map

Putting the building blocks of the flow together is fairly straight forward and easily achieved using the excellent flow editor built into Node Red.

I configured WSJT-X to make the decode data available via UDP on port 2237 and then started the flow by creating a UDP node that connects to WSJT-X using the same port. The data immediately started flowing and I could see the information via a debug node.

I can’t stress enough how useful debug nodes are in Node Red. You can add debug nodes onto any output on any other node to capture the data as it flows. This gives you the ability to check what you’re getting is what you expected and also to see the format the data is in. The debug data is displayed in the debug panel on the right of the flow editor in realtime and gives you a great view of what is going on in your flow.

I decided to start with capturing the data for stations calling CQ as this was easily identifiable in the JSON object coming out from WSJT-X.

Passing the output from the WSJT-X-Decode node into a switch node I added a rule that filtered out data containing “type: “cq” and passed it onto the next switch node that created a payload consisting of the station callsign, maidenhead grid square and type so that it could be passed onto the next node for processing.

The next node in the flow is a function, this is where it gets a bit tricky. To be able to plot data on the map we need the Lat/Lon coordinates of the station making the CQ call. Since WSJT-X uses maidenhead locator data I needed to convert this to Lat/Lon coordinates before passing the data to the map node to be plotted.

Since Node Red is written in Java all the functions have to be written in javascript. The problem here is that I am not a javascript programmer and so this meant I’d need to learn yet another programming language. Unfortunately Node Red doesn’t allow functions to be written in C, Rust, Go or Python, all languages that I know well and after retiring from over 40 years in the UNIX/Linux/IT world my enthusiasm for learning yet another programming language has wained somewhat.

Being so close to having a working solution I pressed on and after much head scratching I finally put together some javascript that converts the maidenhead locator information in to good old fashioned Lat/Lon coordinates. I’m sure a seasoned Javascript developer wouldn’t be impressed with my code but, it works and does what I need and so I’m happy with it for the time being.

WSJT-X FT8 stations calling CQ on the 60m Band plotted on a Node Red World Map

Once I had the location information converted it was just a matter of passing the data to the world map node in the correct format for it to be plotted realtime.

As you can see on the screenshot of the map above, it worked extremely well with stations popping up as they were decoded by WSJT-X.

I now need to refine the data sent to the map so that it shows the frequency the station is calling on, the time they made the CQ call and the mode (FT8/FT4 etc) being used.. I would also like to add the distance from my QTH to the station calling CQ to round the information off however, this will mean writing another javascript function which, I’m not sure I want to dive into just yet.

I also need to add into the mix stations that aren’t calling CQ but, who’s callsign and grid square are passed on from WSJT-X. This will mean I will then be able to add to the map those stations that are actively working other stations and maybe I might even be able to show a line between the two stations that are in QSO.

This has been a fun but, steep learning curve however, it will certainly add some great functionality into my radio room and enhance my radio HAM addiction even further.

More soon …

QO-100 Station – Initial parts purchase

After much reading and viewing of youtube videos I have finally settled on the parts that I want to use to build my QO-100 Satellite ground station.

Initially I’m only going to build the receive path of the QO-100 station. From the articles and blogs I’ve read online all the experienced Amateur Radio satellite Op’s recommend getting the receive side sorted first and then moving onto the transmit path.

I need to stress here that I have no experience of radio above 433Mhz (70cm), a band that I have only used a handful of times. 99% of my Amateur Radio life has been spent below 30Mhz and so this is going to be a very new experience for me.

So, what am I going to purchase for the receive path?

I’ve settled on a 1.1m off-set dish from the Satellite Super Store that should give me plenty of gain if I manage to get it pointed successfully at the bird.

I’ll pair a Bullseye 10Ghz TCXO LNB with the dish to give me a high stability receive path that shouldn’t wander too much up and down the band with temperature changes throughout the seasons.

1.1m Off-Set Dish for QO-100

The Bullseye LNB gets extremely good reviews from the HAM Satellite community, although it is a little on the expensive side compared to many others available. Since I only want to do this once I’ve gone with the more expensive option in the hope that it gives me the stability I’m looking for.

Since we’ve never had satellite TV here at home I’ve only just learnt that LNBs require a voltage feed since reading about other peoples QO-100 station builds. Most LNBs can be used for either horizontal or vertical polarisation and are switched by feeding with either 12v or 18v respectively. The LNBs also use this same voltage feed to do the frequency down conversation and some amplification of the received signal.

At the moment I’m only looking to get onto the narrowband part of the QO-100 satellite service and so I will need to feed the LNB with around 12v to ensure vertical polarisation is achieved. The easiest way to do this is to inject the 12v feed up the coax cable to the LNB.

Bullseye 10Ghz TCXO LNB

To achieve this I will need to purchase a little circuit called a Bias Tee. This relatively simple circuit consists of a capacitor and inductor combination that stops the 12v from going back into the receiver whilst at the same time stopping the RF from going back into the power supply.

Bias Tee units are relatively cheap to buy online and I have decided to get one from Amazon that has been recommended in a number of blogs posts I have read during my research.

Broco Bias Tee

With these parts ordered I now need to source the materials to mount the dish up above head height in the garden with a clear view of the sky in the direction of the satellite.

Getting the dish up high enough to be above head height will be important for when I get the 2.4Ghz uplink path in place. At these frequencies it’s important to ensure that no one is able to walk across the front of the dish whilst I’m transmitting. I’m hoping to get the dish up about 3m in the air in such a fashion that it is rigid enough to stop the dish moving around in the wind. I must admit I’ve not done any wind load calculations for the 1.1m dish so I’ll have to see how it goes over time. Fortunately where I want to put the dish is fairly well sheltered from the north wind that often howls through here so, hopefully it won’t be an issue.

More soon …

Funcube Dongle Pro+ / GQRX / Kubuntu

Many years ago I purchased a Funcube Dongle Pro+ (FCD) SDR. Since it’s arrival it has just been stored in my “Get round too it” drawer.

It’s been many years but, today is the day it comes out into the light and finally gets powered up.

Funcube Dongle Pro+ USB SDR

I’m hoping to be able to use the FCD as the receiver in my QO-100 satellite ground station setup.

The output from the 10Ghz dish mounted LNB is around 739Mhz, well within the FCD receiver range of 150khz to 2Ghz. This will save me from having to transvert from 739Mhz to 430Mhz (70cm band) on the receive path.

This will also give me full duplex operation as I will use my Icom IC-705 on the 2m band (144-146Mhz) to drive the 2.4Ghz transverter for the satellite uplink whilst listening to my own signal via the 10Ghz downlink fed into the FCD.

Before I can even start to build the QO-100 satellite ground station I need to get to grips with the FCD, get the software installed, configured, resolve audio routing via virtual audio cables and get it decoding FT8/JS8/WSPR etc.

Talking to G0DUB in the General Amateur Radio Chat room on Matrix he recommended trying the GQRX software to drive the FCD. GQRX is open source which fits perfectly as I want to control the FCD from my Kubuntu PC.

Checking the Ubuntu repo’s I found that GQRX v2.12 is available for installation.

sudo apt install gqrx-sdr

Once installed I fired up GQRX and set about configuring it. Initially it appeared to have automatically detected and configured the FCD however, when I started the FCD the software ran for 5 seconds and then just hung.

Diving into the configuration settings I found that the FCD actually appears twice in the list of available devices and all I had to do was select the other one in the list and start the software again and all was well.

I connected my 20m Band EFHW Vertical antenna and trawled up and down the band. The receiver performed well even with fairly strong signals so, I spent some time listening to a few of the stations coming in from the USA.

Next I wanted to sort out the configuration for digital modes. I already have a couple of virtual audio cables in the form of loopback audio devices configured on my Kubuntu PC as this is how I connect the audio between WFView for the IC-705 and WSJT-X/JS8CALL.

Sadly, GQRX doesn’t recognise the loopback audio devices that already exist and so I had to do a little further research to get to the bottom of the issue.

Digging deeper I discovered that GQRX requires loopback audio devices created using Pulse Audio and not the kind I had already created at the O/S level. A quick read of the pactl man page and some further searching online I found all the info I needed to create the correct kind of loopback audio devices.

Two commands are required to create the pulse audio server audio loopback devices:

pactl load-module module-null-sink sink_name=gq2jt sink_properties=device.description="gq2jt"

pactl load-module module-loopback latency_msec=1

Once I’d created the loopback audio devices I was able to select the gq2jt devices in both GQRX and WSJT-X/JS8CALL so that the audio was routed correctly.

GQRX SDR and WSJT-X working with the Funcube Dongle Pro+

The overall solution works well and doesn’t put much load on the CPU of my Kubuntu PC, leaving plenty of horse power for me to do other things at the same time.

So I now have the Funcube Dongle Pro+ working perfectly on my Kubuntu PC, all I need now is a 1.2m dish, a 10Ghz LNB and some high quality coax cable.

UPDATE: I decided to leave the FCD connected to the 20m Band EFHW Vertical overnight and monitor FT8 on the 40m band. The EFHW antenna isn’t anywhere near resonant on the 40m band and so I thought it would be interesting to see how well the FCD performed on a completely non-resonant antenna.

To my surprise it did exceptionally well, stations from all over the world were heard with ease, the FCD really is an excellent little SDR receiver.

Map showing stations heard on 40m Band FT8 over night 16/17 Jan 2023

If you’re looking for a relatively cheap but, effective receiver for FT8/WSPR monitoring then I can highly recommend the FCD. If paired with a RaspberryPi then it would be a really cheap to purchase/operate solution for any HAM operator or short wave listener (SWL).

More soon …

A Great start to 2023

The 2023 new year has got off to a great start here at the M0AWS radio shack with my first QSO with New Zealand since setting up the new radio room.

It’s been almost a year now since I started putting the radio room together and throughout all this time I’d not been able to secure a complete QSO with New Zealand.

Well today was the day that I finally achieved what seemed like the impossible.

M0AWS WSJT-X QSO Map as of 3rd January 2023

ZL4AS was the first New Zealand station that I’d managed to complete a full QSO with, up until now I’d made a few ZL contacts but, never managed to complete the QSO due to conditions on various bands.

The band of choice today was 17m, a great WARC band that has provided me with much of the DX over the last year. This band really does give full global comms when it’s open.

With a new longest distance of 11776 Miles to ZL4AS in Balclutha New Zealand, I’m looking forward to see what new countries 2023 brings to the M0AWs radio room.

More soon …

JS8 Logs now online

I’ve now added my JS8/JS8CALL logs to the website for both QRO (25w Max) and QRP (<10w) QSOs.

The JS8 logs are available from the Logs menu above.

I’ve updated the adi2html program to now be capable of processing the JS8CALL log file and will be releasing it into the public domain soon.

M0AWS QRP JS8 Online Log

More soon …

Social Media – Sucking the life out of our devices

Let me be up front from the outset, this isn’t a HAM Radio related article but, something that probably affects 99% of people today.

I’ve recently given up using social media. Like many of you reading this I had Instagram, Facebook, Twitter etc etc installed and active on all of my devices. Throughout the day and night my iPhone and iPad would be constantly notifying me of posts in the HAM Radio/Motorcycle/Adventure groups I was linked into, or that Jonny/Karen had posted something that I may be interested in, even though 99.99% of the time I wasn’t interested at all.

Even switching off notifications these apps still found ways to continually pester me, so annoying!

Then there was the toxicity, I was genuinely shocked at the constant barrage of hate and anger in the HAM Radio groups. If someone posted something about a radio/antenna/device and others disagreed there was this immediate attack and following argument that went on for days. These nearly always ended up with personal insults and hatred, whatever happened to respecting others opinions?

The HAM Radio groups weren’t the only ones either, the motorcycle groups were just as bad as were the adventure groups, social media really does bring out the worst in people.

Would we all really speak to each other in the same manner face-to-face? I doubt it!

So I deleted all my social media accounts and deleted the apps from all my devices and this is where something very positive happened.

Apart from the fact that my devices were no longer hounding me 24hrs a day, the batteries in my devices were lasting considerably longer.

With the social media apps installed my iPhone battery would barely last a day however, after deleting the apps I was amazed to find that after the next full charge my iPhone battery now lasted 2.5 days without a charge!

Even though I had my iPhone set not to allow the social media apps to update in the background and switched off notifications they were still consuming massive amounts of energy from the battery of the device even when the apps had been closed and were not being used.

Clearly the social media apps are busy skimming data in the background constantly collecting GPS information, movement, app usage etc etc building up a profile for targeted advertising. This data skimming is using considerable amounts of energy from the battery and it has to be questioned if this is reducing the life of device batteries overall.

I found the same on my iPad Pro too, battery life is now considerably longer, not quite as long as my iPhone but, it too is now lasting two days on a single charge even though I use it daily.

So, apart from no longer being exposed to the toxicity of social media, my device batteries are now lasting some 2 to 2.5 times longer allowing me to consume the content that interests me for longer rather than the batteries being discharged by the constant, silent collection of data for social media companies to sell on to advertisers.

If you are an avid social media user then perhaps now is a good time to consider deleting the apps from your devices and instead start using the website interface for each platform, this way you can still get your daily fix of targeted adverts but, without the constant drain on your battery.

Normal content will resume soon …..

Getting chatty with JS8CALL

JS8CALL running on my MacBook Pro

I’ve been chasing the DX on the HF bands using FT8 for a while now and I have to say it’s been very successful however, it does get rather boring after a while just exchanging SNR reports and nothing else. I noticed that my time spent in the shack was getting less and less, not a good sign after all the work I’d put into building the new radio shack.

Since there’s not a lot of CW on the bands these days (everyone is on FT8) I thought I’d give JS8CALL a go.

Initially I started with trying to get JS8CALL working on my Kubuntu PC to my Icom IC-705 wirelessly. This turned out not to be as straight forward as I’d hoped but, I persevered.

I found that to communicate with the IC-705 via WFview wirelessly I needed to use FLRig as a go between. I installed FLRig from the Ubuntu repo’s only to find it’s an old version that doesn’t have support for the IC-705. Downloading the IC-705.xml file didn’t help either so I uninstalled it and headed to the source forge website to grab the source code for the latest version of FLRig.

Once I had the right development libraries installed compiling the code was easy enough and I soon had FLRig talking to the IC-705 via WFview wirelessly from my Kubuntu PC.

My first JS8 QSO was with Jonny, SM5COI in Sweden on the 20m band, using just 2.5w I had a very reliable link from my 20m band EFHW vertical antenna to his 20m band yagi antenna.

I also worked GM0DHD/P via OH8XAT using the relay capability built into JS8CALL, it works incredibly well and allows you to work the stations that you cannot hear directly, very useful!

Later in the morning Jonny, SM5COI emailed me asking for a sked on the 40m band later in the afternoon, of course I agreed and decided that I’d also get my MacBook Pro setup with JS8CALL so I could give my Yaesu FTDX10 a spin on JS8 mode.

Installing and configuring JS8CALL on my MacBook Pro was much easier and I had it fully operational in minutes.

The sked went well on 40m and it was good to get Jonny on another band.

With 3 JS8 QSOs in the log it’s great to be using a digital mode again that allows you to have a good chat with other radio HAMs around the world. I think this may become my preferred digital mode going forward.

More soon…

Dual Band VHF/UHF End Fed Vertical Dipole

Since purchasing my Icom IC-705 radio I’ve only used it on the HF bands. Since the IC-705 is a “shack-in-a-box” I thought it was about time I ventured up onto the VHF/UHF bands and add another string to my bow.

Since I don’t have an antenna for these two bands I’d need to build something. I’m not really interested in DXing on the VHF/UHF bands as I’d need a yagi or two, a rotator and would need to get the entire setup up high on the chimney on the house.

We’re very fortunate in that there are a good many repeaters on VHF/UHF in East Anglia with quite a few being well within range of my QTH.

So I decided to go with a simple vertical antenna of some sort that I could easily attach to the top of a 10m spider pole and pop up in the garden without too much hassle.

The simplest of all antennas to build for any band is an end fed vertical dipole. It’s made purely from a piece of coax cable, you can’t get much simpler.

Using some dimensions I found online I unrolled a length of RG58U and set about cutting it to resonance for the two bands.

To start I measured out 910mm of RG58U and put a piece of tape around the cable at the 910mm point. I then stripped the top 460mm of the outer and braid from the coax so that the inner wire and plastic insulation was exposed. This then left 450mm of coax with the braid still in place to make up the 2nd half of the vertical dipole.

At the 910mm marker I wound the coax 9 times around a 27mm former to create a choke balun. I taped the coil up to ensure it kept it’s shape, removed it from the former and then used a few zip ties to hold it in place.

VHF/UHF End Fed Vertical Dipole Diagram

The diagram above aids in visualisation of the make up of the antenna that is made from a single piece of RG58U coax cable.

Choke Balun made from 9 turns of RG58U on a 27mm former

I next wound some electrical tape around the point on the antenna where the outer insulation and braid ended so that it would stop moisture getting into the rest of the coax and causing problems in the future. I also put a bit of electrical tape across the top of the end of the wire to stop moisture getting into the inner wire and then a piece of electrical tape around the wire to ensure it was fully sealed.

Electrical tape wound around the point where the outer braid finishes

At this point the antenna was complete! It literally took a few minutes to make. I could now either cut the coax a few centimetres from the bottom of the coil and fit a PL259 or just continue the coaxial cable back into the shack and fit a PL259 on the end. I decided to go with the latter as it’s one less connection to make.

VHF/UHF End Fed Vertical Dipole taped to the top of a 10m spiderpole

Once complete, I taped the antenna to the top of a 10m spider pole and then ran the rest of the coax back into the shack and soldered on a PL259 connector.

Raising the spider pole up to its maximum length put the antenna some 10m up above the ground. Hopefully this will give me a relatively clear path to the local repeaters.

Plugging the antenna into the IC-705 and checking the SWR I found it was <1.2:1 across the entire 2m band and <1.5:1 across most of the 70cm band. It was perfect for what I wanted!

VHF/UHF End Fed Vertical Dipole up 10m on a Spiderpole

I configured the local repeaters into the the IC-705 memories so that I could easily switch from one repeater to the next with all the appropriate tone and duplex frequency shifts set at the touch of a button.

My local 2m repeater GB3PO comes in at 5/9+10dB without any preamp and the local 70cm repeater GB3IH comes in at 5/9+5dB without any preamp. I was really pleased with the results and set about having a chat with other local HAMs on the local repeaters. It’s been a while since I’ve used the mic on this radio and it made a nice change!

To my surprise I found I could get into far more repeaters than I ever imagined. GB3NB in Norwich is 5/8 as are a number of repeaters down in Essex. This gives me quite a scope for chatting on the VHF/UHF bands via the repeater network.

To my surprise I can also hear ON0WV in Brugge Belgium, unfortunately it’s on the same frequency as the local 2m GB3PO repeater and so often gets drowned out completely but, it’s good to know that when there’s a lift in propagation I should be able to get into the near continent without too much hassle.

If you’re looking to build a simple but, effective 2m/70cm vertical for local repeater access then I highly recommend making an end fed vertical dipole. It only takes a few minutes to cut the cable to length, remove the outer sheath and braid and wind the choke balun, it really couldn’t be any easier.

More soon …

WSPR update

For the last 24hrs I’ve had the RaspberryPi2 transmitting WSPR on 20m and 10m connected to my EFHW Vertical antenna. So far not a single spot on the 10m band, I’m assuming the band hasn’t opened in the UK over the test period.

WSPR 20m band reports over the last 24hrs

Results on 20m continue to impress with reports from the USA, West Africa coast and as far east as Georgia.

I’ll check the signal on 10m later today using my IC705 to ensure it is transmitting ok and then will leave it running for another 24hrs to see what happens.

UPDATE:

It appears there’s been a reliable opening on both 10m and 20m to the Canary Islands just off the west coast of Africa so far today.

The last 48hrs looks like this:

10mW WSPR from M0AWS JO02QC on 10m and 20m bands

More soon …

Whispering around the world

The Weak Signal Propagation Reporting Network (WSPR) known as “Whisper” in the HAM community is a QRP/QRPp beacon mode that is used by many HAMs around the world to see pretty much realtime propagation on the HF bands.

I first started using WSPR when I lived in France some years ago and it proved invaluable for assessing antenna performance and directivity. It’s not a new mode by any means and nowhere near as popular as it used to be as it’s really been superseded by FT4/8 these days that provides the same functionality but, with QSO capability too.

Having an old RaspberryPi hanging around and reading about the WSPR software that’s available for it now I decided to put the Raspi to good use and build a WSPR beacon for the 20m band that I could leave on 24/7.

Having the EFHW Vertical at the end of the garden means that I can connect it directly to the Raspi without the need for an ATU as it’s fully resonant. (It’s actually resonant on 20m and 10m)

I normally run both my RaspberryPi mini computers completely headless and then SSH in to them from my MacBook Pro and decided this was the best way to go with the WSPR beacon too since the WSPR software is command line based and doesn’t require a GUI.

First thing to do was to upgrade the OS from Debian Buster to Bullseye. It’s been a while since I used the Raspi but, it fired up perfectly and connected to the LAN without issue.

After a little time I had the O/S updated to Bullseye and the Raspi was ready for the software build.

The WSPR program comes in source code only so, this means you have to compile it yourself. This isn’t a big job as it comes complete with a makefile.

Using a terminal run the following commands to download and compile the WSPR source code.

So first thing to do is install git.

sudo apt-get install git

Once git is installed I downloaded the software from the git repository.

git clone https://github.com/JamesP6000/WsprryPi.git

It only takes a few seconds to download the software which is stored in a new directory called “WsprryPi”.

Before the code can be compiled there’s a small issue with the includes in one of the source code files that needs to be resolved so that the code compiles without error.

cd WsprryPi
vi mailbox.c

Using your favourite command line editor, ‘vi‘ in my case I added the following line into the include statement at the top of the code.

#include <sys/sysmacros.h>

Once added the full include statement looked like this:

#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <fcntl.h>
#include <unistd.h>
#include <assert.h>
#include <stdint.h>
#include <sys/mman.h>
#include <sys/ioctl.h>
#include <sys/stat.h>
#include <sys/sysmacros.h>

#include "mailbox.h"

Once done, I saved the file ready for compilation.

Compiling the code is easy, just run the make command and sit back and watch all the compiler messages scroll across the screen.

make
Compiling the WSPR source code

Once compiled without errors, I just needed to install the binary.

make install

At this point the software is ready to go.

I quickly soldered up a lead to go from the RaspberryPi GPIO pins to the Coax cable that is connected to the EFHW vertical antenna in the garden and connected it all up ready to test.

RaspberryPi 2 WSPR Beacon connected to EFHW vertical for 20m/10m bands

Pins 7 and 9 on the Raspberry Pi’s GPIO pins are where the signal is output. Pin 9 is the Ground pin, and pin 7 is the Signal pin. Pin 7 goes to the inner of the coax and pin 9 to the ground side of the coax.

The purple cable is the ethernet cable connecting the Raspi to my local LAN so that I can access it remotely via SSH. I’ve powered the Raspi off of the USB port on the wifi access point in the radio shack which is always on.

Once it’s all connected it’s just a case of starting the WSPR program from the command line as user root.

wspr -s -r M0AWS JO02 10 20m > ./wspr.log &

I run the WSPR program as root user so that it has the correct privileges to access the devices to communicate with the GPIO headers, if you want too start it as your normal user then you’d need to use sudo to gain the root privileges.

The command line options I’ve used are as follows:

-s

Check NTP before every transmission to obtain the PPM error of the crystal

-r


Repeatedly, and in order, transmit on all the specified command line freqs.

M0AWS

My Callsign

JO02

My Locator Square

10

The power being used in dBm

> ./wspr.log &

Redirects all output to wspr.log in the current directory and then puts the program into the background so that it is left running when I log out.

Once the program is started you can monitor progress by using tail on the log file.

tail -f ./wspr.log

The output you will see will be something like this.

Desired center frequency for WSPR transmission: 14.097100 MHz
  Waiting for next WSPR transmission window...
  TX started at: UTC 2022-07-17 16:06:01.015
  TX ended at:   UTC 2022-07-17 16:07:51.638 (110.623 s)
Desired center frequency for WSPR transmission: 14.097100 MHz
  Waiting for next WSPR transmission window...
  TX started at: UTC 2022-07-17 16:08:01.015
  TX ended at:   UTC 2022-07-17 16:09:51.639 (110.624 s)
Desired center frequency for WSPR transmission: 14.097100 MHz
  Waiting for next WSPR transmission window...
  TX started at: UTC 2022-07-17 16:10:01.015
  TX ended at:   UTC 2022-07-17 16:11:51.642 (110.627 s)
Desired center frequency for WSPR transmission: 14.097100 MHz
  Waiting for next WSPR transmission window...
  TX started at: UTC 2022-07-17 16:12:01.015
  TX ended at:   UTC 2022-07-17 16:13:51.639 (110.624 s)
Desired center frequency for WSPR transmission: 14.097100 MHz
  Waiting for next WSPR transmission window...
  TX started at: UTC 2022-07-17 16:14:01.015
  TX ended at:   UTC 2022-07-17 16:15:51.639 (110.624 s)
Desired center frequency for WSPR transmission: 14.097100 MHz
  Waiting for next WSPR transmission window...
  TX started at: UTC 2022-07-17 16:16:01.014
  TX ended at:   UTC 2022-07-17 16:17:51.639 (110.624 s)
Desired center frequency for WSPR transmission: 14.097100 MHz
  Waiting for next WSPR transmission window...
  Obtained new ppm value: 4.09996
  TX started at: UTC 2022-07-17 16:18:01.015
  TX ended at:   UTC 2022-07-17 16:19:51.640 (110.624 s)
Desired center frequency for WSPR transmission: 14.097100 MHz
  Waiting for next WSPR transmission window...
  TX started at: UTC 2022-07-17 16:20:01.014
  TX ended at:   UTC 2022-07-17 16:21:51.638 (110.624 s)
Desired center frequency for WSPR transmission: 14.097100 MHz
  Waiting for next WSPR transmission window...
  TX started at: UTC 2022-07-17 16:22:01.004
  TX ended at:   UTC 2022-07-17 16:23:51.628 (110.624 s)

You can pass multiple bands on the command line if you want to hop around bands.

It’s also recommended that you add a low pass filter between the Raspi and coax connection to help suppress any harmonics that may be generated. You can make one easily enough using just a capacitor or there are a number of prebuilt low pass filters specifically made for the GPIO hat on the Raspi online.

With only 10dBm (10mW) output from the RaspberryPi it’s surprising the distances that the signal travels. In no time at all I had reports from all over Europe and as the day progressed reports started coming in from Iceland, the USA and Russia.

Map showing stations that heard M0AWS on WSPR

I used http://wspr.aprsinfo.com WSPR monitoring website to watch progress as the day went on and after 24hrs had been heard by a number of stations over 3000 miles away.

You can also get a more detailed view of reports from the WSPRnet website where you can query the database and create a detailed list of all decodes over a set period of time.

Detailed list of WSPR decodes

Since my EFHW Vertical is resonant on both 20m and 10m I’ll now run it for the next 24hrs on both bands to see what results I get.

More soon …