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
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
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.


More soon …

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
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 …

Node-Red ADIF to Log Map Flow

Following on from my previous article on using Node-Red to build interactive log maps I’ve now reworked the flow to make it more efficient with less Javascript.

The original flow had a function that handled the issue of FT4 contacts being recorded in two different ways depending on which app you use for your FT4/8 operations.

<mode:4>MFSK <submode:3>FT4
or
<mode:8>MFSK FT4

The code I wrote to handle this wasn’t particularly elegant and so I decided to remove the code entirely and just use a simple change node.

M0AWS New node to handle FT4 more efficiently
M0AWS New node to handle FT4 more efficiently

This is the great thing about Node-Red, there’s always more than one way to do something.

With this fix in place and the old code stripped out of the format generic payload function, the new flow is much tidier and easier to comprehend.

M0AWs Updated ADI Log Map flow
M0AWs Updated ADI Log Map flow

With testing complete and the two maps now live on my website the flow is finally ready for release into the wild.

If you fancy presenting your ADIF logs in a more visual, interactive format then just download the flow below and import it into your Node-Red flow editor.


Don’t forget that you will need to change the path to the log files in the file read nodes to suit your setup and change the location data in the My QTH trigger to match your callsign and location. Other than this the flow should just work.

More soon …

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.

M0AWS Interactive Log Flow
M0AWS Interactive Log Flow

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
M0AWS SSB / CW / FreeDV Interactive Log World Map
M0AWS Interactive Log Map Layers Menu
M0AWS Interactive Log Map Layers Menu



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
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
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 …

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
QEMU Virtual Machine Manager
QEMU Virtual Machine 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 …

Coding a new version of adi2html in Python3

I’ve spent some considerable time of late coding a new version of adi2html that I use to convert my ADIF log files into online web pages for all my HAM Radio logs.

The old version that I wrote quite some time ago was written using BASH shell which was quick and easy at the time but, as the logs grew in size it got slower and slower to process the ever increasing number of log entries.

Now I’m retired I have the time to revisit these things and write better, more modern versions of my various programs that run silently in the background.

Writing the new version of adi2html in Python3
Writing the new version of adi2html in Python3

It’s taken a little over a week to put this code together, test and debug it, I don’t like to rush these things!

I’ve finally put v1.2 into production today.

The 585 lines of code produce a very nice, modern looking web page and can be used to convert any ADIF file into HTML. The code is extremely quick, taking less than a second to process almost 2500 log entries, a huge improvement over the old version of adi2html.

New look M0AWS Log web page
New look M0AWS Log web page

All of my logs are available here on my blog under the Logs menu above, feel free to have a look at them.

I now need to rewrite the log search functionality so that it uses the same format of presentation for the results.

More soon …