RaspberryPi OS 13 Networking tidy up & broken lm-sensors

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

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

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

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

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

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

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

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

sudo apt install ifupdown

Step 2 – Disable NetworkManager:

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

(Optional but tidy: )

sudo apt purge network-manager

Step 3 – Disable Netplan

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

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

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

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

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

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

Example for DHCP:

auto eth0
iface eth0 inet dhcp

If you use Wi-Fi:

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

Step 5 – Enable the traditional networking service

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

Then confirm:

ip a

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

Step 6 – (Optionally) Clean residual files

Remove leftover NetworkManager/Netplan configs to avoid confusion:

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

Verification

Check which subsystem is active:

systemctl is-active NetworkManager
systemctl is-active networking

Expected output:

inactive
active

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

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

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

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

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

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

# Loopback
auto lo
iface lo inet loopback

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

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

Check both IP Addresses appear on the same interface:

ip a show eth0

For the example above you’ll see:

inet 192.168.1.10/24
inet 192.168.1.11/24

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

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

vcgencmd measure_temp

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

alias cputemp="vcgencmd measure_temp"

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

More soon …

Trialing DeskHPSDR

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

More soon…

Linux – Wandering USB devices

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

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

Griffin Technology Powermate VFO
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.

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

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

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

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

Into the file I wrote the following udev rule.

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

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

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

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

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

udevadm control -R

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

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

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

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

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

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

More soon ….

Rescuing a Bricked Pluto+

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

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

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

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

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

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

So, how do we rescue a bricked Pluto+?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

boot.frm
pluto.frm

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

Once this is complete, eject the PlutoSDR drive safely.

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

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

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

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

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

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

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

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

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

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

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

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

More soon ….

1946 Philips 170A-15 RadioBerry Receiver Project

Back in January 2025 I wrote an article about a little RadioBerry Project I’d started that was based around a very old Philips 170A-15 receiver from 1946.

The idea of the project was to build a nice shortwave receiver for the radio shack based around the RadioBerry HAT on a RaspberryPi 4 housed in a vintage receiver cabinet.

The project has taken longer than I imagined due to getting side-tracked by other projects that I already had ongoing.

1946 Philips 170A-15 Shortwave Receiver Internal View
1946 Philips 170A-15 Shortwave Receiver Internal View

With the original internals removed there’s plenty of room inside for the RadioBerry, RaspberryPi 4 and the small 15w audio amplifier. The audio is delivered via a pair of Celestion speakers that I had that were originally part of an old surround sound TV system.

Power distribution is achieved very simply using a multi-plug adapter that also has USB A connections in it. The whole thing is then powered via one 240v mains cable.

The screen fits over the original opening for the glass tuning display and is held in place by two mounting screws on the rear of the LCD panel.

I purchased some new speaker grill cloth from Amazon and remade the speaker grill front with cut outs for the speakers. It looks really tidy and matches the rest of the bakelite cabinet nicely.

1946 Philips 170A-15 Shortwave Receiver RadioBerry HAT on RaspberryPi 4
1946 Philips 170A-15 Shortwave Receiver RadioBerry HAT on RaspberryPi 4

To finish the project off I need to purchase 3 rotary encoders so that I can have a VFO knob and two more knobs for other things (to be determined). The Volume control is already in place with the original knob fitted to it. It will be nice to complete the 4 knob line up.

1946 Philips 170A-15 Shortwave Receiver Rear Panel
1946 Philips 170A-15 Shortwave Receiver Rear Panel

I had to make a couple of fittings top and bottom to hold the original rear panel in place but, it worked out just fine and I only had to fit an SO239 antenna connector and ethernet RJ45 port so that it can be connected to my local LAN.

Receiving radio Caroline on 648Khz

The audio quality from the little RadioBerry and 15w amp is pretty good. With the speakers hidden nicely behind the refurbished speaker grill the project looks quite tidy!

It also makes a great receiver for the HAM bands with it’s coverage of 100Khz to 30Mhz.

The DL1YCF Enhanced fork of PiHPSDR works really well on the touchscreen and provides a modern control interface to the RadioBerry HAT.

Listening to the 20m HAM Band

I’ll drop a final article once I have purchased the 3 rotary encoders to fill the 3 remaining holes in the front of the cabinet.

More soon …

Updates to my install-pihpsdr.sh script

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

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

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

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

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

PiHPSDR running on Linuxmint 22.1 Cinnamon Edition using the LibreSDR transceiver
PiHPSDR running on Linuxmint 22.1 Cinnamon Edition using the LibreSDR transceiver

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

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

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

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

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

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

More soon …

Hermes Lite 2 Audio

I often get unsolicited good audio reports whilst using my Hermes Lite 2 (HL2) on the HF bands with people asking what settings I am using so, I thought it was time I put together an article on the subject.

I use the DL1YCF enhanced fork of PiHPSDR to drive my HL2, a great OpenSource SDR software package that supports many SDR radios including some very high end, expensive models.

PiHPSDR is extremely configurable via it’s well laid out menu system. It’s possible to change the settings on almost everything which, when combined with really good hardware like the HL2 gives the operator the ability to create an extremely high spec transceiver at a fraction of the price of the typical black box commercial offerings.

Starting at the beginning of the transmit audio chain the first settings to be changed are in the Transmit (TX) menu.

M0AWS Transmit filter settings
M0AWS Transmit filter settings

Using my Sennheiser headset I found I needed to set the Radio Mic setting to Mic Boost. This increases the audio level so that it drives the radio properly. It’s important to make sure that boosting the audio doesn’t cause distortion though.

Next I set the TX Filter Low to 150Hz. This ensures I don’t have that nasty bass sound that you hear often on the HF bands today.

The TX Filter High is set to 2700Hz. This gives me a transmit filter width of 2550Hz which is well within the 2700Hz standard for the HF bands.

I also set the compression level to +10dB to increase the average talk power of the audio.

Next in the transmit audio chain is the TX Equalisation. The PiHPSDR software has a very good software defined Parametric EQ menu that provides all the audio tailoring capabilities any HAM operator will ever need.

Having watched many videos by the great Bob Heil, K9EID (SK) I understand that all the articulation in the voice is around the 2500hz range. Today on the HF bands you often hear bass heavy audio that sounds muddy and horrible. This is exactly the type of audio I don’t want to have so, to this end I have adjusted my EQ settings such that the articulation is accentuated to increase clarity and give a little pep to my rather dull sounding voice.

M0AWS PiHPSDR Transmit EQ Settings
M0AWS PiHPSDR Transmit EQ Settings

Since the transmit filter width is set from 150Hz to 2700Hz there’s really no point in making EQ adjustments outside of this range. As show above I have made the following changes to the transmit EQ settings in PiHPSDR:

FrequencyGain
150hz+6dB
500Hz+5dB
1500Hz+6dB
2500Hz+6dB

The final part of the audio setup is the Mic Gain, I keep this set at 5. This keeps the audio nice and tidy with no IMD.

My HL2 TX Drive is set so that it puts out a maximum of 500mW, this is enough to drive my Xiegu XPA125B amplifier to 100W.

With these settings I find that the Sennheiser headset, PiHPSDR software and the Hermes Lite 2 combination gives me a great signal on all the HF bands.

I hope this helps all those who have asked how my audio is setup and have been so impressed by this great little radio.

More soon …

Signal on RaspberryPi without Snap!

Let me start this article by confessing that I hate Snap on Linux!

The whole idea that you’d need a container type environment to install an application on a Unix system is very far from where I want to be.

It annoys me that snaps are updated automatically too. I know you can disable this but, I shouldn’t have too. App’s should only get updated when I want to update them, not before.

What I really hate is the fact that the Snap back end system is proprietary and owned solely by Canonical, the Ubuntu people. This goes against my OpenSource ethos.

Sadly I had to install Snap to get the Signal messenger app installed on my RaspberryPi 5 desktop computer. App’s installed via Snap are extremely slow to start, run slow and are heavy on resources. Snap also mounts a whole bunch of dependency Snaps via loop devices to make the app work. Snaps make a real mess of your system.

The final straw that broke the camel’s back for me was when Snap did an automatic upgrade to Signal to a version that has a serious bug in it causing it to crash a minute or so after startup. I initially reverted to the previous version to get it working again but, sure enough Snap did another auto-update and broke it again.

This time I couldn’t revert back to the previous version as Canonical, in their infinite wisdom decided to remove the previous version of Signal from their Snap store!

At this point I removed the Signal Snap from my computer, along with all the “hanger on” snap packages that were clogging up the RaspberyyPi 5 and finally did a complete purge of snapd using dpkg to get rid of all the horrendous snap mount points on the file system.

After a reboot I then went hunting for the Signal messenger app source code. Looking through the code it’s not a 5min job to get it compiled on a RaspberryPi and so I followed a few of the forked versions to see if someone had already done all the hard work for me.

After disappearing down a few Rabbit Holes I eventually stumbled into the world of Pi Apps.

Pi Apps is a neat little app that provides access to the “most popular app store for RaspberryPi computers”. It’s 100% free, OpenSource and written in shell scripts. Perfect!

Installing the “Pi Apps” app is straight forward and only takes a few moments.

Pi-Apps - App store for RaspberryPi
Pi-Apps – App store for RaspberryPi

Opening Pi-Apps I found a multitude of OpenSource apps all ready to be installed at the click of a button. In no time at all I’d found Signal and had it installed without getting anywhere near the dreaded Snap.

The version of Signal available at the time of writing this article is v7.39.0 which is fine as this is a stable, bug free version that works reliably.

If you’re using a RaspberryPi computer I can highly recommend you install the Pi-Apps app to enhance your collection of great OpenSource programmes to make your little raspberry flavoured buddy even more useful.

More soon …

Breathing new life into a vintage receiver

Sometime back I purchased a RadioBerry HAT for my RaspberryPi 4 single board computer (SBC) to use as an experimental platform to test PiHPSDR software modifications and to test changes to the actual RadioBerry software. With these two projects completed I decided that the receiver on the RadioBerry was so good it would be a shame not to put it to good use.

RadioBerry HAT
RadioBerry HAT

For many decades I’ve been an avid Short Wave Listener (SWL) but, haven’t had a general coverage receiver for many years. The RadioBerry fills this gap in my radio lineup perfectly but, needs to be put into a suitable cabinet with speakers, display, control knobs and antenna connections.

Rather than just buy another bland square box I decided it would be nice to repurpose an old, vintage radio receiver from a bygone era and bring it into the 21st Century.

1950 Philips valve radio receiver
1946 Philips valve radio receiver

After much searching on the popular auction sites online I eventually found the perfect old receiver for the project, a vintage Philips 170A-15 valve receiver from 1946.

This lovely old Art Deco looking receiver is made from Bakelite which was an early type of plastic made from phenol-formaldehyde resin, obtained from coal tar and methanol.

The full specification for the receiver can be found on the Radio Museum Website.

Sadly this is a non working example of this lovely old receiver and so I don’t feel so guilty stripping it out and replacing it’s internals with the RadioBerry.


Having the original serial number and Licence plate on the radio is nice, it also makes it easy to search for information about the old receiver.

One nice thing I did discover during the disassembly of the receiver was the signature of the person that put the radio together during manufacture on the inside of the Bakelite cabinet.

1946 Philips receiver builder signature
1946 Philips receiver builder signature

Getting the internals out of the cabinet was fun, so many little screws holding the old valve electronics and tuning display in place.

Once the electrical part of the radio was removed I gained access to the old speaker that was fitted to the front panel of the receiver. Unfortunately the speaker cone had a tear in it rendering it useless so I’ll need to get a new speaker(s) for the rebuild.

1946 Philips receiver speaker view
1946 Philips receiver speaker view

Once I got the speaker and fittings removed I set about cleaning the cabinet inside and out to remove the 79 years worth of dirt and grime that had collected within. The fascia of the receiver cabinet seems to have lost it’s shine and will need to be polished to get it back to it’s original beauty.

It took 5 lots of fresh water and washing up liquid to get the cabinet clean. The first three lots of water looked like mud in no time at all such was the state of the cabinet.

With the cabinet now cleaned and put to one side to dry thoroughly I have started to search for the best type of polish to use to put the sheen back onto it.

Once I’ve got the cabinet looking good again I’ll start fitting the new internals. I also need to find a source for a new piece of material to cover the speaker hole at the front of the cabinet as the original material is looking somewhat tired.

The old Philips Emblem from 1946 on the receiver case
The old Philips Emblem from 1946 on the receiver case

More soon …

Hermes Lite 2 and Xiegu XPA125B Auto Band Switching

Since I’ve had my Hermes Lite 2 (HL2) and Xiegu XPA125B amplifier combo I’ve had to manually change the band setting on the amp as I never purchased the HL2 I/O board when I initially purchased the kit.

At the time I didn’t think I would need it but, changing band manually on the amp (and sometimes forgetting causing tuning issues) is a nuisance and so I put my hand in my pocket once again and ordered the I/O board for the HL2.

Hermes Lite 2 I/O Board
Hermes Lite 2 I/O Board

The HL2 I/O board is a small RaspberryPi Pico controlled device that can be used for a multitude of functions depending on the software loaded. Many people are writing their own software for the Pico to do things like control transverters, remote antenna switches, amplifiers and just about anything else you can think of. It’s a really versatile little add on board for the HL2.

The I/O board arrived after about 10 days from Makerfabs, all nicely packaged as always. Unfortunately due to Christmas, New year and other priorities it’s sat in the box since it arrived.

A couple of days ago I finally got round to getting it out of the box and set about configuring it to control the Xiegu amp.

The Xiegu amp needs three connections from the I/O board. They are PTT, Band Switching Voltage and Ground. These are easily accessed from the I/O board via 3 jumper wires to connect to the DB9 connector on the rear of the board.

The other thing that is required is some software for the RaspberryPi Pico to control the whole process. Steve, M0XVT has kindly supplied me with a copy of the software.

Soldering the jumpers from the relevant points on the circuit board to the DB9 connector was pretty straight forward. You can use any of the pins on the DB9 connector that you like as from the factory the DB9 connector isn’t connected to anything. I decided to use pins 2, 6 and 8 and so will refer to those pins from this point forward.

HL2 I/O Board Jumpers
HL2 I/O Board Jumpers

I used a different colour for each of the jumpers so that I knew which jumper was for which connection. The colours used also match the colours of the wire in the old RS232 serial lead that I cannibalized to make the connection between the I/O board and the amp thus making it easy to ensure continuity.

The colours are as follows:

Black Jumper - Ground - Pin 2 on DB9 Connector
White Jumper - PTT - Pin 6 on DB9 Connector
Red Jumper   - Band Control - Pin 8 on DB9 Connector

The I/O board gets its power feed directly from the HL2 main board however, the 3 pins it needs to connect to don’t have any headers in place and so, it’s necessary to solder a short row of 3 header pins onto the HL2 main board.

I found the easiest way to do this was to put the 3 header pins into the correct position and then use the HL2 to N2ADR filter board connector to hold them in place whilst soldering. This worked perfectly and I soon had the header pins soldered onto the main board.

Extra 3 header pins soldered to the main HL2 board
Extra 3 header pins soldered to the main HL2 board

It’s important to note that the 3 extra header pins need to be placed 2 holes away from existing header pins as shown above. Take care to get these pins in the right position so as not to cause any damage to the 3 circuit boards once all are connected and powered up.

Note: The HL2 main board must be removed from the case to solder the extra 3 header pins in place. Take care to ensure the correct fitting of the PA heatsink when when refitting the HL2 main board into the case.

At this point I refitted the N2ADR Filter board back into the HL2 case so that the two sets of header pins aligned correctly ready for the placement of the new I/O board that would connect all 3 circuit boards together.

Preparing the N2ADR Filter board for reconnection
Preparing the N2ADR Filter board for reconnection

Once the filter board was in place I fitted the new I/O board taking care to ensure all pins aligned with the socket and then gently pushed it home.

Close up of the HL2 I/O board fitted to the main HL2 board and N2ADR Filter board
Close up of the HL2 I/O board fitted to the main HL2 board and N2ADR Filter board

The close up of the I/O board connector above shows how the extra 3 header pins connect to the last 3 sockets in the I/O board connector. It’s a snug fit with the N2ADR filter board below it.

View of the fitted HL2 I/O board from above
View of the fitted HL2 I/O board from above

Before the HL2 case can be put back together it’s necessary to load the software onto the RaspberryPi Pico (top left in photo above) that controls the I/O board.

This is accomplished by pressing the tiny button on the Pico whilst connecting a USB lead to the USB socket on the board that had already been plugged into my PC. Once connected the Pico appeared as a USB drive on my Kubuntu Linux desktop. All I then had to do was to copy the software file onto the drive. Once the software file is on the drive the Pico will reboot automatically and the little LED on the board will start to flash to show it has booted successfully. At this point I could safely unplug the USB cable.

The software for the RaspberryPi Pico is available for download below.


The I/O board comes with a new back panel for the HL2 to accommodate the extra connectors on the rear. Refit the top of the HL2 case and then attach the new rear panel using the original 4 counter sunk screws.

Supplied HL2 I/O board replacement rear panel fitted to the HL2 case
Supplied HL2 I/O board replacement rear panel fitted to the case

The final part of this project is to make the lead that will go from the HL2 rear DB9 ACC connector to the Xiegu XPA125B mini din ACC socket.

For this you will need a 6 pin mini din plug (AKA PS2 plug), (these are readily available on Amazon) and an old fashioned DB9 female connector from the days of RS232 serial leads..

The connections are as follows:

DB9 Pin 2 (BLACK) to Mini Din Pin 6 (GND)
DB9 Pin 6 (WHITE) to mini Din Pin 2 (PTT)
DB9 Pin 8 (RED) to Mini Din Pin 3 (Band Switching Voltage)

Below are a couple of screenshots from the Xiegu XPA125B user manual showing the Mini Din pin layout and the data interface connections for the amplifier.

Xiegu XPA125B Amplifier ACC Interface Connections
Xiegu XPA125B Amplifier ACC Interface Connections
Xiegu XPA125B Amplifier ACC Connector Pin Information
Xiegu XPA125B Amplifier ACC Connector Pin Information

Before I connected the lead to the two devices, I tested the end-to-end continuity of the lead to ensure all pins were correctly connected and that there were no shorts between any of the pins.

It’s important that the wires are connected to the correct pins on each end of the lead. Failure to ensure correct connection could cause damage to your HL2 and/or amplifier.

Once the lead had been tested, I connected it to both the Hermes Lite 2 and the Xiegu XPA125B amplifier. I also had to switch the amplifier band switching to AUTO.

Now when I change band on my HL2 in the PiHPSDR software the amplifier also changes band at the same time keeping the two devices in sync. No more manual band changing for me!

I hope this article is of use to other Hermes Lite 2 users who have purchased the Xiegu XPA125B but, have yet to setup auto band switching between the two devices.

Thanks to Steve, M0XVT for all the jumper information and the RaspberryPi Pico Software to get this all working.

UPDATE:
The RaspberryPi Pico software originally came from Ramon, KP4RX. More information can found in this Google Groups article where he released the binary into the wild.

A full table of I/O resources available on the HL2 I/O board can be found on the KP4RX Guthub page.

The source code for the main.uf2 file above can be found at KP4RX.com

More soon …