CommandLine – M0AWS Amateur Radio

25 June 20261 July 2026

Node-Red Control Dashboard for AllStarLink 3

I’ve recently built a new AllStarLink (ASL) node for my MB7IBW gateway that I have recently brought up on air on the 2m band.

AllStarLink 3 has a lot of changes in it when compared to the previous version and this of course impacts my Node-Red Control Dashboard that I’ve been using to manage my first ASL node for well over a year now.

To build the node I used the RaspberryPi imager and added the AllStarlink 3 image as detailed on the allstarlink.org website.

Installing the system this way makes it pretty easy compared to previous installs but, it comes with some quirks which cause issues with Node-Red.

From the outset the plan has always been to have AllStartLink 3 and Node-Red running on the same Pi4 to keep it totally self contained. This was easy enough to achieve and works without issue.

Node-Red Control Dashboard for AllStarLink 3

Installing Node-Red onto a Pi4 is really easy and is fully documented on the Node-Red Website.

Once the AllStarLink 3 operating system was installed on my SD card, booted and operational I installed Node-Red. I soon realised that there were a few things I had to do before loading the Node-Red flow.

AllStarLink 3 no longer logs connect and disconnect messages in the connectlog like it did in AllStarLink 2. To get logging working again I had to create two new BASH scripts as detailed below and put them into /etc/asterisk/myscripts.

For the connect information I created the BASH script as detailed below.

#!/bin/bash

# /etc/asterisk/myscripts/connectlog.sh

echo $1 Connected $2  on $(date +"%T") - $(date +"%m-%d-%Y")  >> /var/log/asterisk/connectlog

For the disconnect information I created the 2nd script detailed below.

#!/bin/bash

# /etc/asterisk/myscripts/disconnectlog.sh

echo $1 Disconnected $2  on $(date +"%T") - $(date +"%m-%d-%Y")  >> /var/log/asterisk/connectlog

Once these scripts were created I had to change the ownership and privileges as detailed below.

cd /etc/asterisk/myscripts
chown asterisk:asterisk ./*
chmod 750 ./*

I also had to change ownership/privileges of /etc/asterisk/myscripts.

cd /etc/asterisk
chown asterisk:asterisk ./myscripts
chmod 755 ./myscripts

Once the two scripts were in place I had to alter the asterisk config so that it called the scripts as part of the connect/disconnect process.

I found the connpgm and discpgm entries in /etc/asterisk/rpt.conf and changed them as shown below.

connpgm = /etc/asterisk/myscripts/connectlog.sh

discpgm = /etc/asterisk/myscripts/disconnectlog.sh

Next I disabled the temporary filesystems that are used by default for the apache and asterisk logging as it’s useful to keep the apache logs for debugging and I needed the asterisk logs for the Node-Red dashboard.

Disabling the temporary file system is very easy to do, just edit the /etc/fstab and comment out the two lines as shown below.

# Comment out the next line for persistent Apache logs
#tmpfs  /var/log/apache2        tmpfs   defaults,noatime,nosuid,nodev,noexec,mode=0775,size=32M 0 0

# Comment out the next line for persistent Asterisk logs
#tmpfs  /var/log/asterisk       tmpfs   defaults,noatime,nosuid,nodev,noexec,mode=0775,size=32M,uid=102,gid=106 0 0 

# Note: These lines are wrapped, should be on 1 line in the /etc/fstab

Once the entries in the /etc/fstab were commented out I rebooted the Pi4 to get persistent filesystems.

The final thing that had to be done was to allow user repeater to use sudo without a password so that it could be used to perform reboot/shutdown/process restart as user root from within the dashboard.

# /etc/sudoers

# Allow repeater sudo without password
repeater ALL=(ALL) NOPASSWD: ALL

Once this was all done I imported the Node-Red flow, configured the SSH nodes with login credentials for the Pi4 (important to use the user repeater for SSH), clicked deploy and the dashboard was ready for use.

Node Red AllStarLink3 Control Dashboard Flow

I’ve been using the dashboard for a few weeks now and it’s running perfectly, without error.

If you want to build your own Node-Red Control Dashboard for your AllStarLink 3 node then, just download the flow using the button below and import it into your flow editor.

M0AWS ASL3 Control Dashboard Download

More soon …

30 May 20263 June 2026

Node-Red Dashboard for AllStarLink 3 Nodes

I’ve spent some time this afternoon modifying my Node-Red Dashboard for controlling AllStarLink nodes to work with the new AllStarLink version 3.

My original AllStarLink Control Dashboard was designed to work with AllStarLink 2 which I have running on an old RaspberryPi 3b on the 70cm band. The dashboard has worked reliably ever since deployment and is in use daily.

With the release of AllStarLink 3 and all the changes that it entails I’ve had to make a few changes to the dashboard flows in order to make it compatible with AllStarLink 3 nodes.

This entails not only flow changes but also the addition of two new bash scripts that are called by Asterisk to log connect and disconnect messages as they are not logged by default any more. (Seems a bit of a step backwards)

Node-Red AllStarLink Control Dashboard v3.0 for ASL3

The changes also entail disabling the temporary filesystems used by default in the new ASL3 build so that log files etc become persistent.

I’ll spend some time using the new dashboard to ensure it’s working correctly and then will release it into the wild for all those that are brave enough to move over to AllStarLink 3.

More soon …

2 May 20262 May 2026

Bring your old handheld to life with an AIOC

I’m sure there are many radio amateurs around the world today who have an old handheld radio sat on the shelf that works perfectly but, has been replaced by a new, shiny, all singing, all dancing model that gets used on a daily basis. I for one have fallen into this trap with the recent purchase of a very nice Wouxun KG-UV9K full duplex 2m and 70cm handheld.

On my shelf there is a cheap Retevis RT85 that gave sterling service for a number of years and even today is ready to continue that service, if only I had a need?

Well now I do!

Currently I have an AllStarLink node running on a RaspberryPi 3b connected to a SHARI device that operates on the 70cm band. This node works great and gives me the ability to chat with people all over the world from my trusty handheld. It does of course also give me access to the weekly Matrix AllStarLink Net that happens on our Matrix node ( 642332 ) every Thursday evening at 20:00 UK time, a great way of bringing the Matrix HAM Radio community together regardless of propagation.

For some time I’ve been wanting to bring another AllStarLink node online so that I can have a connection to HUBNET/FreeNet whilst keeping my current node connected to the Matrix node for our regular daily chats. Since my new Wouxun handheld is a full duplex unit it makes sense to bring a new node up on the 2m band as I can then monitor both at the same time easily. I do have a spare SHARI node however, it’s a UHF only unit and I don’t want another node on the 70cm band. This is where the old Retevis RT85 comes in to play.

The All In One Cable ( AIOC ) board is a very neat little CM108 compatible sound card and serial interface that is sold by Steve, KM9G of YouTube fame ( Temporarily Offline ) that plugs into any handheld radio that has the now pretty much standard Kenwood ‘K’ type mic connector.

The AIOC board really is tiny but, beautifully put together. The four large solder pads on the top and more on the underside are positioned such that the TRS plug solder lugs line up perfectly for soldering. Attempting to do this by hand would be impossible as it’s critical that the spacing between the two connectors matches that of the spacing of the sockets on the radio.

Searching online I found a very handy soldering jig on Github that enables you to hold both the TRS connectors and AIOC board in the perfect position for soldering.

Downloading the .STL file I quickly printed off a solder jig on my Bambu Lab A1 Combo 3D printer and fitted the components into place ready for soldering.

Fitting TRS connectors into the AIOC solder jig

Fitting AIOC board into the solder jig. — Fitting TRS connectors into the AIOC solder jig

Everything fitted rather snugly into the jig and I soon had the board and connectors soldered together. Test fitting to my Retevis RT85 I found the TRS plugs lined up perfectly and it slid into the sockets with ease.

I then thought about designing a case for the AIOC board so that the bare circuit was nicely protected but, quickly searched online and found that NA6D has already designed a case and made the .STL available publicly for download on Printable.com. I quickly grabbed a copy of the file and punted it off to my 3D printer to get to work on.

Once the print was complete I fitted the AIOC board and snapped it together ready for testing.

Fitting the AIOC into the 3D printed case.

AIOC case with 2 x TRS connectors in place. — Fitting the AIOC into the 3D printed case.

Now that the AIOC was production ready I moved on to getting the latest version of AllStarLink onto my RaspberryPi 4 that I had taken out of my RadioBerry based shortwave receiver that I am going to upgrade to a Hermes Lite 2 in a later project. The RaspberryPi 4 is perfect for AllStarLink 3, a 64bit app and operating system.

Using the RaspberryPi Imager I pulled the image down onto an SD card and slipped it into my Pi4. ( Instructions on how to do this are on the AllStarLink website here )

Booting the Pi4 for the first time I found that it went through a number of reboot and configuration cycles before it was ready for use.

Once ready I went through all the normal configuration of the Pi4 namely, static IP assignment, timezone config, security, port forwarding etc etc.

Having configured an AllStarLink node for myself and only just a few days ago for another HAM I was pretty familiar with the setup. Wanting to make sure there were no “gotcha’s” I also watched a couple of KM9G’s videos on Youtube to make sure I wasn’t missing anything.

Using the asl-menu command line app as user root I set about configuring Asterisk to work with the AIOC board. Much to my frustration I could not get Asterisk to recognise the AIOC board as an available sound device. I checked and double checked all the settings ensuring that I had selected “AIOC” in the available devices menu but found that Asterisk constantly errored saying it could not find the selected audio device. This went on for a whole day without success and so, I decided to put it to one side and come back to it later, a method I found that often worked.

A couple of days later I revisited the problem and had decided to take a different approach. Rather than continue going through the asl-menu app I decided to drop down to a lower level and go through the asterisk config files in the /etc/asterisk directory.

It wasn’t long before I found a file called res_usbradio.conf. Inside this file was the config for the AIOC board however, it was all commented out which meant it was disabled.

I’m guessing here but, I imagine this is what should get enabled when selecting AIOC in the available devices menu in the asl-menu command line app but, for some reason it doesn’t happen.

[general]
;usb_devices = 1209:7388    ;comma delimited list of usb
                            ;descriptors to allow.
                            ;format vvvv:pppp in hexadecimal
                            ;vvvv=vendor id, pppp=product id
                            ;
                            ;1209:7388 = AIOC (all in one cable)

Above is the disabled configuration which is easily edited to enable the AIOC device as shown below.

[general]
usb_devices = 1209:7388    ;comma delimited list of usb
                            ;descriptors to allow.
                            ;format vvvv:pppp in hexadecimal
                            ;vvvv=vendor id, pppp=product id
                            ;
                            1209:7388 = AIOC (all in one cable)

Once the updated file had been saved and I restarted Asterisk using systemctl the AIOC burst into life and Asterisk recognised it immediately. The Retevis RT85 switched between TX and RX and I was ready to check out the audio.

Setting the volume levels for both RX and TX via the command line tuning app I connected the node to my already existing node. Sure enough the two nodes connected without error and I was able to send and receive audio between them via the AllStarLink net.

Connecting the new node to the parrot I checked the audio levels to ensure it sounded ok and then connected it to the Matrix node where I had a brief chat with Ben, M8TKK.

All that is left to do now is to 3D print a case for the Pi4 so that it isn’t left naked and at risk of being shorted out on conductive surfaces and it’ll be ready for service.

I also plan to build another AllStarLink node using a 4m band handheld and another AIOC board and then will apply for MB7Ixx callsigns for the two new nodes. This will hopefully help to bring some life to the 2m/4m bands locally and introduce HAM’s both to the weekly Matrix Net and HUBNet/FreeStar via AllStarLink.

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 …

18 October 202523 October 2025

RaspberryPi OS 13 Networking tidy up & broken lm-sensors

Since RaspberryPi are now forcing users of its SBC to use RaspberryPi OS 13 (via the RaspberryPi Imager tool) instead of the reliably stable Debian 11 or 12 several issues have come to light.

Firstly if like me you run most of the your Pi4/5 SBCs headless/lights out you’ll notice that networking is now ridiculously managed via Network Manager and Netplan.

This is a ridiculous method of managing such a simple device, it’s over complicated, messy and ill thought out. Yet another classic example of change for the sake of change and not to actually improve things.

This combination of Network Manager (often referred to as Network Mangler for good reason) and Netplan is fraught with bugs. Try setting a second IP address on an interface and you’ll find it doesn’t work. nmtui will show the ip address as being configured however, netplan never actually puts the config into play.

Having to use nmtui on the command line to manage ethernet interfaces is also ridiculous. Its badly laid out menu system takes an age to get through to do the simplest of config changes. What’s wrong with just editing the /etc/network/interfaces file?

After much frustration trying to configure the ethernet interface on my headless Pi5 I decided to get rid of this hideous method of managing ethernet interfaces and put it back to using the simple interfaces file.

I’ve documented the steps just in case anyone else wants to do the same.

Step 1: Make sure the traditional networking stack is installed:

sudo apt install ifupdown

Step 2 – Disable NetworkManager:

sudo systemctl stop NetworkManager.service
sudo systemctl disable NetworkManager.service
sudo systemctl mask NetworkManager.service

(Optional but tidy: )

sudo apt purge network-manager

Step 3 – Disable Netplan

sudo apt purge netplan.io
sudo rm -f /etc/netplan/*.yaml

Also ensure /lib/systemd/systemd-networkd is disabled, since Netplan can trigger it:

sudo systemctl disable systemd-networkd
sudo systemctl mask systemd-networkd

Step 4 – Create your `/etc/network/interfaces` file

# Example /etc/network/interfaces for Ethernet (eth0) with static IP:
#
# Loopback
auto lo
iface lo inet loopback

# Ethernet
auto eth0
iface eth0 inet static
    address 192.168.1.10
    netmask 255.255.255.0
    gateway 192.168.1.1
    dns-nameservers 1.1.1.1 8.8.8.8

Example for DHCP:

auto eth0
iface eth0 inet dhcp

If you use Wi-Fi:

auto wlan0
iface wlan0 inet dhcp
    wpa-ssid "YourSSID"
    wpa-psk "YourPassword"

Step 5 – Enable the traditional networking service

sudo systemctl enable networking.service
sudo systemctl restart networking.service

Then confirm:

ip a

You should see your interfaces up with the expected IP addresses, managed by ifupdown.

Step 6 – (Optionally) Clean residual files

Remove leftover NetworkManager/Netplan configs to avoid confusion:

sudo rm -rf /etc/NetworkManager
sudo rm -rf /etc/netplan

Verification

Check which subsystem is active:

systemctl is-active NetworkManager
systemctl is-active networking

Expected output:

inactive
active

The /etc/network/interfaces method works perfectly on Pi 5 and is lighter weight and ideal for embedded or headless servers.

If you later reinstall NetworkManager, it will override interfaces again unless you mark them as unmanaged in /etc/NetworkManager/NetworkManager.conf.

You can still use ifup / ifdown commands manually for control.

You now have your Pi running the classic, lightweight networking stack which is ideal if you use your Pi as a 24/7 server like I do.

Note: This method is still supported on RaspberryPi Debian 13 but, it’s no longer the default.

As a final note, if you want to add a second IP Address to your Ethernet interface it’s extremely simple to define in the /etc/network/interfaces file. I’ve created an example of how to do this below for reference.

# Loopback
auto lo
iface lo inet loopback

#
# Primary interface - static IP
#
auto eth0
iface eth0 inet static
    address 192.168.1.10
    netmask 255.255.255.0
    gateway 192.168.1.1
    dns-nameservers 1.1.1.1 8.8.8.8

#
# Secondary IP on same interface
#
auto eth0:1
iface eth0:1 inet static
    address 192.168.1.11
    netmask 255.255.255.0

Check both IP Addresses appear on the same interface:

ip a show eth0

For the example above you’ll see:

inet 192.168.1.10/24
inet 192.168.1.11/24

Finally, if like me you use lm-sensors to keep check on how hot your Pi is running you’ll find that the sensors command no longer works, it just throws a segmentation fault. This is a nuisance as I use this as part of my Node-Red Monitoring Dashboard.

A partial work around is to use the vcgencmd command as it can return the temperature of the system on a chip (SOC) device.

vcgencmd measure_temp

You can create an alias for this command in your ~/.profile file, I’ve named the alias ‘cputemp’ in this example:

alias cputemp="vcgencmd measure_temp"

Once you’ve saved your .profile file logout and back in again and you’ll now have a new command to use to get the CPU temp.

More soon …

3 July 20254 July 2025

Linux – Wandering USB devices

As I detailed in my QO-100 Satellite Ground Station Complete Build article I use a Griffin Powermate VFO knob to control the receive VFO frequency when in split mode or needing to RIT a DX station to get on frequency with them. Since building the ground station this setup has worked perfectly and without error however, for the last couple of days every time I start my Kubuntu Linux PC the USB VFO knob appears on a different USB event queue.

For the last two years the VFO knob has always appeared on /dev/input/event11 but, after connecting a Pluto+ SDR transceiver to the PC via USB the VFO knob now appears randomly on the /dev/input/events tree. This normally doesn’t cause any problems but, my Node-Red QO-100 Ground Station Control Dashboard expects the device to always be on /dev/input/event11.

Initially I tried to find a way to lock the USB VFO knob to /dev/input/event11 however, there doesn’t appear to be a way to do this as the event tree is built at boot time by udev.

Digging deeper into udev I discovered that it’s possible to create a udev rule that is read at boot time, that will search for the device and then create a symlink to it with the same name each time making the USB VFO Knob appear as if it’s always in the same place. This is exactly what I need so I set about writing the udev rule.

To find out what event the USB VFO knob is currently on I ran evtest on the Linux command-line and got the following output.

No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0:      Sleep Button
/dev/input/event1:      Power Button
/dev/input/event2:      Power Button
/dev/input/event3:      Video Bus
/dev/input/event4:      Telink Wireless Receiver Mouse
/dev/input/event5:      Telink Wireless Receiver Consumer Control
/dev/input/event6:      Telink Wireless Receiver System Control
/dev/input/event7:      Telink Wireless Receiver
/dev/input/event8:      Kensington USB/PS2 Orbit
/dev/input/event9:      PixArt USB Optical Mouse
/dev/input/event10:     USB PnP Audio Device
/dev/input/event11:     HDA Intel PCH Front Mic
/dev/input/event12:     HDA Intel PCH Rear Mic
/dev/input/event13:     HDA Intel PCH Line
/dev/input/event14:     HDA Intel PCH Line Out Front
/dev/input/event15:     HDA Intel PCH Line Out Surround
/dev/input/event16:     HDA Intel PCH Line Out CLFE
/dev/input/event17:     HDA Intel PCH Line Out Side
/dev/input/event18:     HDA Intel PCH Front Headphone
/dev/input/event19:     HDA Intel PCH HDMI/DP,pcm=3
/dev/input/event20:     HDA Intel PCH HDMI/DP,pcm=7
/dev/input/event21:     HDA Intel PCH HDMI/DP,pcm=8
/dev/input/event22:     HDA Intel PCH HDMI/DP,pcm=9
/dev/input/event23:     HDA Intel PCH HDMI/DP,pcm=10
/dev/input/event24:     Griffin PowerMate
/dev/input/event25:     Realtek RTL2832U reference design

This shows that currently the Griffin Powermate VFO knob is on event 24.

Having this information I now needed to use the udevadm command to obtain the Vendor and Product ID of the USB VFO knob.

udevadm info -a /dev/input/event24

This returns a lot of information about the USB device, more than I was expecting but, upon close inspection I found the Vendor and Product IDs.

ATTRS{id/product}=="0410"
ATTRS{id/vendor}=="077d"

Now that I have the Vendor and Product IDs I could start writing the udev rule.

Using the vi text editor on the command-line I created the necessary file in the
/etc/udev/rules.d/ directory.rule

vi /etc/udev/rules.d/90-powermate.rules

Into the file I wrote the following udev rule.

_{SUBSYSTEMS=="input", ATTRS{id/product}=="0410", ATTRS{id/vendor}=="077d", SYMLINK += "powermate"}

Note: That should all be on one line in the file not wrapped as shown above.

This one line rule sets the subsystem to input events, sets the Product and Vendor IDs to that of the Griffin Powermate USB VFO knob and then creates the symlink /dev/powermate

Once I’d completed the rule, I saved the file and exited the vi text editor.

Next I needed to use udevadm to get it to re-read the udev rules as if it were boot time and check that it created the symlink.

udevadm control -R

Once the udevadm command completed I used the ls command to see if the symlink had been created.

ls -la /dev/powermate
lrwxrwxrwx 1 root root 13 Jul  3 15:32 /dev/powermate -> input/event24

As shown above the symlink had been created and I could now enter
/dev/powermate into my Node-Red code so that it always finds the VFO knob regardless of what event number it appears on.

Just to make sure it worked correctly at boot time, I shutdown my Kubuntu linux PC and started it from a cold boot. Sure enough the
/dev/powermate symlink was created and pointed to the new event number in the /dev/input tree, problem solved!

I hope this information is useful to Linux users especially as it can be used for any USB input device.

It’s worth noting that you will need to be root user to run most of the commands or use sudo from your regular user account.

More soon ….

29 June 20257 February 2026

Rescuing a Bricked Pluto+

I’ve not written an article on the blog for a while now mainly because I’ve not had anything interesting to write about.

Today that changed, as I had a fun little project to dive into.

Steve, M0XVT sent me his Pluto+ SDR transceiver after his rather unsuccessful attempt at updating the firmware. Long story short, he somehow managed to brick the Pluto+ rendering it completely useless.

Not having a Pluto+ myself I’ve never actually played with one before and so this was new and exciting. I have, however played with Steve’s LibreSDR which is a later iteration of the Pluto+ and so, I had an idea of what I was getting into.

Firstly, how do you know when you have bricked your Pluto+?

Fortunately the Pluto+ device is actually quite clever and will inform you when it is bricked. The first sign you will notice is that you can no longer connect to the device using a USB connection to the data socket. The second sign is that when you take the top off the case you’ll notice that the blue LED is off and the green LED is on constantly. These are both classic signs that the device is bricked and needs rescuing

So, how do we rescue a bricked Pluto+?

Firstly, disconnect all cables and power to the device, it needs to be in a powered down state. Next remove the top of the case completely.

Unlike the LibreSDR the Pluto+ doesn’t boot from SD card so, we have to tell it that we want to boot it from an SD card. This is done by shorting the 3v3 and SD-H pins together using a jumper as shown in the photo below. (Black Jumper)

Pluto+ 3v3 and SD-H pins shorted together by black jumper

I believe that the v1 version of the Pluto+ has 1.8v instead of 3.3v, if this is the case on your device just short the SD-H pin to the 1v8 pin instead.

Next we need to make sure that the URST pin is connected to the MIO46 pin as shown by the green jumper in the image above. I put the jumper into this position as I am going to be using firmware that has ethernet support built in. If you want to load the official firmware then you will need to connect the URST pin to the MIO52 pin instead.

Next we need to load the new firmware onto an appropriate SD card. I’m using the F5OEO firmware that has ethernet support with DHCP built in. You can get the firmware from this Github link.

Whilst the firmware is downloading, insert your SD card into your PC and format it using a FAT32 filesystem.

Once the firmware has downloaded, unzip the file and save the contents of the zip file to a directory. Using your favourite file manager or in the case of a Linux junkie like me, the command line, copy the contents of the sdimg folder into the root of the SD card.

Note: That’s copy of the contents of the sdimg folder, not the folder itself.

Make sure to eject your SD card safely before removing it from your PC to ensure you don’t corrupt the contents.

Insert the SD card into the Pluto+ (it’s still powered down at this point with the top off).

Plug the USB A end of the USB cable into your PC but, do not plug the micro USB end into the Pluto+ just yet!

Now this is the tricky part, you need to hold down the DFU Button on the Pluto+ PCB (It’s behind the professor image on the PCB) whilst inserting the micro-USB plug into the DATA port of the Pluto+.

Once you see that the green and blue LED lights come on permanently, let go of the DFU Button and let the Pluto+ boot from the SD card. A short while afterwards the green LED should start flashing, this means your Pluto+ is alive again and has booted from the SD card.

At this point it’s important not to unplug the USB cable and not to remove the SD card from the device, we’re only half way there!

After a little more time the Pluto+ will appear in your file manager as a drive called PlutoSDR, navigate to this drive using your favourite file manager.

At the same time, open another window in your file manager and navigate to the folder where you saved the files from the Zip file. In this directory you will see the following two files:

boot.frm
pluto.frm

Copy these two files from the directory where you saved them into the root of the PlutoSDR drive.

Once this is complete, eject the PlutoSDR drive safely.

The green LED will now start blinking, don’t do anything, just leave everything as it is and the device will now create a new boot image on it’s own built in storage.

This process will take about 5mins so, go grab a cold beer, glass of wine or anything else that takes your fancy, sit back and relax.

Eventually the green LED will stop flashing, wait another minute or so for the process to fully complete.

If the PlutoSDR drive has reappeared in your file manager, safely remove the drive from your file manager and unplug the micro USB connector from the Pluto+ powering it down.

It’s now important to remove the 3v3 to SD-H jumper as we no longer need to boot from SD card.

You can now refit the top cover and the 4 screws and put the case back together. Connect an ethernet cable and micro USB cable to the DATA port and wait.

After about 10-15 seconds the green LED should flash and your Pluto+ is now no longer bricked and ready for use once more.

You can SSH to your Pluto+ using the normal Linux SSH command logging in as root with a password of analog.

If you have PiHPSDR installed and compiled with the SOAPYSDR library and modules (See my article on how to do this easily) you can now start it and connect to your Pluto+ device as normal.

Steve's rescued Pluto+ receiving a signal from my AllStarLink node in PiHPSDR — Steve’s rescued Pluto+ receiving a signal on the 70cm band

This same procedure can be used on Linux, Mac, Windows and RaspberryPi, it is not platform dependent.

If you want your Pluto+ to always boot from the SD card, you can leave the 3v3 pin connected to the SD-H pin permanently.

More soon ….

17 April 202517 April 2025

Updates to my install-pihpsdr.sh script

Over the last few weeks I’ve been working on my install-pihpsdr script to build a version of the DL1YCF PiHPSDR fork that will work with the Adalm Pluo, Pluto+ and LibreSDR transceivers.

Since I don’t own any of these devices, Steve M0XVT has loaned me his Adalm Pluto and LibreSDR devices to test with.

Initially neither of the devices would work with the PiHPSDR build that my script was creating. After some investigation I found this was due to the fact that the developer build script was only building the SOAPYSDR library, it wasn’t building the modules for each device type.

This was easily fixed by adding some extra code that would build the necessary SOAPYSDR modules so that the devices were discovered on the local LAN.

Since I had the devices to hand I took the opportunity to test the updated build script on a number of Linux Distro’s that I have to hand.

PiHPSDR running on Linuxmint 22.1 Cinnamon Edition using the LibreSDR transceiver

I tested the updated build script on Kubuntu 22.04LTS, Linuxmint 22.1 Cinnamon Edition and RaspberryPi 4/5 running the latest RaspberryPi OS 64bit version.

These all worked great with the transceivers and will now make a great platform for QO-100 stations that use either the Adalm Pluto, Pluto+ or LibreSDR devices.

Of course this build of PiHPSDR will also work with the Hermes Lite 2 and RadioBerry devices that I use most of the time in my own radio shack.

The updated PiHPSDR install script can be downloaded from my original blog article on the subject that is located here: https://m0aws .co.uk/?p=3686

The updated build script will most likely work on most Debian based Linux distro’s and build a working version of PiHPSDR. If you find a distro where you have problems please email me and let me know the details and I’ll happily look at the issue and try to resolve it.

Thanks to Steve for the loan of his precious SDR transceivers, I had a lot of fun with them!

More soon …

14 December 202428 February 2025

Building a new Desktop Environment for the RaspberryPi 5

Regular readers of my blog will already know that I am a huge fan of the Linux operating system, it’s clearly evident in most of the content on this website.

I am also a very enthusiastic user of one of the first credit card sized computers that came to be, namely the RaspberryPi. I own all the iterations of this wonderful little computer from the very first version to the latest and greatest, RaspberryPi 5.

This little computer has done more for computing in education than Microsoft and Apple will ever achieve and it’s done it at an incredibly low price making it more accessible to schools, colleges and students than any other platform.

The RaspberryPi has what most consider to be the best support on the planet when it comes to single board computers (SBCs). From the dedicated team that build Raspberry Pi OS, to all the amazing projects and forums that are available, for free on the internet today.

The RaspberryPi computer really has revolutionised computing for the masses.

My RaspberryPi 5 that I am writing this article on — My RaspberryPi 5 that I am using to write this article.

Raspberry Pi OS really is very good. It’s based on the great Debian distro’ that many of us seasoned Linux users dearly love. It’s light weight, fast and meets the needs of everyone that is venturing into the exciting world of Linux and SBCs for the first time.

Overtime as we all become more experienced with Linux on the RaspberryPi we become more demanding and start to find the Raspberry Pi OS desktop environment lacking. Sure it can be enhanced by adding more and more to it however, it never quite reaches the point of satisfaction and we are always wishing for something more.

With the Pi-5, the latest iteration of this great credit card sized computer, users are now able to seriously think about building a more powerful desktop environment for their little berry flavoured computers.

On my desktop PCs dotted around the house I have used Kubuntu for decades. It’s a slick and powerful desktop environment that has met my needs for many years and I love it more than any other Linux desktop. Sadly Kubuntu isn’t easily available out the box for the RaspberryPi and so I decided that it was time to replicate it as closely as possible on my new, super powerful RaspberryPi 5.

When I ordered my RaspberryPi 5 from Pimoroni I added the NVMe base and 250GB M.2 SSD drive to the order. Up until now I’d always used SD cards however, they are slow and unreliable and so I decided that since the Pi-5 has PCIe it was time to take the step away from SD cards and start using SSD technology.

Getting the OS onto the SSD is a two stage affair. First you have to create a bootable SD card to boot the Pi-5 from and then use it via the RaspberryPi Imager to install the OS onto the SSD. It’s a bit long winded but, easy enough.

Since I’m a huge Kubuntu fan I decided my desktop of choice for my new Pi-5 was going to be KDE-Plasma. I had tried to install this desktop before on older model Pi’s however, it ran so slow that it was unusable. With the new Pi-5’s increased computing power and the speed of the SSD I was confident that this was now possible.

I started out installing the Lite version of Raspberry Pi OS on the SSD. This is a command line only version of Linux that doesn’t include any desktop environment, a nice clean slate to start from.

RaspberryPi Imager showing Pi OS Liite (64bit) — RaspberryPi Imager showing Pi OS Lite (64bit)

Once the Lite version of the OS was installed on the SSD I shutdown the Pi-5 and removed the SD card and then powered the Pi-5 back up again so that it booted from the SSD.

Upon booting I was presented with the simple Linux Login prompt. After entering my username and password as setup during OS install I landed at the Linux command prompt.

sudo su -

I used sudo to become root user as shown above and then set about building my new KDE based super computer. First I needed to update the operating system with all the latest patches and security fixes.

apt update && apt dist-upgrade

The update and upgrade process ran for a while but, it was soon complete.

reboot

I issued the reboot command and then logged back in again, I was now ready to start building the KDE desktop environment.

sudo su -
apt install kde-plasma-desktop gldriver-test

Becoming root again I type the command to install the KDE-Plasma desktop and the graphics-related config services. There’s a lot of packages to download and install so, I left it to do its thing.

A little while later all the packages were installed and ready to go. I now needed to tell the system to boot into the new graphical user interface instead of the command prompt using systemctl.

systemctl set-default graphical.target

Once this was done I needed to make a change to the display settings using the raspi-config program.

raspi-config

Selecting No.2 on the menu, Display Options and then D2 Screen Blanking, I disabled screen blanking so that I got the full 4K support for my KDE Desktop.

Once the system had been configured for a graphical user interface there was only one thing left to do and that was to shutdown the RaspberryPi.

shutdown -h now

The beautiful KDE-Plasma Desktop on RaspberryPi 5

Powering the Pi-5 back up again I was greeted by the standard KDE Plasma login screen and then, after logging in I was transported to the beautiful KDE desktop. I was now smiling like a Cheshire cat!

The KDE desktop is incredibly snappy on the Pi-5 with an SSD, app’s open instantly and run with minimum CPU exertion. It was now time to load the rest of the KDE application suite to complete the build. Popping open a terminal I hit the command line once more.

sudo su -
apt install kde-full vim yakuake vlc firefox rsyslog

This loads the full set of KDE applications adding just about everything you’ll ever need to the desktop environment. It’s about 1GB of packages and so depending on your internet speed it could take a while but, it’s well worth the wait.

Once complete you are ready to go with a fully functional, snappy, powerful desktop.

I’m extremely pleased with the performance of the Pi-5. KDE is super fast, snappy and responsive. With 8GB of RAM on tap the RaspberryPi has no problem with performance. The Pi-5 and KDE-Plasma really do make a great desktop computer at an incredible cheap price.

Looking for a new computer?

Add a cheap USB sound card and a pair of speakers and this little setup will meet the needs of 90% of the population with ease and go on to satisfy the more seasoned, demanding Linux user or programmer without breaking the bank.

More soon …

10 December 202413 May 2025

Using the DL1YCF version of PiHPSDR with the RadioBerry

(This information is also for the Hermes Lite 2, Adalm Pluto, Pluto+ and LibreSDR)

During my RadioBerry build I started out using the version of PiHPSDR that was created just for the RadioBerry. The problem with this is that it is hard coded for a very small screen making it hard to use on a big screen since the user cannot resize the window dynamically.

I decided to look for a forked version of the PiHPSDR software that had the ability to change the window size to suit all use cases. During my search I stumbled across the DL1YCF fork of the source code that has some enhancements, one of which is the ability to change the display size.

In no time at all I had the source code downloaded and compiled only to find that it didn’t work with the RadioBerry. After some investigation I found that this was due to the fact that the RadioBerry software has compiled into it code that is used to access the GPIO pins on the RaspberryPi so that it can communicate with the RadioBerry HAT. This is fine except that the DL1YCF version of PiHPSDR also has code in it to use the GPIO pins. This of course causes a conflict and the net result is that nothing works.

Reading through the source code and Makefile I found that all I needed to do was to compile a version of PiHPSDR without GPIO support. This would then remove the conflict and allow the RadioBerry software to operate correctly.

To this end I put together a download/compile/install script for the DL1YCF version of PiHPSDR that will work on a RaspberryPi with a RadioBerry HAT and give the ability to resize the window to fit any size screen.

The script also works on a Linux Desktop PC running Ubuntu/Kubuntu/Linuxmint/Debian operating systems. (It will most likely work on other distro’s too but, these are all I have to hand currently). You can of course also use this software with a Hermes Lite 2 transceiver.

DL1YCF PiHPSDR running on RaspberryPi 4 with RadioBerry HAT on a large monitor

To install this enhanced version of PiHPSDR on your RaspberryPi/Desktop PC with GPIO support disabled, download the installation script below, unzip it and run it in a terminal on your RaspberryPi/Desktop PC in your home directory. (/home/<your-username>).

The script will download the latest source code from the DL1YCF github, disable the GPIO code and then compile and install it to your computer. If installing on a RaspberryPi it will create an icon on the desktop for you to use to start the software.

If installing on a PC then you will need to create your own desktop icon as the one created only works on a RaspberryPi. You can of course just start the software from the command line in a terminal. (My preferred method).

If you have a RaspberryPi 5 then I highly recommend that you run this version of PiHPSDR on it as it has a lot more computing power and handles using dual receive with ease. It will run on a Pi4 but, you will load the CPU more as it’s not as powerful as the later model Pi5.

The script will ask if you want to compile in SOAPYSDR support so that PiHPSDR will work with RTL-SDR, Adalm-Pluto, Pluto+ and LibreSDR. Enter Y to compile in support or N if you don’t need it.

install-pihpsdr-v22-update Download

I hope this proves useful to all the RadioBerry, Hermes Lite 2 and Pluto users out there who want to use PiHPSDR on a big screen.

More soon …

Step 1: Make sure the traditional networking stack is installed:

Step 2 – Disable NetworkManager:

Step 3 – Disable Netplan

Step 4 – Create your /etc/network/interfaces file

Step 5 – Enable the traditional networking service

Step 6 – (Optionally) Clean residual files

(This information is also for the Hermes Lite 2, Adalm Pluto, Pluto+ and LibreSDR)

Step 4 – Create your `/etc/network/interfaces` file