Use a Griffin Powermate with SDR via Node Red

I’ve been gradually building my QO-100 ground station over the last few months and have had the receive path working for some time now. One of the things I really miss with the Funcube Dongle Pro+ (FCD) SDR is a real VFO knob for changing frequency.

My QO-100 Node Red dashboard is configured so that I can have the FCD track the uplink frequency from the IC-705 but, sometimes I use the FCD without the IC-705 in the shack and so a physical VFO would be handy.

Many years ago when I lived in France (F5VKM) I had a Flexradio Flex-3000 SDR, a great radio in it’s time and one that gave me many hours of enjoyment. One addition I bought for that station was a Griffin Technology Powermate VFO knob. It worked extremely well with the PowerSDR software for the Flex-3000 and I used it for many years.

Many years later I’m back in the UK and much of my equipment is packed away in the attic, including the Griffin Technology Powermate VFO.

I decided to dig it out and see if I could get it working with GQRX SDR software. Sadly I couldn’t get it working with GQRX however, I did find a way of getting it working with Node Red and thus could add it to my QO-100 Node Red Dashboard and then control GQRX with it via a simple Node Red flow.

Griffin Technology Powermate VFO
Griffin Technology Powermate VFO

Plugging the Powermate VFO into my Kubuntu PC it wasn’t immediately recognised by the Linux O/S. After a little searching I found the driver on Github. I added the PPA to my aptitude sources and installed the driver using apt.

https://launchpad.net/~stefansundin/+archive/ubuntu/powermate

Once installed the default config for the Powermate device is to control the default audio device volume. To make the device available for use as a VFO knob you need to change the configuration so that the default setting is disabled. To do this is relatively easy, just edit the config file using your favourite command line editor (Vi/Vim in my case) and add the following entry.

vi /etc/powermate.toml

# Entry to control HDMI volume with Powermate
#sink_name = "alsa_output.pci-0000_01_00.1.hdmi-stereo"

# Set powermate not to work with volume control
sink_name = ""

As shown above, comment out the default “sink_name” entry (Yours may be different depending on audio device in your PC) and add in the Powermate “sink_name” entry that effectively assigns it to nothing.

Once this is done, save the file and exit your editor and then reboot the PC.

Next you’ll need to install a small program called evtest.

sudo apt install evtest

To check the evtest program has installed correctly, plugin your Powermate VFO to any available USB port and run the following command in a terminal.

evtest /dev/input/powermate

Turning the Powermate knob you should see output on the screen showing the input from the device. You should also see BTN events for each press of the Powermate device.

Input driver version is 1.0.1
Input device ID: bus 0x3 vendor 0x77d product 0x410 version 0x400
Input device name: "Griffin PowerMate"
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
    Event code 256 (BTN_0)
  Event type 2 (EV_REL)
    Event code 7 (REL_DIAL)
  Event type 4 (EV_MSC)
    Event code 1 (MSC_PULSELED)
Properties:
Testing ... (interrupt to exit)
Event: time 1685816662.086666, type 2 (EV_REL), code 7 (REL_DIAL), value -1
Event: time 1685816662.086666, -------------- SYN_REPORT ------------
Event: time 1685816662.318638, type 2 (EV_REL), code 7 (REL_DIAL), value -1
Event: time 1685816662.318638, -------------- SYN_REPORT ------------
Event: time 1685816662.574615, type 2 (EV_REL), code 7 (REL_DIAL), value -1
Event: time 1685816662.574615, -------------- SYN_REPORT ------------
Event: time 1685816663.670461, type 2 (EV_REL), code 7 (REL_DIAL), value 1
Event: time 1685816663.670461, -------------- SYN_REPORT ------------
Event: time 1685816664.030421, type 2 (EV_REL), code 7 (REL_DIAL), value 1
Event: time 1685816664.030421, -------------- SYN_REPORT ------------
Event: time 1685816664.334389, type 2 (EV_REL), code 7 (REL_DIAL), value 1
Event: time 1685816664.334389, -------------- SYN_REPORT ------------
Event: time 1685816665.334255, type 1 (EV_KEY), code 256 (BTN_0), value 1
Event: time 1685816665.334255, -------------- SYN_REPORT ------------
Event: time 1685816665.558230, type 1 (EV_KEY), code 256 (BTN_0), value 0
Event: time 1685816665.558230, -------------- SYN_REPORT ------------
Event: time 1685816666.030161, type 1 (EV_KEY), code 256 (BTN_0), value 1
Event: time 1685816666.030161, -------------- SYN_REPORT ------------
Event: time 1685816666.182151, type 1 (EV_KEY), code 256 (BTN_0), value 0
Event: time 1685816666.182151, -------------- SYN_REPORT ------------

At this point you’re ready to stop evtest (CTRL-C) and then create the following little BASH shell script that Node Red will run to collect the O/P from the Powermate USB device.

#!/bin/bash

###############################################
# Griffin Technology Powermate control script #
# for Node Red.                               #
#                                             #
# 04/06/23 - M0AWS - v0.1                     #
#                                             #
###############################################

VAL="1"
echo "STEP-1Hz"

/usr/bin/evtest /dev/input/powermate | while read LINE 
do
   case $LINE in

      *"(REL_DIAL), value 1") echo "$VAL"
           ;;

      *"(REL_DIAL), value -1") echo "-$VAL"
           ;;

      *"(BTN_0), value 1") case $VAL in

                              "1") VAL="10"
                                   echo "STEP-10Hz"
                                      ;;

                             "10") VAL="100"
                                   echo "STEP-100Hz"
                                      ;;

                             "100") VAL="1000"
                                    echo "STEP-1Khz"
                                       ;;

                             "1000") VAL="10000"
                                     echo "STEP-10Khz"
                                         ;;

                             "10000") VAL="1"
                                       echo "STEP-1Hz"
                                          ;;
                              esac
                                 ;;
        esac
done

Once the BASH script is copied and pasted into a file called powermate.sh you need to make it executable by using the following command.

chmod 700 ./powermate.sh

If you now run the shell script in a terminal you’ll see a similar output to that shown below from the device when used.

./powermate.sh 
STEP-1Hz
-1
-1
-1
1
1
1
STEP-10Hz
10
10
10
-10
-10
-10
STEP-100Hz
100
-100
-100
STEP-1Khz
1000
STEP-10Khz
STEP-1Hz
1
1
STEP-10Hz

As you can see above the shell script outputs a positive or negative number for VFO tuning and changes the VFO step size each time the Powermate is depressed.

Getting this output from the BASH shell script into Node Red is really simple to achieve using just 3 or 4 nodes.

In the Node Red development UI create the following nodes.

Griffin Powermate Node Red Nodes
Griffin Powermate Node Red Nodes

The first node in the flow is a simple inject node, here I called it trigger. This sends a timestamp into the next node in the flow at startup to set the flow running.

The Griffin Powermate node is a simple exec node that runs the script we created above.

M0AWS Powermate exec node
M0AWS Powermate exec node

Configure the node as shown above and connect it to the inject node that’s used as a trigger. Note: Change “user” in the Command field shown above to that of your username on your Linux PC)

Once done create the third node in the flow, a simple switch node and configure as shown below.

Switch Node for Powermate
Switch Node for Powermate

The switch node has two outputs, the top one is a text output that is fed into a text field to show the current step size of the Powermate device and the lower output is the numeric output that must be fed into your VFO control flow so that the VFO value is incremented/decremented by the amount output by the Powermate device.

I’ve found the Griffin Technology Powermate USB device works extremely well with Node Red and GQRX that I use for controlling the FCD SDR radio and it’s now part of my QO-100 ground station build.

M0AWS QO-100 Dashboard with Powermate Step Display at bottom
M0AWS QO-100 Dashboard with Powermate Step Display at bottom

As shown above you can see the Powermate Step size at the bottom of the dashboard, this text changes each time the Powermate device is depressed and will set a step size of 1Hz, 10Hz, 100Hz, 1Khz, 10Khz in a round-robin fashion.

The next stage of the build is the 2.4Ghz transmit path. I now have all the necessary hardware and so this part of the build can finally commence.

More soon …

QO-100 Satellite Node Red Dashboard

Whilst I’ve been waiting for the weather to improve so that I can get my QO-100 dish antenna up I’ve been working on my QO-100 Node Red dashboard.

The idea of the dash board is to bring together the operating of the receiver and transmitter into one control centre so that the two separate devices are able to communicate and behave as if they were actually one device, like a transceiver rather than being individual components.

Ideally I would like to have the transmitter and receiver talking to each other such that when the VFO on the transmitter is incremented/decremented the receiver VFO also moves by the same amount.

By doing this the receiver VFO should always be in the right place on the 10Ghz band to hear my 2.4Ghz uplink signal and of course, any station coming back to my CQ calls.

So far I’ve only been working on the receive part of the Node Red flow, it’s certainly been a lot of fun getting it put together.

I control my Funcube Dongle Pro+ (FCD) using GQRX SDR on my Kubuntu PC. This software is working extremely well with the FCD and I’m happy with the level of functionality it offers.

GQRX SDR has the ability built in to control the SDR via remote TCP connection using RIGCTL protocol. Currently there isn’t a RIGCTL node available for Node Red so I have written a number of Javascript function nodes that provide the appropriate functionality in conjunction with a standard Node Red TCP node. This is working extremely well on the local LAN in the radio room and is proving to be very stable and responsive.

M0AWS QO-100 Node Red Flow – Receive Section

The flow for the receive section of the dashboard looks fairly complicated but, in reality it’s really not too difficult to get to grips with. The receive flow provides the facility to switch bands, switch modes, change receiver filter band width, display a realtime signal strength meter, receive +/- clarifier in 10/100/1000Hz increments and put the receiver into QO-100 mode where the SDR VFO is tuned to 739.550Mhz whilst the dashboard VFO shows the QO-100 downlink frequency in the 10Ghz band. This is all working very well and I’m happy with the initial result.

M0AWS QO-100 Receive Dashboard in QO-100 mode

I now need to start work on the transmit side of the QO-100 dashboard and get communications between my IC-705 transceiver and the FCD SDR working via Node Red. This could be a little more challenging as it will involve communicating with the IC-705 via WFView over wifi.

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 …

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…

M0AWS Private Search now online!

After writing an article on how to “Build your own Search Engine” I thought it would be great to share the facility of being able to search the internet without being profiled, adverts constantly being rammed in your face or having your data sold to 3rd parties without your knowledge.

To make this happen I organised a dedicated SSL Certificate for the search engine, set up the service to use HTTPS for end-to-end encryption and configured the system for public access to the internet.

The system doesn’t log any search information at all, you can search for whatever you want safe in the knowledge that the system has no record of what you are looking for. Every search made uses a new unique ID and so you cannot be traced through browser information or any other information such as your IP Address, it’s about as private as you can get these days!

https://search.m0aws.co.uk/ is now live and available for everyone to use day and night from anywhere in the world.

It’s also accessible via the “Private Search” menu option at the top of the website.

This has been a fun project to build and I hope it is of use to many of my regular readers.

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 …

How to make a webpage from your WSJT-X log file

Map showing all M0AWS FT4/8 contacts

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.

Screen grab from my M0AWS WSJT-X Log web page

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 …

adi2html v0.6 release

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!

adi2html v0.5 release

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!