ARM64 – M0AWS Amateur Radio

1 October 20264 October 2026

piHPSDR-Improved – Our First Release

piHPSDR-Improved Logo from The Three Amigos Development Team

For some time now Steve (M0XVT), Alan (G1SQB) and I have been working on a version of piHPSDR to use with our Hermes Lite 2, Anan 200D, Adalm Pluto, Pluto+ and LibreSDR transceivers. The biggest problem we’ve had is the constantly changing code on github that often would stop the software from working on one device or more each time we updated and then we’d have to spend hours finding the issue and fixing it.

Eventually we got tired of this and decided to build our own stable version that doesn’t get anything from github and is made up of all the parts necessary to create a version that just works on the devices that we use on a daily basis.

Using piHPSDR on the QO-100 satellite and the HF bands across a number of very different types of hardware is a challenge in itself, especially when the devices use different protocols and only certain library sets work with certain firmware on some devices, the combinations get complicated to say the least.

To differentiate our build of piHPSDR from all the others available on the internet today we decided to call it piHPSDR-Improved.

So what is piHPSDR-Improved?

piHPSDR-Improved is a version of piHPSDR that has the fixes and enhancements in it that we’ve dreamt of having over the last couple of years. Some of the fixes are simple things like being able to detach the toolbar from the main window thus giving more space for the two panadapter/waterfall displays and have all the toolbar buttons on another screen in a floating toolbar. Other enhancements were more involved and addressed some of the most annoying issues like none of the settings for VFOB (RX2) were saved and so, every time you started the program you had to setup the RX2 all over again from scratch. These sound like simple fixes but, believe me, they’re not.

Another thing we wanted to do was make piHPSDR-Improved easy to install. Many Windows users transitioning from Windows to Linux often regret it the moment they have to use the Linux command line to install piHPSDR.

We’ve committed to having GUI installers for all the applications that we develop and release, regardless of how much extra work this entails.

It’s time installing software on Linux desktop PCs was as easy as it has been on Windows PCs for decades.

We’ve taken a modular approach to building piHPSDR-improved. Rather than putting everything into the one application, we’re going to be releasing add on modules that will bring new functionality over time. This way we can build on a structured, stable base keeping everything operational all of the time.

The first module we’re releasing is piSync and we’ve included it in the zip file that you’ll download to install piHPSDR-Improved.

piSync Logo

piSync adds functionality to piHPSDR-Improved that Windows Thetis users have had for a long time, namely the ability to use an online WebSDR along side their own SDR transceiver and have it track the frequency, band and mode automatically. This functionality has proven to be incredibly useful when you are struggling to hear a weak DX or QRP station.

With piSync you can now use an online WebSDR receiver closer to the DX station to aid getting that QSO in the log. It’s like having another receiver in your radio that is located anywhere in the world, for free!

We believe this is a first for the Linux platform and we’re really pleased to be able to share it with the Linux community.

We’ve had great fun with piSync during testing and we think you’re all going to find it extremely useful too.

We’re also planning on adding support for FLRig in the next version of piSync so that you’ll be able to use a WebSDR with any transceiver that is supported by FLRig.

Of course it goes without saying, all of our software is Opensource. When you download and install piHPSDR-Improved or any of the new modules you will get the full source code every time and be free to do whatever you like with it. Every module will also have it’s own GUI installer, no more command line, just double click and go.

Both piHPSDR-Improved and piSync have been tested on RaspberryPi 5/500+, Linuxmint Cinnamon, Kubuntu, Debian 12 (Bookworm) and Debian 13 (Trixie) so, we’re pretty confident it’ll work on most Debian/Ubuntu based Linux distro’s on Intel/AMD PCs and the current versions of the RaspberryPi SBCs.

piHPSDR-Improved, piSync and a WebSDR running on a pi 500+

Inside the zip file you’ll find a file called README.1st, do make sure you read this before installing any of the software as it contains some important information that’ll make installation as easy as possible.

To download both piHPSDR-Improved and piSync in an easy to use zip file, just click the Download button below.

piHPSDR-Improved-v2.42-and-piSync-v0.6 Download

We’ve got lots of ideas for new features, modules and bug fixes (Yes there are still some bugs in there!) which we will be releasing over time. Don’t expect this to happen overnight as Steve still works full time and Alan and I are both enjoying our retirement.

This is just another facet of our hobby and we don’t like to rush things. We do like to use our radios on air, pretty much daily and so we do this software development in between all the other fun things that Amateur Radio has to offer.

To be clear and open we do use Claude Code to help with development. I go through as much of the code as I can without spending days and days just reading code. I am retired after all and have spent enough of my life professionally writing and debugging both my own code and other people’s code. We do a lot of testing on a good number of Linux distros before we even consider releasing the software to the wider world and use it on air as part of the testing process, so we’ve done as much as we can to ensure we’ve not introduced new bugs to the software. Keep in mind we do this as part of our Amateur Radio hobby and so, it needs to be fun and enjoyable.

We hope you enjoy using the software and find it useful. If you’ve got ideas for new things you’d like to see in future versions then please feel free to contact any of us via our contact details on QRZ.

UPDATE: We’ve fixed a little bug in piSync and released an updated version. You can download it from this article.

More soon …

23 August 2026

Building MB7IBW 2m AllStarLink Internet Gateway

I’ve recently built another AllStarLink node to compliment my personal 70cm band SHARI node as I thought since I have a full duplex dual band handheld it would be great to have another node that I could connect to FreeStar or HUBNet at the same time as monitoring the Matrix node.

Rather than build another personal node I decided this time I would build a public node, obtain a callsign from the RSGB and make it available to the HAM’s locally on the 2m band.

This would make it possible for me to monitor both nodes at the same time using my Wouxun KG-UV9K full duplex dual band handheld whilst providing the local HAM community with access to the AllStarLink network.

Initially I thought I may be able to use my old Retevis RT85 handheld and AIOC board for the 2m node but, after a little testing it soon became apparent that it overheats during long overs (which are common on AllStarLink) and so, I needed to find another solution.

Chatting about this in the main Matrix HAM Radio room Steve, M0XVT sent me a message saying he had an old Key KM-4000 converted PMR radio that had been reprogrammed for the 2m band that he was looking to sell and that it might be ideal for the new node. Wasting no time, we came to an agreement and I was soon the proud owner of a converted PMR transceiver.

The KM4000 transceiver has a standard output of 15w, 10w more than I needed for the gateway and so I had to reduce the output. A quick search on the internet and I found the Thames Valley Repeater Group website that had all the information required to turn down the output.

I also had to reprogramme channel 1 to the frequency and CTCSS tone allocated to me by the RSGB so that in the event of a power outage when the radio came back on it automatically jumps to channel 1 which would be correctly setup for operation.

Unfortunately the software for programming the radio is only available for windows and so I had to build a virtual machine running windows 10 to be able to reprogramme the radio.

Once this was done I rewired the AIOC USB audio device to work with the KM4000 radio and built the AllStarLink node on a spare RaspberryPi 4.

For an antenna I made a simple end fed vertical dipole from some RG58 coax and mounted it 8m up on one of my Spiderpoles in the garden. Running a coax feed out to the antenna I did some tests into the Parrot to get the audio levels setup and checked that the DTMF codes were interpreted correctly and that the node switched connections without error.

MB7IBW Internet Gateway hardware at the M0AWS QTH

Once this was done I had a few test conversations with stations on the Matrix node and FreeStar to ensure all was fine and then set the gateway status to “Operational” on the RSGB website.

This worked fine for a while with myself and some local stations using the node regularly but, then the hot weather arrived and things started to overheat. The transceiver was getting incredibly hot in the 30c+ summer temperatures and the power supply was also running extremely hot and so I decided to add some cooling.

Cooling the PSU was simple, it has a perforated top panel to which I strapped a cooling fan. This worked great and brought the temperature of the PSU down considerably.

The radio wasn’t so easy to cool. It has a solid case cover top and bottom and so cooling wasn’t going to be a simple affair.

I decided to remove the covers and drill some holes into them to allow airflow through the unit and strapped a fan to the top cover to pull the hot air out. This worked well however, on both transmit and receive I now had a warbling sound on the audio that was caused by the motor of the fan when powered up.

I found that lifting the fan up away from the case of the radio the warbling audio disappeared and things were back to normal and so, I decided to design a cooling tube to fit to the top of the radio to allow full airflow from the fan but, with the fan raised up away from the radio to resolve the audio problem.

Jumping into my CAD software I quickly designed a cooling tower to fit on the top of the radio that would allow the fan to sit far enough away from the radio so as to not affect the audio whilst at the same time pulling the hot air out of the radio and drawing cooler air in through the bottom of the case.

I sent the design through to my Bambu Lab A1 Combo 3D printer and set the print job running.

The cooler worked great with the radio staying cool to the touch and no longer overheating and reducing O/P power.

It’s amazing how much dust and dirt is in the air from all the farming activities going on at the end of our garden and how much of it is sucked in by the cooling fan. Regular cleaning is a must!

The MB7IBW Internet Gateway has been on air since mid June 2026 and has worked well. It spends most of its time connected to either FreeStar or HUBNet with connections to the Matrix Node when we have our nets.

Details on Frequency, CTCSS etc can be found under the MB7IBW menu above.

Sadly the initial interest from local HAMs has now wained and I am mostly the only user of the gateway. I was hoping more people would use it and bring some life to the 2m band, I guess time will tell.

It’s been a fun project and was interesting to go through the callsign allocation process with the RSGB representative. It was much easier than I thought it would be.

I now have all the parts to build another Internet Gateway for the 4m band. Hopefully that may attract some more interest. It’s certainly worth a try!

More soon …

13 January 202613 January 2026

Using Node-Red to build interactive log maps

I’ve not been on the radio much over the last few weeks as I’ve had my head down other radio related rabbit holes.

One of the rabbit holes is a Node-Red project to make my online logs a little more interactive. For sometime now my logs have been displayed on my website as nicely formatted, searchable HTML pages however, they don’t really allow the viewer (myself included) to see the global coverage of all the contacts so, I decided to write a Node-Red flow that would do just that.

The flow itself isn’t too complicated and basically consists of reading in the individual ADIF formatted log files, processing the data and then sending the data in the correct format to the map node for display.

I’ve had to write a few functions to handle the processing of the ADIF formatted data but, these aren’t particularly complex and are fairly easy to understand even if like me, you’re not a Javascript programmer.

The flow is working perfectly however, I’m in the process of reworking the format generic payload function to reduce the amount of code and make it more efficient.

M0AWS SSB / CW / FreeDV Interactive Log World Map

The flow generates two maps, one for voice / CW /Satellite contacts and the other for WSJT-X FT4/8 contacts. Every pin on the map is colour coded by band with satellite contacts being denoted by a satellite icon.

Each pin / icon on the map is clickable and reveals the data of the QSO being displayed.

In the top right-hand corner of the map there is a drop down layer menu that allows the viewer to filter by band thus reducing the number of icons on the screen at any one time.

Seeing the data presented on a map really brings my logs alive. An example of this is that I had no idea I’d worked so many stations in India on the QO-100 Satellite.

The small icons in the pins show a microphone for SSB/FM/FreeDV contacts and a downwards pointing triangle in a box for CW contacts. Sadly I couldn’t find a Morse key icon in the collection available.

M0AWS filtered view of QO-100 Satellite contacts

I only use FT4/8 for testing new antenna designs however, it’s interesting to see the global coverage accomplished with this weak signal mode.

M0AWS WSJT-X FT4/8 Interactive Log World Map

Once I’ve finished rewriting the format generic payload function I will make the flow available for download here so that others can also create an interactive view of their radio logs.

If you want to have a look at the maps and try them out for yourself, they are available under the Logs menu above.

This Node-Red instance is running in a virtual machine (VM) on a 16GB RAM RaspberryPi 5 that is also running a number of other VMs at the same time so, it’s safe to say it’s not heavy on CPU and will run on the older Pi4 as well.

More soon …

1 December 20252 December 2025

Virtual Machines on RaspberryPi 5

RaspberryPi computers are now moving into the realm of being powerful enough to replace the traditional desktop PC. My most recent purchase, a RaspberryPi 500+ is proof of this as it has been my daily desktop PC since it’s arrival.

One of the things I use heavily are virtual machines. They’re great for developing, prototyping and running new services. With the ability to snapshot, rollback and backup in an instant, virtualisation helps to reduce the development and test time for many of the programs and services that I’m playing with.

With RaspberryPi computers now supporting 16GB of RAM and M.2 SSD drives there is no reason for not taking advantage of virtualisation.

To this end I decided to test running some virtualised loads on my new 500+ with the plan to deploy to 16GB Pi5’s with SSD drives in place of more expensive Intel based computers.

On my Intel based machines I use QEMU, KVM and Virt-Manager to manage the multitude of virtual machines (VMs) I have running here. Since this is a solid, high performance platform for running VMs I decided to take the same route on the 500+

Installing the necessary packages is extremely simple, just one simple apt command:

sudo apt install qemu-kvm libvirt-daemon-system libvirt-clients virt-manager bridge-utils

Note: If you’re using Debian 13 (Trixie) then the apt command to use is:

sudo apt install qemu-system-arm libvirt-daemon-system libvirt-clients virt-manager bridge-utils

The qemu-kvm package doesn’t exist in Debian 13 and so you have to replace it with the qemu-system-arm package.

To be able to create and run VMs you need to add yourself to the libvirt and libvirt-qemu groups.

sudo usermod -a -G libvirt your_username
sudo usermod -a -G libvirt-qemu your_username

Of course you can do it the old-fashioned way by editing the /etc/group file and adding your username to each group.

You’ll need to create a bridged ethernet device for the VMs to use to access the ethernet interface on your RaspberryPi.

If like me you don’t use NetworkManager the easiest way to create a bridge is to define it in your /etc/network/interfaces file.

For this example I am using an IP Address of 192.168.0.100, gateway on 192.168.0.1 with a netmask of 255.255.255.0 and DNS nameserver on 192.168.0.5.

The normal entry in the interfaces file would look like this:

# Main ethernet
auto eth0
iface eth0 inet static
address 192.168.0.100
netmask 255.255.255.0
gateway 192.168.0.1
dns-nameservers 192.168.0.5
dns-domain lan.local
dns-search lan.local
#
#

To create a bridge this entry needs to change to:

# Main ethernet
# Setup Bridge called br1 on eth0
allow-hotplug eth0
iface eth0 inet manual
auto br1
iface br1 inet static
address 192.168.0.100
network 192.168.0.0
netmask 255.255.255.0
broadcast 192.168.0.255
gateway 192.168.0.1
dns-nameservers 192.168.0.5
bridge_ports eth0
bridge_stp off
#
#

Once this is done reboot your RaspberryPi and check you have access to your local LAN and of course the internet. You will now also inherit the two new groups that you added yourself to above.

Note: If you are using NetworkManager open the network settings app and create a bridge on eth0. You can also use the nmtui copmmandline app if you prefer.

At this point you’re ready to create your first virtual machine.

It’s important to have an arm64 version of Linux in ISO format that you can use to install into your VM. My preferred distro is Debian and so I downloaded the Debian 13 Arm64 netinst ISO from the debian.org website.

From the main menu start “Virtual machine Manager” or on the commandline type:

virt-manager

Click the Create new VM button and then navigate to where you saved your ISO file and select it as the installation media.

Virtual Machine Manager - Local install media — Virtual Machine Manager – Local install media

Virtual Machine Manager - Select ISO file — Virtual Machine Manager – Select ISO file

Once you’ve chosen your ISO you’ll need to configure the actual VM. Start by setting the amount of RAM and number of virtual CPUs you want the VM to have.

Virtual Machine Manager - Configure RAM and CPU — Virtual Machine Manager – Configure RAM and CPU

Next set the size of the virtual disk that the VM will use.

Virtual Machine Manager - Create virtual disk — Virtual Machine Manager – Create virtual disk

Finally, give the VM a name and set its network device to br0 as created above. Click finish and your VM will boot.

Virtual Machine Manager - Name VM and select bridge interface — Virtual Machine Manager – Name VM and select bridge interface

Now it’s just a case of going through the standard Debian install process to build your Debian VM.

Virtual Machine Manager - Boot ISO — Virtual Machine Manager – Boot ISO

Virtual machine Manager - Running standard Debian install — Virtual machine Manager – Running standard Debian install

Once the installation is complete and the VM has rebooted you will have a functional Debian computer ready to use for whatever you like, just like a physical PC but, in virtual form. You’ll find that the VM runs as fast as the actual physical machine thanks to the kernel based virtualisation.

Virtual Machine Manager - Running VM — Virtual Machine Manager – Running VM

For more information on Virtual Machine Manager take a look at the Ubuntu Server documentation.

More soon …