A legacy of service, a future of innovation
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.
More soon …
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 gitOnce git is installed I downloaded the software from the git repository.
git clone https://github.com/JamesP6000/WsprryPi.gitIt 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.cUsing 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
Once compiled without errors, I just needed to install the binary.
make installAt 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.
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.
M0AWSMy Callsign
JO02My Locator Square
10The 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.logThe 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.
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.
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 …
I’ve had a few messages of late asking how I generate my WSJT-X log web pages for my website. The answer is pretty simple, I use a little BASH script that I started writing some time back and have gradually improved over the last few months.
If you have a PC running Linux or a RaspberryPi running any of the normal Debian/Ubuntu/Redhat/Fedora based Linux distro’s that are available today then, this script should work just fine.
I originally wrote this program using Python but, a friend of mine bet me that I couldn’t write it in BASH and so, I took up the challenge and this is the result. It’s pretty simple and uses all the normal UNIX command line goodies like grep, sed and awk.
The script also uses WWL to calculate the distance between two Maidenhead locator grid squares and so it’s important to have it installed before running the script. (The script checks for it at runtime and will exit if it is not installed!). You can install WWL using your package manager on your Linux distro or from the command line directly. Details are in the READ-ME.txt file.
It’s important that you READ the READ-ME.txt included in the zip file before trying to run any of the scripts included as it details the variables that you need to enter values for to make the script run on your PC/Server. (Example entries are in place as supplied).
The variables are mainly just paths to files on your system and whether you want distances calculated in miles or kilometres. Other than that there’s nothing else required for it to run.
I’ve also included details on how to run the script automatically from a crontab so that your webpage can be updated automatically every few minutes/hours etc.
The script also includes code to add a PNG map file into the generated webpage so that there is a graphical representation of all your QSOs. The map isn’t generated by the script (something I need to add in the coming few months) so you’ll need to generate it yourself and then add it to the website either via the crontab script included in the zip file or manually.
I use the QSOMap website to generate my map image files and then have them uploaded to my web server via the crontab script.
The script processes 100 entries per second on my web server (Headless virtual machine running Ubuntu Server 64bit Edition) and so should be pretty fast on most PCs. It will run somewhat slower on a RaspberryPi so be patient!
You can download the script and associated information using the button below.
If you do use my script please send me a link to your website so that I can take a look at your log file.
More soon …
Being a UNIX/Linux command line guy I’m not a fan of a lot of these GUI based logging programs that are full of functionality I’ll never use. I currently have RumLogNG for the MacBook Pro but, I really don’t like it. It does many things I don’t need and not the things I really need when on air.
So I decided to write a bunch of command line based programs that do exactly what I want with minimal fuss. The first of these programs was adi2html, a simple program that converts the WSJT-X ADI log file into HTML so I can easily put it on my website.
I’ve now written a new program using the same BASH shell technique to allow me to search the WSJT-X log file quickly and easily whilst on air.
searchwsjtxlog is a simple little shell script that searches for either a full or partial callsign and presents the results instantly. I use this script a lot when working FT4/8 as I can see if I’ve worked a station before and on what bands easily and quickly.
The script works on Linux and MacOS Big Sur (Not got Monterey to test but, should work fine). If you find a bug please let me know and I’ll fix it as soon as possible.
Note: Since MacOS uses such an old version of the BASH it cannot handle spaces in the path to the wsjtx_log.adi file. On MacOS you’ll need to create a softlink to the file and then put the path to the soft link into the script for it to work properly. CD into the directory where you have saved the searchwsjtxlog.sh file and then run the following command:
ln -s /Users/YOURUSERNAME/Library/Application\ Support/WSJT-X/wsjtx_log.adi ./wsjtx_log.adi
Make sure you replace YOURUSERNAME with your MacOS username. The command is all on one line and not on two lines as shown above.
You can download v0.4 of searchwsjtxlog using the link below.
More soon …
Following on from the adi2html v0.5 release I’ve now added a little more code to include a map of the contacts detailed in the wsjtx_log.adi file so that there is a visual representation of the data included in the webpage. (Map must be generated externally and JPEG/GIF/PNG uploaded to website to be included in the webpage).
See my WSJT-X log here
Just to recap, adi2html generates a HTML webpage from the wsjtx_log.adi file so that the log can be presented in a palatable format on a website.
As before the code can be downloaded using the link below.
If you use my code please consider leaving the footer in place so I get some credit, thanks!
I’ve started using RUMLogng for logging on my MacBook Pro as it seems to be the most common logbook to use on the Apple Mac platform. I must admit that I’m not sure if I’ll carry on using it going forward as I’m not overly enamoured by it but, for the time being it’s all I have.
To get my logs on the blog I’ve written a small BASH shell script that reads the exported ADIF file from RUMLogng and creates a log in HTML format for each different mode.
You can see the output of the BASH script by selecting a log from the Logs menu at the top of this page.
If you want to be able to add your log to your own website then I’ve made the script available for download below.
Currently I’ve only tested the script with the few different modes that I have log entries for but, it should work for all modes. If you find any issues please contact me with all the details and I’ll look into resolving any problems.
As always, if you use my code to generate webpages on your website please consider leaving the footer in place so I get some credit, thanks!
Following on from my original article where I detailed the adi2html Bash script that reads in the WSJT-X log and creates an HTML version of the data so that it can be presented in a palatable format on websites (See my WSJT-X log here), I’ve now released v0.5 for public consumption.
In adi2html v0.5 I’ve added colour to the webpage that is generated to make it easier on the eyes and rewritten the function process_log() so that it uses the column name to identify each field instead of the row position.
By making this change it should cope just fine if the order of the fields is ever altered in the WSJT-X log during its development.
As before the code can be downloaded using the link below.
If you use my code please consider leaving the footer in place so I get some credit, thanks!
I had some spare time today so I finished a small BASH program that I started writing yesterday that reads the wsjtx_log.adi file and writes the data out in HTML format so that it can be incorporated into my website (See the Logs Menu).
(Sorry the font is so small but WordPress is crap at displaying code!)
It’s a fairly simple piece of code that anyone who is into Linux and has a basic understanding of the BASH shell will easily be able to comprehend. (Yes there’s a little awk and sed in it just to add to the entertainment value!).
There are a few places where the code can be improved which I’ll address in v0.3 when I have time but, for now I’ll put it online just incase anyone is interested in using it.
If you do use the code please consider leaving the footer in place so I get some credit.
More soon …