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.
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.
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.
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
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
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.
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!
For the last week or so I’ve been playing with a RadioBerry HAT for my RaspberryPi computer. The RadioBerry is a cut down version of the Hermes Lite 2 with just 20mW output power and separate TX and RX antenna ports. It’s a really neat little package that sits on top of a RaspberryPi4/5 and creates a neat little HF transceiver.
RadioBerry HAT
I initially started with the RadioBerry HAT on my Pi5 but, I soon realised that the software really doesn’t work well at all on the Pi5. I’m not 100% sure as to why but, for some reason it holds one core at 100% continuously. It seems that the RadioBerry software is single threaded. The end result is that on the Pi5 you cannot use a sample rate above 9600 before the IQ stream starts to stutter.
By contrast, installing the RadioBerry software onto a Pi4 it performs perfectly upto the maximum sample rate of 384000 without any stuttering. I’ll need to spend some time going through the source code to try and determine why it doesn’t work correctly on a Pi5.
Whilst going through the source I discovered that the developer has put some code in that collects data from the running computer and sends it to the developer’s website. Some of this data is then made public via his website, http://www.pa3gsb.nl/radioberry/api/read.php
One of the things displayed on the website is the Mac address of the RaspberryPi on which the RadioBerry is running. This is a security risk and should never be done!
The most annoying thing is that this is done without authorisation. The installation doesn’t state that it’s going to collect data every time you start your RaspberryPi computer nor does it offer the ability to opt out. It also doesn’t inform the user that it’s going to pass the data on to a third party. In some cases it even collects HAM Radio Callsign and location data and displays it on a public website, a clear breach of the UK/European Data Protection Law.
Finding spyware in open source software is really poor and something most open source developers would never consider doing.
To this end I have disabled the spyware in the version of the RadioBerry software that I am using and am making it available to everyone else to use via this blog.
So, to install the RadioBerry software you just need to download the installation script and run it in a terminal on your RaspberryPi computer.
The script will download the modified source code, compile it and install it on your RaspberryPi ready for you to use.
I encourage everyone that downloads the script and the source code to take a look at it and ensure you are happy with it. It’s important to know what you are running on your computer and what it does.
You can find the spyware code in the register.c file (It’s all commented out with “//” marks). The function now doesn’t pass any data at all to the public website.
I hope some of my readers who are experimenting with the RadioBerry transceiver find this useful.
I will soon be publishing an article on an enhanced version of PiHPSDR from DL1YCF to use with the the RadioBerry to complete the project.
Important Update:
There is an issue with the RadioBerry code that renders it useless if you use a kernel later than the version shown below:
Updating the O/S Kernel to any version later than the version shown above will stop the RadioBerry software from working. Recompiling of the code also fails due to the Kernel update and at the time of writing this cannot be fixed without a code rewrite by the original developer.
I also recommend that once you have built a working RadioBerry on a RaspberryPi 4 you should disable the automatic updates of the O/S to stop the system from failing in the future.
You can disable the automatic updates by entering the following commands into a terminal:
This is more of an aide memoire for myself more than anything but, may be useful to anyone who is using a SHARI powered AllStarLink node.
Out the box the SHARI build as documented here and here uses node numbers in announcements when connecting/disconnecting. The information in this article will change this so that the announcements use the node callsigns instead of node numbers.
As user repeater, login to the RaspberryPi that the SHARI is connected too via SSH and make the following changes:
1: Using your favourite command line text editor, edit /usr/sbin/write-node-callsigns and change SRCDIR to point to /var/www/html/allmon2
# 28/08/24 - M0AWS - Changed path to point to allmon2
##SRCDIR=/var/www/html/allmon
SRCDIR=/var/www/html/allmon2
2: Copy the astb.txt file into the necessary directory:
NOTE: The info in this article is out of date and does not work with the latest version of AllStarLink. The Debian O/S it is based on is no longer in support.
Over the last couple of days in-between doing other things I’ve been writing and testing a BASH shell script that will completely configure a fully working AllStarLink node.
M0AWS – Coding the BASH script for the automated AllStarLink installation
To use the script you must already have your RaspberryPi (preferably a Pi 3b) connected to your LAN with full internet access using the Raspbian based version of the AllStarLink software downloadable from here.
The specific version I use is:
asl-2.0.0-beta.6-kc1kcc-20210324-rpi-armhf
I have tested the BASH script using this specific version of O/S only.
Once your RaspberryPi 3b is up and running, has full internet access and is accessible on your local LAN, using SSH login in as the user ‘repeater‘ using the password ‘allstarlink‘.
It’s important you only use this login to configure the node as this is the user the script is expecting to be run by. You must login via SSH as the SHARI device needs to be connected to the RaspberryPi 3b and you won’t be able to connect a keyboard and mouse at the same time. (If you are using two USB cables for the SHARI device then you can use a keyboard and mouse along with a monitor attached to your RaspberryPi instead of using SSH).
Once logged in as user repeater run the following wget command to download the zipped install script:
You are now ready to build your AllStarLink node. Before you run the script make sure you have your node number and node secret to hand. These are obtained from the AllStarLink portal.
Once you’ve got all your node information you can run the script using the following command:
./install.sh
The script will now take you through the full process of updating the operating system as necessary, installing all the required packages and software. It will then reboot the RaspberryPi and you will need to login and run the script a second time using the command above.
On the second run the script will install some python specific software, ask you to enter your callsign, node number and node secret and will then configure your node. The last thing it does is configure the Allmon2 and Supermon Web Admin websites. During this process it will ask you to enter a password twice for the Admin user for the two websites, make sure you make a note of this password as you will need it to login and control your node.
Once the node is configured it will be rebooted and you will then be able to connect to your node using your favourite web browser and the user admin and the password you set above.
To access the Allmon2 web-admin system use the following URL:
For those of you who prefer Supermon you an use the following URL:
http://your-RaspberryPi-IP-Address/supermon
M0AWS – Supermon Web Admin view
I have also pre-populated the Favorites button with a list of nodes that I use often. You can easily change these entries by editing the favorites.ini file in the /var/www/html/supermon directory as user root.
M0AWS – Supermon pre-populated Favourites drop down list
When you first login to your node via your web browser you’ll notice that it says your node isn’t in the database. You can update the database by using the following URL in your web browser:
Please note: This build is now deprecated and will no longer work. Please use the new AllStarLink 3 build process as documented on the AllStarLink website.
We’ve recently added a new room to the Matrix HAM Radio Space for Digital Voice modes as this was an area of interest that didn’t really fit into any of the other rooms.
The new Digital Voice room has attracted a lot of attention from members, with a lot of the focus being on the AllStarLink system. Michael, DK1MI built an AllStarLink node in the cloud for us all to use for Matrix Nets and so I decided I had to get in on the fun.
Jumbospot SHARI SA818 Amateur Radio AllStarLink Radio Interface Front Panel ViewJumbospot SHARI SA818 Amateur Radio AllStarLink Radio Interface Rear ViewJumbospot SHARI SA818 Amateur Radio AllStarLink Radio Interface stripped down View
The two USB connectors on the SHARI device are position such that they plug into two of the available 4 USB ports on the RaspberryPi without the need for cables. This keeps the whole solution together in one neat package.
Before you start you will need to obtain a node number and secret (password) from the AllStarLink Portal. To get this you will need to provide proof to the AllStarLink administrators that you are a licensed Amateur Radio (HAM) operator. This is done by uploading a copy of the first page of your HAM licence to the website for the admin team to check. This can take 24hrs to be completed so make sure you get this all done before trying to build your node. You cannot build a node successfully without a node number and secret.
Of course you will also need a transceiver that can operate on the 438.800Mhz frequency or other frequency of your choice on the 2m or 70cm HAM band.
You will also need to open port 4569 on your internet router and setup port forwarding to the IP Address that you will be using on your RaspberryPi node. It’s important to use a static IP Address on your RaspberryPi.
There are quite a few different Linux based operating system (O/S) images that are available for the RaspberryPi devices that have been specifically tailored for the AllStarLink node and include all the necessary software and library packages out the box.
Once downloaded you need to burn the ISO image onto a suitable SD card for your RaspberryPi. I use BalenaEtcher as it’s extremely quick and reliable at burning ISO images to SD cards.
Of course if you are a hardline Linux command line junkie you can always use dd to create the SD card.
Once you’ve got your O/S onto your SD card, slot it into your RaspberryPi making sure your SHARI device is connected to the two USB ports and then power it up. Make sure you have a good PSU for the RaspberryPi as the two devices together draw around 3A of current during the transmit cycle. (I use a 3.6A PSU from Amazon).
The default login for the Raspbian O/S is shown below. Login via SSH and configure your RaspberryPi for your local network. It’s important to use a static IP Address configured either directly on the RaspberryPi or via DHCP in your router.
Next you need to change directory into the asterisk config file directory using the command shown below:
cd /etc/asterisk
In this directory you will find all the default config files that come as part of the distro. For this build we’re not going to use them and so we need to move them out of the way ready for a set of config files that have already been configured correctly.
Using the following commands create a new directory, move into that new directory and then move all the unwanted configuration files into it:
mkdir ORIGINAL-CONF-FILES
cd ./ORIGINAL-CONF-FILES
mv ../*.conf ./
ls -la
cd ../
You should now be back in the /etc/asterisk directory which will now be empty apart from the custom directory which we left in place.
You now need to copy the correctly configured configuration files into the /etc/asterisk directory. Start by downloading the zip file containing the new configuration files
Download removed as deprecated.
Once downloaded, copy the .zip file into the repeater users home directory (/home/repeater) using either scp on the Linux command line or if using Windows you can use the FileZilla Client in SFTP mode using the login details above.
Once you have the .zip file in the repeater user’s home directory you need to copy the file into the /etc/asterisk directory as user root:
Next as user root, change directory into the /etc/asterisk directory and unzip the .zip file:
cd /etc/asterisk
unzip ./AllStarLink-Config-v3.zip
Once the file is unzipped you will have a directory called AllStarLink-Config in the /etc/asterisk directory. You now need to cd into the directory, copy all the files out of it into the /etc/asterisk directory leaving a copy in the AllStarLink-Config directory for future reference:
cd /etc/asterisk/AllStarLink-Config
cp ./* /etc/asterisk
cd /etc/asterisk
You now need to move a couple of files into the repeater users home directory using the following commands:
The gpioBASH script and configuration details were supplied by Mark, G1INU in the Digital Voice room on the Matrix. It adds the COS light functionality to the setup. The COS light will now light every time the SA818 hears RF on the input.
The next thing you need to do is configure the SA818 radio device in the SHARI. The script I used was originally from https://wiki.fm-funknetz.de/doku.php?id=fm-funknetz:technik:shari-sa818 all I’ve done is change the entries to switch off CTCSS and change the frequency to 438.800Mhz. Configuring the SA818 is done by running the SA818-running.pyPython programme that you moved into the repeater user home directory. Making sure you are still user root, run the following commands:
cd /home/repeater
./SA818-running.py
At this point your SHARI SA818 device will be configured to operate on 438.800Mhz and CTCSS will be disabled.
If you want to change the frequency or enable and set a CTCSS tone to access the node you will need to edit the Python programme using your favourite text editor and change the entries accordingly. Once changed rerun the program as shown above and your SHARI will be reconfigured to your new settings.
Next you need to move the allmon.ini.php file into the correct directory so that it enables access to the Allstar Monitor web page on the device so that you can manage connecting/disconnecting nodes. Use the following commands as user root to achieve this:
The allmon.ini.php file needs to have your node name entered into it to work correctly. As user root, change directory and edit the file using your favourite editor.
cd /var/www/html/allmon2
Using your text editor, search for the line starting [XXXXX] and change the XXXXX to your node number. Save the change and exit the file.
At this point you are almost complete, all that is left to do is add your node number and node secret into the appropriate configuration files in the /etc/asterisk directory.
Since I am a Linux command line junkie I use vi to edit all the configuration files on the command line as user root, but you can use any editor of your choice.
cd /etc/asterisk
Start with the extensions.conf file. Search for the line starting with NODE = and delete the XXXXX entry and insert your node number. Save the file and exit it.
Next you need to edit the iax.conf file. This time search for the line starting with register= and change the XXXXX for your node number and the YYYYYYYYYYYY for your node secret. Be careful not to accidentally delete any other characters in the lines otherwise it will corrupt the configuration file.
In the same file search for the two lines that start with secret = and change the YYYYYYYYYYYY for your node secret. Once you have changed both of the secret entries, save and exit the file.
The final file to edit is the rpt.conf file. Once again open the file using your favourite editor and search for the line starting with XXXXX = radio@127.0.0.1:4569/XXXXX, change the XXXXX entries for your node number making sure not to delete any other characters next to the XXXXX entries.
Further down in the same file there is a line that starts with [XXXXX], once again change the XXXXX for your node number making sure to keep the square brackets at each end of the node number as you edit it.
Finally move down to the very bottom of the file and find the two lines that start with /home/repeater/gpio, once again change the XXXXX entries for your node number.
The final thing to change in the rpt.conf file is to replace my callsign with your own callsign so that the node identifies itself correctly. Scroll through the file until you find the two lines shown below, delete M0AWS and add your own callsign instead making sure you keep all the spaces between words as shown below.
idrecording = |i DE M0AWS
idtalkover = |i DE M0AWS
Once this is done, save and exit the file. At this point your node should be fully configured and will only require a reboot to get it working.
As user root, reboot your raspi using the reboot command.
reboot
Once your raspi comes back online, login using SSH as user repeater and then become root user using the sudo command detailed above.
You now need to create the admin user password for the Allstar Monitor web page on the device. This is done using the following commands as user root:
cd /var/www/html/allmon2
htpasswd -c .htpasswd admin
You will be asked to enter a password twice for the admin user. Make sure you make a note of this user/password as you will need it to login to the web page.
Finally check that the controlpanel.ini.php file is in the /var/www/html/allmon2 directory:
ls -la /var/www/html/allmon2/controlpanel.ini.php
If the file isn’t shown in the directory, enter the following commands to create the file in the correct place as user root and then exit the SSH session:
cd /var/www/html/allmon2
cp ./controlpanel.ini.txt ./controlpanel.ini.php
cd
exit
Once this is done your configuration is complete, logout from the terminal session by entering exit once more and your SSH session will terminate.
Using your favourite web browser enter the IP Address of your raspi into the URL bar as shown below:
http://<Your-Raspi-IP>/allmon2
Note: remove the <> from the URL once you have entered the required information.
Once this is done you should be presented with your node control panel as shown below.
First visit to the AllStar Monitor Web Page
Login using Admin and the password you set above and you are now ready to start using your node.
It’s a good idea to connect to node 55553 which is a parrot test node to check your audio levels. You can do this by entering the node into the field at the top left and pressing the connect button.
M0AWS AllStarLink Node 61928 connected to 55553 Parrot
Once connected, tune your radio to 438.800Mhz FM and transmit a test message using your callsign and test123, or something similar. The parrot will then play your recording back to you so that you can hear how you sound. It will also comment on your audio level as to whether it is OK or not.
You are now connected to AllStarLink network and have the world at your finger tips. Below is a small list of nodes in the UK, Australia and America to get you started chatting with other HAMs via your node.
57881 Matrix HAM Radio Space AllStarLink Node (Hosted by Dk1MI)
55553 ASL Parrot for testing
41522 M0HOY HUBNet Manchester, UK
60349 VK6CIA 439.275 Perth, Western Australia
51077 VK6SEG South West Hub B Albany WA
2167 M0JKT FreeSTAR UK HUB 2 freestar.network
53573 NWAG NW AllStar Group Lancashire, UK
27339 East Coast Hub Wilmington NC USA
M0AWS AllStarLink Node 61928 sitting on the equipment rack
Thanks to Michael, DK1MI for building and hosting the Matrix HAM Radio Space AllStarLink Node (57881) and getting us all started in the world of AllStarLink!
We hope to be having regular Matrix Net’s on the node soon for all Matrix members and visitors. We’ll organise days/times via the Digital Voice room.
Following on from my article about my QO-100 Satellite Ground Station Complete Build, this article goes into some detail on the Node-RED section of the build and how I put together my QO-100 Satellite Ground Station Dashboard web app.
The Node-RED project has grown organically as I used the QO-100 satellite over time. Initially this started out as a simple project to synchronise the transmit and receive VFO’s so that the SDR receiver always tracked the IC-705 transmitter.
Over time I added more and more functionality until the QO-100 Ground Station Dashboard became the beast it is today.
M0AWS QO-100 Ground Station Control Dashboard built using Node-RED.
Looking at the dashboard web app it looks relatively simple in that it reflects a lot of the functionality that the two radio devices already have in their own rights however, bringing this together is actually more complicated than it first appears.
Starting at the beginning I use FLRig to connect to the IC-705. The connection can be via USB or LAN/Wifi, it makes no difference. Node-RED gains CAT control of the IC-705 via XMLRPC on port 12345 to FLRig.
To control the SDR receiver I use GQRX SDR software and connect to it using RIGCTL on GQRX port 7356 from Node-RED. These two methods of connectivity work well and enables full control of the two radios.
M0AWS Node-RED QO-100 Ground Station Dashboard Flow as of 12/06/24
The complete flow above looks rather daunting initially however, breaking it down into its constituent parts makes it much easier to understand.
There are two sections to the flow, the GQRX control which is the more complex of the two flows and the comparatively simple IC-705 section of the flow. These two flows could be broken down further into smaller flows and spread across multiple projects using inter-flow links however, I found it much easier from a debug point of view to have the entire flow in one Node-RED project.
Breaking down the flow further the GQRX startup section (shown below) establishes communication with the GQRX SDR software via TCP/IP and gets the initial mode and filter settings from the SDR software. This information is then used to populate the dashboard web app.
M0AWS Node-RED QO-100 Ground Station Dashboard – GQRX Startup Flow
The startup triggers fire just once at initial startup of Node-RED so it’s important that the SDR device is plugged into the PC at boot time.
All the startup triggers feed information into the RIGCTL section of the GQRX flow. This section of the flow (shown below) passes all the commands onto the GQRX SDR software to control the SDR receiver.
M0AWS Node-RED QO-100 Ground Station Dashboard – GQRX RIGCTL Flow
The TCP RIGCTL -> GQRX node is a standard TCP Request node that is configured to talk to the GQRX software on the defined IP Address and Port as configured in the GQRX setup. The output from this node then goes into the Filter RIGCTL Response node that processes the corresponding reply from GQRX for each message sent to it. Errors are trapped in the green Debug node and can be used for debugging.
The receive S Meter is also driven from the the output of the Filter RIGCTL Response node and passed onto the S Meter function for formatting before being passed through to the actual gauge on the dashboard.
Continuing down the left hand side of the flow we move into the section where all the GQRX controls are defined.
M0AWS Node-RED QO-100 Ground Station Dashboard – GQRX Controls Flow
In this section we have the VFO step buttons that move the VFO up/down in steps of 10Hz to 10Khz. Each button press generates a value that is passed onto the Set DeltaFreq change node and then on to the Calc new VFO Freq function. From here the new VFO frequency is stored and passed onto the communications channel to send the new VFO frequency to the GQRX software.
The Mode and Filter nodes are simple drop down menus with predefined values that are used to change the mode and receive filter width of the SDR receiver.
Below are the HAM band selector buttons, each of these will use a similar process as detailed above to change the VFO frequency to a preset value on each of the HAM HF Bands.
The QO-100 button puts the transmit and receive VFO’s into synchro-mode so that the receive VFO follows the transmit VFO. It also sets the correct frequency in the 739Mhz band for the downlink from the LNB in GQRX SDR software and sets the IC-705 to the correct frequency in the 2m VHF HAM band to drive the 2.4Ghz up-converter.
The Split button allows the receive VFO to be moved away from the transmit VFO for split operation when in QO-100 mode. This allows for the receive VFO to be moved away so that you can RIT into slightly off frequency stations or to work split when working DXpedition stations.
The bottom two Memory buttons allow you to store the current receive frequency into a memory for later recall.
At the top right of this section of the flow there is a Display Band Plan Info function, this displays the band plan information for the QO-100 satellite in a small display field on the Dashboard as you tune across the transponder. Currently it only displays information for the satellite, at some point in the future I will add the necessary code to display band plan information for the HF bands too.
The final section of the GQRX flow (shown below) sets the initial button colours and starts the Powermate USB VFO knob flow. I’ve already written a detailed article on how this works here but, for completeness it is triggered a few seconds after startup (to allow the USB device to be found) and then starts the BASH script that is used to communicate with the USB device. The output of this is processed and passed back into the VFO control part of the flow so that the receive VFO can be manually altered when in split mode or in non-QO-100 mode.
M0AWS Node-RED QO-100 Ground Station Dashboard – Powermate VFO Flow
The bottom flows in the image above set some flow variables that are used throughout the flow and then calculates and sets the RIT value on the dashboard display.
The final section of the flow is the IC-705 control flow. This is a relatively simple flow that is used to both send and receive data to/from the IC-705, process it and pass it on to the other parts of the flow as required.
M0AWS Node-RED QO-100 Ground Station Dashboard – IC-705 Control Flow
The IC-705 flow is started via the timestamp trigger at the top left. This node is nothing more than a trigger that fires every 0.5 seconds so that the dashboard display is updated in near realtime. The flow is pretty self explanatory, in that it collects the current frequency, transmit power, SWR reading, PTT on/off status and S Meter reading each time it is triggered. This information is then processed and used to keep the dashboard display up to date and to provide VFO tracking information to the GQRX receive flow.
On the left are the buttons to change band on the IC-705 along with a button to tune to the VOLEMT on the 60m band. Once again there two memory buttons to save and recall the IC-705 VFO frequency.
The Startup PTT Colour trigger node sets the PTT button to green on startup. The PTT button changes to red during transmit and is controlled via the Toggle PTT function.
At the very bottom of the flow is the set transverter IF Freq function, this sets the IC-705 to a preselected frequency in the 2m HAM band when the dashboard is switched into QO-100 mode by pressing the QO-100 button.
On the right of the flow there is a standard file write node that writes the 2.4Ghz QO-100 uplink frequency each time it changes into a file that is used by my own logging software to add the uplink frequency into my log entries automatically. (Yes I wrote my own logging software!)
The RX Audio Mute Control filter node is used to reduce the receive volume during transmit when in QO-100 full duplex mode otherwise, the operator can get tongue tied hearing their own voice 250ms after they’ve spoken coming back from the satellite. This uses the pulse audio system found on the Linux platform. The audio is reduced to a level whereby it makes it much easier to talk but, you can still hear enough of your audio to ensure that you have a good, clean signal on the satellite.
As I said at the beginning of this article, this flow has grown organically over the last 12 months and has been a fun project to put together. I’ve had many people ask me how I have created the dashboard and whether they could do the same for their ground station. The simple answer is yes, you can use this flow with any kind of radio as long as it has the ability to be controlled via CAT/USB or TCP/IP using XMLRPC or RIGCTL.
To this end I include below an export of the complete flow that can be imported into your own Node-RED flow editor. You may need to make changes to it for it to work with your radio/SDR but, it shouldn’t take too much to complete. If like me you are using an IC-705 and any kind of SDR controlled by GQRX SDR software then it’s ready to go without any changes at all.
I’ve got a couple of old RaspberryPi computers on the shelf in the shack and so decided it was time for me to put one of them to good use. The first model on the shelf is the oldest and is one of the very first RaspberryPi 1 computers that was released. (It’s the one with the yellow analog video signal output on the board!). This particular model is extremely slow but, I hang onto it just as a reminder of the first SBC in the line.
The second one is a RaspberryPi 2, a quad core machine that is only slightly faster than the first model but, it’s powerful enough to run HAM Clock.
It didn’t take long to install a vanilla Raspbian Desktop O/S and get it configured on the local LAN. I installed a few packages that I like to have available on all my Linux machines and then started on the HAM Clock install.
The first thing I needed to do was install the X11 development library that is required to compile the HAM Clock binary. To do this, open a terminal and enter the command below to install the package.
sudo apt install libx11-dev
You will need to type in your password to obtain root privileges to complete the installation process and then wait for the package to be installed.
The HAM Clock source code is available from the HAM Clock Website under the Download tab in .zip format. Once downloaded unzip the file and change directory into the ESPHamClock folder ready to compile the code.
cd ~/Downloads/ESPHamClock
Once in the ESPHamClock directory you can run a command to get details on how to compile the source code.
make help
This will check your system to see what screen resolutions are available and then list out the options available to you for compiling the code as shown below.
The following targets are available (as appropriate for your system)
hamclock-800x480 X11 GUI desktop version, AKA hamclock
hamclock-1600x960 X11 GUI desktop version, larger, AKA hamclock-big
hamclock-2400x1440 X11 GUI desktop version, larger yet
hamclock-3200x1920 X11 GUI desktop version, huge
hamclock-web-800x480 web server only (no display)
hamclock-web-1600x960 web server only (no display), larger
hamclock-web-2400x1440 web server only (no display), larger yet
hamclock-web-3200x1920 web server only (no display), huge
hamclock-fb0-800x480 RPi stand-alone /dev/fb0, AKA hamclock-fb0-small
hamclock-fb0-1600x960 RPi stand-alone /dev/fb0, larger, AKA hamclock-fb0
hamclock-fb0-2400x1440 RPi stand-alone /dev/fb0, larger yet
hamclock-fb0-3200x1920 RPi stand-alone /dev/fb0, huge
For my system 1600×960 was the best option and so I compiled the code using the command as follows.
make hamclock-1600x960
It’s no surprise that it takes a while to compile the code on such a low powered device. I can’t tell you how long exactly as I went and made a brew and did a few other things whilst it was running but, it took a while!
Once the compilation was complete you then need to install the application to your desktop environment and move the binary to the correct directory.
make install
Once the install is complete there should be an icon on the GUI desktop to start the app. If like mine it didn’t create the icon then you can start the HAM Clock by using the following command in the terminal.
/usr/local/bin/hamclock &
The first time you start the app you’ll need to enter your station information, callsign, location etc and then select the settings you want to use. There are 4 pages of options for configuring the app all of which are described in the user documentation.
M0AWS – HAM Clock running on RaspberryPi Computer
Once the configuration is complete the map will populate with the default panels and data. I tailored my panels to show the items of interest to me namely, POTA, SOTA, International Beacon Project and the ISS space station track. I was hoping to be able to display more than one satellite at a time on the map however, the interface only allows for one bird to be tracked at a time.
You can access the HAM Clock from another computer using a web browser pointed at your RaspberryPi on your local LAN using either the IP address or the hostname of the device.
http://<hostname>:8081/live.html
or
http://<ip-address>:8081/live.html
You can also control the HAM Clock remotely via web browser using a set of web commands that are detailed on port 8080 of the device.
http://<hostname or ip-address>:8080/
M0AWS – HAM Clock remote command set
This is a great addition to any HAM shack especially if, like me you have an old HDTV on the wall of the shack that is crying out to display something useful.
More soon …
We use cookies to ensure that we give you the best experience on our website. If you continue to use this site we will assume that you are happy with it.
