Living in a rural area we have a very unreliable mains power supply and so I have to protect all the IT equipment in my home lab with an uninterruptible power supply (UPS).
Over the years I’ve found APC UPSs to be super reliable and use them extensively around the house to keep important services running during power outages.
Running a combination of Debian and Ubuntu operating systems on my servers and virtual machines (VMs) I’ve always used the apcupsd daemon to interface with the UPS for automated shutdowns etc.
The apcupsd daemon does have a very simple web interface that can display 3 items of information at a time but, I decided it would be nice to have a view showing all the information on one dashboard.
Node-Red APC UPS Flow
The Node-Red flow is pretty simple and is based around the apcrequest node that connects directly to the apcupsd service on port 3551.
Note: You must configure the apcupsd service as a NIS server in the /etc/apcupsd/apcupsd.conf config file.
Most of the info is collected via the apcrequest node however, I found that getting the events information via the node to be unreliable and so I used a BigSSH node to connect to the computer to get the UPS events information directly from the log file.
The simple flow collects the data, formats it into a useable format and then passes the data on to the dashboard GUI objects for display, it really is very simple.
Node-Red APC UPS Dashboard
The resultant dashboard clearly displays all the information needed including line voltage over time. I was surprised to see such a swing in the incoming voltage but, now understand why I get so many low line voltage and over voltage events on the UPS.
The events log is displayed in a scrolling text area on the dashboard with colour highlighting.
If you’d like to create a dashboard for your APC UPS then the flow can be downloaded below.
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
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 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 layermenu that allows the viewer to filter by band thus reducing the number of icons on the screen at any one time.
Seeing the data presented on a map really brings my logs alive. An example of this is that I had no idea I’d worked so many stations in India on the QO-100 Satellite.
The small icons in the pins show a microphone for SSB/FM/FreeDV contacts and a downwards pointing triangle in a box for CW contacts. Sadly I couldn’t find a Morse key icon in the collection available.
M0AWS filtered view of QO-100 Satellite contacts
I only use FT4/8 for testing new antenna designs however, it’s interesting to see the global coverage accomplished with this weak signal mode.
M0AWS WSJT-X FT4/8 Interactive Log World Map
Once I’ve finished rewriting the format generic payload function I will make the flow available for download here so that others can also create an interactive view of their radio logs.
If you want to have a look at the maps and try them out for yourself, they are available under the Logs menu above.
This Node-Red instance is running in a virtual machine (VM) on a 16GB RAM RaspberryPi 5 that is also running a number of other VMs at the same time so, it’s safe to say it’s not heavy on CPU and will run on the older Pi4 as well.
I’ve recently been trying out the FreeDV RADEv1 digital voice mode on the HF bands with great success. The audio quality is astounding when compared to the normal analog SSB mode. Using only 20w I’ve been surprised how successful I’ve been talking to stations in the UK and Europe as can be seen in my FreeDV Log.
FreeDV has been around for quite a few years with development being funded by an ARDC grant and financial sponsorship from the Software Freedom Conservancy.
“FreeDV is a suite of digital voice modes for HF radio. Our flagship mode is the Radio Autoencoder (RADE). You can run RADE using a free GUI application for Windows, Linux and macOS that allows any SSB radio to be used for high quality digital voice.“
And the most important part:
“All software is open source, released under the (a) GNU Lesser Public License version 2.1 (GUI and legacy FreeDV modes) and two-clause BSD license (RADE).“
FreeDV running under KDE-Plasma on Kubuntu PC
Looking at the digital voice (DV) community in the HAM Radio world, it’s stuffed full with proprietary DV modes from small software houses and black box transceiver manufacturers with no real OpenSource alternatives, until now.
Installing FreeDV is pretty simple regardless of which operating system (O/S) you use. Being a Linux user I grabbed the AppImage from the website and set about reading up on how it works and how it is configured.
I decided to take the two sound card approach since I have 2 USB sound cards connected to my shack Kubuntu Linux PC.
Configuring the audio routing isn’t straight forward as both the receive and transmit audio to/from the radio needs to be routed via the FreeDV app. To make this even more complicated I am using my Hermes Lite 2 SDR transceiver and PiHPSDR software, a complete OpenSource/OpenHardware Amateur Radio Station.
M0AWS FreeDV and PiHPSDR Audio Routing Diagram
Trying to clearly describe the audio routing using words alone would be impossible and very confusing so, I put together the diagram above.
Using two USB sound cards I’ve configured the system such that USB Sound Card 1 (an old Griffin iMic USB sound device) handles just the audio from/to the headphones and microphone. All the audio at this point in the system is analogue.
The second USB sound card, a cheap Plug and Play (PNP) USB audio device from Amazon, handles all the digitised signals from/to FreeDV and PiHPSDR.
Taking this 2 sound card approach keeps confusion to a minimum and separates the analogue and digital components of the audio routing.
So, how does this translate to the FreeDV and PiHPSDR audio settings?
Transmit Audio Chain
FreeDV Transmit Audio Settings
Starting at the beginning of the transmit audio chain, let’s look at the transmit audio settings in FreeDV.
Looking at the FreeDV Transmit audio settings screenshot below we can see that the Input From Microphone to Computer device is set to:
This is the digitised audio output from FreeDV (via USB Sound Card 2) to PiHPSDR and is used as the transmit audio that is sent to the Hermes Lite 2 transceiver.
FreeDV Transmit Audio Settings
PiHPSDR Transmit Audio Setting
To complete the transmit audio path we next need to look at the PiHPSDR transmit audio setting.
PiHPSDR Transmit Audio Settings
As can be seen in the screenshot above, the Local Microphone device in PiHPSDR is set to the Monitor of USB PnP Audio Device Analogue Stereo.
This effectively routes the digitised output audio from FreeDV (Output From Computer to Radio device) to the Input audio of PiHPSDR.
The reason for using the Monitor audio feed is because FreeDV does not recognise the Mic Input in PiHPSDR as a valid output device for FreeDV to use, hence we just need to monitor the FreeDV output device and use it as our input audio device in PiHPSDR.
This completes the transmit audio chain.
Receive Audio Chain
PiHPSDR Receive Audio Setting
Starting at the beginning of the receive audio chain we first look at the PiHPSDR receive audio setting.
PiHPSDR Receive Audio Setting
In the screenshot above we can see that the receive audio output from PiHPSDR is set to USB PnP Audio Device Analogue Stereo (USB Sound Card2). This is the DX station’s digitised audio as received by the Hermes Lite 2.
FreeDV Receive Audio Settings
Next let’s look at the receive audio setting in FreeDV.
FreeDV Receive Audio Settings
The Input To Computer from Radio device is set to the monitor of the USB PnP Audio Output Device:
This is the analogue audio output on the iMic USB Sound card (Sound Card 1) that routes the analogue audio to the headphones and completes the receive audio chain.
Summary
The audio routing required by FreeDV can appear very daunting when first attempting to configure it on the Linux platform but, hopefully the diagram and screenshots above will help in understanding the complete end-to-end audio chain that is required to make this mode work.
PiHPSDR can of course be replaced by your black box radio CODEC entries that will appear in the device lists shown above if you have your radio connected via USB. The config is basically the same but, just uses a different device instead of USB sound card 2 shown in the diagram above.
I hope this article is useful to those wanting to try FreeDV on the Linux platform and I look forward to hearing you on RADEv1.
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:
# 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
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 mediaVirtual 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
Next set the size of the virtual disk that the VM will use.
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
Now it’s just a case of going through the standard Debian install process to build your Debian VM.
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.
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:
# 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
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.
In December 2024 the RaspberryPi 500 was announced with great fanfare in the maker world. Following on from the RaspberryPi 400 series, the 500 model moved the keyboard based 80’s style desktop computer to the new faster CPU and RP1 I/O chip technology that came with the RaspberryPi 5 model.
This was hailed as a big step forward in performance for the 500 series however, for me it was disappointing. The problem with the 500 is that it didn’t come with an M.2 NVME SSD connector and was based around the much slower SD card storage solution.
All of my Pi5 models have been upgraded with the Pimoroni SSD Baseboard and a 250GB M.2 NVME SSD drive making a huge improvement in performance for the little single board computer (SBC).
Along comes the Raspberry Pi 500 and once again it’s hobbled by the fact that it has no SSD support on the motherboard. What was ridiculous was that all the pads and tracks were on the circuit board but, not populated. This annoyed many in the RaspberryPi community, myself included as the new faster machine was once again held back by slow SD card I/O.
What made it even worse was the fact that the 500 didn’t have the facility to add an M.2 NVME SSD via the PCIe interface like on the Pi5, making it even more disappointing.
Needless to say I, along with many others didn’t put my hand in my pocket to purchase a 500 as it would be a huge step backwards from my Pi5’s.
Step forward to September 2025 and RaspberryPi announce the new RaspberryPi 500+, the computer we all hoped for 12 months earlier.
My RaspberryPi 500+ that I’m using to write this article
I ordered my 500+ from Pimoroni the moment the email saying it was available with its new high spec dropped into my inbox. Being one of the first to splash the cash I got a 20% discount off the price too, which made the purchase even easier.
A few days later the 500+ landed on my doorstep and I hastily unpacked it.
The 500+ comes with 16GB of RAM and a 256GB M.2 NVME SSD drive from the factory, exactly what we all wanted from the original 500. To everyone’s surprise the 500+ also comes with a new Clicky Gateron Blue KS-33 mechanical keyboard. This isn’t something I was expecting but, it was a nice surprise!
Connecting the 500+ to my mouse, ethernet cable, 4K monitor and official PSU it burst into life. The SSD comes preloaded with RaspberryPi OS and boots first time, no messing with loading ISO images to SD cards here!
The first thing I noticed was that the 500+ feels snappier than my Pi5, even though they both have the same SSD drive. Apps start just that bit quicker on the 500+ and copying files around feels quicker too.
Could this be because the SSD is now directly on the motherboard rather than at the end of a ribbon cable like on the Pi5?
The new keyboard is very different to use compared to the old 400/500 and the official RaspberryPi keyboard for the Pi SBC’s. It’s very clicky and slightly wider with more space between the keys. Initially this is annoying as it creates typo hell but, after some time your muscle memory adjusts and your typing gets back to it’s normal typo free experience.
The new keyboard is a nice improvement over the original 500 and makes the hiked price of £178.00 (with 20% discount) worth paying. The new keyboard is also backlit and can be adjusted to a range of colours and effects. I settled on having the keys light up in red once pressed as this is much easier on the eyes.
Since I’d been using a Pi5 with SSD as my desktop PC in the home office for over a year now I wanted to move my custom KDE-Plasma setup over to my new 500+ in place of the rather sparse RaspberryPi OS desktop that comes as standard on the 500+ SSD.
RaspberyPi 500+ open for SSD replacementRaspberryPi 500+ M.2 NVME SSD Drive
Opening the 500+ is relatively easy using the supplied spudger to tease the keyboard top and bottom apart once the screws have been removed.
Upon splitting the top and bottom sections you immediately become aware of the rather fragile looking ribbon cable that connects the keyboard to the motherboard. Access to the SSD drive is very good and it only took a minute to swap the drives over.
Gently clicking the keyboard back to the bottom half of the case and inserting all the screws I reconnected the computer to all my peripherals and switched it on.
In no time at all my favourite KDE-Plasma desktop and all my files and apps were at my fingertips just as they had been for the last year on my Pi5. An easy transition to the new 500+ now means I have a spare Pi5 and 250GB SSD for another project.
I must say that it would had been much nicer if there was a little removable panel on the bottom of the 500+ providing access to the SSD. This would had made it so much simpler to change the SSD drive without having to find the necessary tools to take the unit apart. Maybe an improvement for the 600+ next year!
The other thing I’ve noticed is that the 500+ runs considerably cooler than the Pi5 with the official cooler. My Pi5 would often reach 50 deg C however, the 500+ rarely gets above 30 deg C.
Overall I’m really pleased with my new RaspberryPi 500+, it’s the RaspberryPi I’ve been wanting in my home office for some time and finally it’s arrived.
Was it worth waiting for? Absolutely! It’s everything the 500 should had been at the outset.
For some time I’ve been considering purchasing a 3D printer so that I can create parts for my HAM Radio projects. The issue has always been, what printer to buy?
Having searched online, watched many YouTube videos and endless reading I ended up even more confused and no closer to making a decision. In the end I decided to step away from the idea for a while and see where things went.
Some time much later I ventured back to the subject and discovered the Bambu Lab 3D printer range. These were getting rave reviews and were positioned as being ideal for the total 3D printing beginner.
Once again I read as much as I could about the Bambu Lab printers, watched endless videos and searched online for supplies, spare parts etc to ensure they were readily available.
Eventually I had all the boxes ticked.
Relatively easy to use software
MacOS/Linux supported
Can print using the filament types I need for my projects
Good size print plate
iPhone App
Wireless connectivity
Built in camera for time-lapse videos
Multi-colour filament delivery system
Sensibly priced filament
Readily available replacement parts
Active Eco System and community
Looking at all the current 3D printers available in the Bambu Lab range I decided to purchase the A1 Combo model. This has a 256 x 256mm build plate, 4 filament feed print head and the filament Automatic Management System (AMS) that makes multi-colour printing a breeze.
With the decision made all I had to do was find a supplier. Strangely enough buying direct from Bambu Lab gave the best price and with the £10 voucher and 28% off of filament bought at the same time as the printer it was a no brainer.
£528 later I had 10 rolls of filament and an A1 Combo 3D printer winging it’s way to me.
Bambu Lab A1 Combo 3D Printer
2 days later our local DPD delivery driver arrived with 2 large boxes and a comment about how heavy one of the boxes was.
Upon opening the printer box I found it was extremely well packed. The printer comes in a partially assembled form and requires some assembly by the end user. All the parts are really well labelled right down to each packet of screws being labelled with their exact use. All the tools needed to assemble the printer are included as is the easy to follow manual.
Bambu Lab screw packages labelled for each partBambu Lab screw set for the AMS Stand
Another thing I really liked about Bambu Lab is that they supply you with screws for things that aren’t in the box, like the scraper screws shown above. At first I thought this was a bit weird but, in reality this makes complete sense as printing your own tool set is a great introduction to making your first prints.
Next I attacked the heavy box, this contained the 10 reels of filament I’d purchased at the same time. I’d ordered a good assortment of colours that would keep everyone in the family happy.
Installing the BambuStudio software on my MacBook Pro was a breeze. Using the account I setup at purchase time I was soon hooked into the Bambu Lab Makerworld community.
I immediately found the tools I needed to print and set about making my first 3D prints. The software has a lot of functionality, especially when it comes to the designing of your own objects. It’s fair to say the initial learning curve is vertical however, there are some great videos on YouTube on printing downloaded objects using the BambuStudio software.
ambuLab Scraper and Stand 3D PrintBambuLab Scraper and Stand 3D Print
Whilst searching for 3D Print tools on the MakerWorld I stumbled across this really neat filament waste collector that fits nicely onto the X axis support. During the print there is a small amount of waste filament, especially if you are printing a multi-colour object as the print head has to be purged each time a new colour is required. Out the box there is nothing to catch the waste filament and so, it ends up on the floor. Fortunately the MakerWorld community resolved this issue with a multitude of options for collecting and storing the waste, all of which you can print yourself.
3D printed waste filament collection bin3D printed waste filament collection bin
The print speed is incredibly quick, much quicker than I ever imagined and it’s addictive to stand and watch the print take form right in front of your eyes.
Printing an iPhone Stand for my sister-in-law
Once I’d printed the necessary tools and a few downloaded iPhone stands for the family I set about looking at designing my own objects.
The Bambu Studio software does have the capability to design objects built in but, the learning curve is vertical and there are very few videos on YouTube showing how to use the object creation section of the software. This lead me to look for an alternative 3D CAD package that had tutorials on how to create 3D print objects. After a little searching online i found that Tinkercad has a great range of tutorials online to get people started with designing their own 3D print objects.
In no time at all I had an account created on the tinkercad site and was going through the online tutorials to learn how to use all the functionality offered in the free tier.
TinkerCAD – Designing a cooling fan mount
The online tutorials are very good and move along at a good pace with interactive examples that show you how things work. Once I’d completed the tutorials I dived straight into designing some objects of my own.
I’ve still got a lot to learn about 3D printing but, I have to say that TinkerCAD really does simplify the whole design process. Once my object designs were complete, all I had to do was export them in .stl format and then import the STL file into Bambu Studio and send it to the printer.
So far my prints have come out great and I’ve been really impressed with the quality of the finished articles.
I’ve now started on my list of HAM Radio 3D print projects and will document my progress over the next few weeks and months as I progress.
For sometime I’ve been using PiHPSDR software to drive my Hermes Lite 2 (HL2) SDR transceiver. It’s a great piece of OpenSource software for SDR transceivers and has the best documentation that I have ever seen from an OpenSource project.
I must admit, I’ve had to make a few changes to get the software how I like it but, that’s the great thing about OpenSource software, you get the source code and can do what you like to it.
Following in this thread I recently decided to give DeskHPSDR a try. DeskHPSDR is a fork of the original PiHPSDR but, with some changes mainly aimed at larger display computers.
After compiling DeskHPSDR on my Kubuntu Linux PC in the radio shack, I found there were a few issues, mainly the colours were hard on the eyes and band/channel markers wrong/missing on a few of bands.
DeskHPSDR default colour scheme on Kubuntu 22.04LTS (KDE-Plasma)
I decided to dive in and take a look at the source code and try and sort out the colour issues as blue writing on dark buttons made them almost impossible to read under a KDE-Plasma desktop.
Delving through the appearance.c and css.c files I found that there were many changes required to get the end result I wanted. The biggest pain is that you have to recompile the source code after each change to see if the code change had worked, this results in many recompiles, a tedious task.
After spending many hours making changes I decided to email Heiko, DL1BZ who is the developer of DeskHPSDR. Over a number of emails we discussed getting the colour management code changed such that it was read in at start time from a separate css file rather than having to be compiled into the main program.
After a few emails back and forth, Heiko changed the code so that a separate CSS file could be read in at start up instead of the hard coded CSS in the C code files, this worked great and made it much easier to make colour changes without constant compilations of the code.
Next I needed to edit the bands.c file to change some of the band edge markers to show the UK band plan as, by default they are incorrect even though I have the region set to UK.
Editing the appearance.c file once more I was able to change the colour of the rather bright green panadapter signal display to a much more pleasing blue fading to red as the signal gets stronger.
One thing I really like about PiHPSDR was the channel markers on the 60m band. Anyone that uses the 60m band will know that the UK allocation is split into 11 different channels separated by spaces used by the primary user of the band. The channel markers make it just that bit easier to ensure you don’t stray out of the allocated channels however, this code had been removed from DeskHPSDR as Heiko didn’t consider it necessary.
Once again I pinged an email over to Heiko explaining how useful it is to UK HAMs and he very kindly put the code back into DeskHPSDR so that the 60m channels are once more clearly visible on the panadapter.
DeskHPSDR modified colour scheme on Kubuntu 22.04LTS (KDE-Plasma)
Feeling happy with the new colour configuration I decided to test it out on Linuxmint Cinnamon. Sadly the scheme that looked so nice under Kubuntu 22.04LTS didn’t look the same under Linuxmint and so I had to set about coming up with a version of the CSS file for this platform too.
After quite a few hours tinkering with CSS code I found it to be impossible to get the colour scheme on Linuxmint Cinnamon Edition identical to that I’d created under Kubuntu KDE-Plasma so, I settled for a look that was as close as possible.
DeskHPSDR on Linuxmint Cinnamon Edition with colour modifications.
Chatting with Steve, M0XVT we thought it would be a good idea to test it on his Kubuntu Linux and Linuxmint PCs. He is using a later version of Kubuntu than I am (24.04LTS) and so, it would be a good test to see if the colour scheme looked the same.
Sadly it turns out that for some bizarre reason the colours come out different in the later version of Kubuntu. This is a real nuisance as it means we’d need a separate colour scheme defining for each version of the O/S. Perhaps using CSS isn’t the best way to define a colour scheme in applications.
For some very strange reason the colours were also rendered differently on his Linuxmint PC even though he was using the same version of the O/S as I am.
DeskHPSDR running on Kubuntu 24.04LTS with colour scheme not rendering correctly
Another issue was found whilst testing on Steve’s computers which seems to be caused by the fact he uses an Anan 200D SDR.
Looking at the documentation on github in theory DeskHPSDR should support the Anan range of SDR transceivers however, we found that it’s impossible to select the sample rate as the drop down selection list is completely missing from the Radio menu with the radio defaulting to its lowest sample rate of 48k resulting in not being able to see the full spectrum of frequency ranges on the bands.
DeskHPSDR Sample Rate drop down missing when using an Anan SDR
The other thing to note is that the Remote Server functionality has also been removed from the code by Heiko as he feels it’s not necessary. This may be a deal breaker for some and so they may choose not to use DeskHPSDR and to continue using PiHPSDR instead.
I will at some point make the O/S specific CSS files and source code available for download for those that want to use DeskHPSDR with my colour scheme changes.
I’m not sure at the moment whether I will continue using DeskHPSDR or go back to PiHPSDR, time will tell.
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.
Griffin Technology Powermate VFO
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.
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.
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.
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 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 ….
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.
