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.
The articles I write for the blog are mostly technical but, I thought it was about time that I wrote this article as it’s been buzzing around inside my head for some time now.
So, what are the 5 things that I have found revolutionary in my shack that have brought new, exciting ideas and projects to life making amateur radio more enjoyable.
1: A RaspberryPi Single Board Computer
RaspberryPi 5 Single Board Computer
Ever since the first RaspberryPi Single Board Computer (SBC) was released I’ve been a huge fan. This little credit card sized number cruncher has been the base for so many projects, it has to be the first on my list.
The RaspberryPi SBC has been through a few iterations since its initial conception and is now powerful enough to take on most tasks that any radio HAM is going to throw at it.
So, what have I done with them?
Well I’ve used them to run Node-Red services for my many web app dashboards that control things like my QO-100 Satellite Ground Station, UPS power monitoring, Internet speed graphs, server and virtual machine monitoring, AllStarLink nodes, hosting websites, building an SDR shortwave receiver, running HAM Clock / Open HAM Clock, developing my own software, hosting virtual machines and a whole host of other fun and interesting things. I’m even writing this article using my RaspberryPi 500+ computer that is my daily desktop PC.
There are an endless number of things you can do with a RaspberryPi to bring new life and functionality to your radio hobby.
Want to get into Amateur TV? Want to decode digital modes real time? Want to track aircraft in the sky real time on a virtual radar screen? Want to search the shortwave bands for stations of interest? Want to host your own blog and website?
All these things and a lot more are easily within reach with a RaspberryPi.
The RaspberryPi is only limited by your imagination, the more imaginative you are the more your number crunching little friend will do.
2: A 3D Printer
Bambu Lab A1 Combo 3D Printer
Every HAM should have a 3D printer. These manufacturing marvels bring a new level of quality, design and simplicity to your HAM radio projects. I’ve found it incredibly useful since venturing into the rabbit hole that is 3D printing. When I think back to the weeks and months of my life I’ve spent making cabinets and boxes out of sheet metal, aluminium or wood for the numerous projects I’ve built over the years, a 3D printer would had made my life so much easier. 3D printing has revolutionised the making of things for the Amateur Radio home brewer.
There’s a multitude of useful things on websites like Printables, Thingiverse , Makerworld and others where you can just download the files and print high quality designs for all those things you’ve wanted to do but, don’t have the time or inclination to craft by hand.
The real satisfaction with 3D printing comes from designing your own things and making them. My first project was to design and print a fan cooling system for my Xiegu XPA125B amplifier.
From the factory the amp is passively cooled and doesn’t take long for the heat-sink to become saturated resulting in a high operating temperature. I was never happy with this and so was determined to resolve the problem.
Getting to grips with TinkerCAD was a bit of a vertical learning curve but, after a few mistakes and design mishaps I soon had it under my belt and pressed on with designing the cooler unit.
Designing the Xiegu XPA125b cooling system using tinkerCAD.
It’s not until you start designing and manufacturing things that you suddenly realise how much effort goes into them but, I persevered and over the period of about a week or so I had a perfectly fitting, operational cooling system that kept the amp super cool regardless of how long I waffled on for on the HF bands.
Once you’ve got your first design made you suddenly find yourself wanting to improve it and add things. In my case this was adding a Hermes Lite 2 holder to the top of the amp cooler and then a top shelf to hold my cross needle SWR and power meter.
Since then I’ve progressed massively with my designs and have even designed and printed things for other HAMs and family members, it’s totally addictive!
I can highly recommend the Bambu Lab A1 Combo (As shown above). It’s a quality piece of equipment that has operated faultlessly since purchase. Right now it’s printing a case for my RaspberryPi 4, just one of the many projects I’ve used it for since becoming a happy owner.
RaspberryPi 4 case from printables.com
Go on, release your inner creativity and treat yourself to a 3D printer, you won’t regret it and it’ll help you bring to life all of those radio projects you’ve dreamt of doing but, never got round to starting.
3: An AllStarLink Node
M0AW AllStarLink Node 61928 sitting on the equipment rack
Many people say that using VOIP over the internet isn’t real radio, I know because I used to be one of those people however, it has become an invaluable resource for keeping in touch with people all over the world.
Being part of an online HAM Radio Community it’s important that as a group we are able to talk to each other regardless of where we live, what bands we have access to and whether there is any propagation.
The AllStarLink (ASL) network gives global FM quality audio no matter where you are in the world. We use it daily for our breakfast net, general chatter throughout the day and even hold a weekly Matrix ASL Net on a Thursday evening.
Using our VHF/UHF handhelds (Real Radios!) and an easy to make AllStarLink Node we’re able to join in with the conversation regardless of propagation, licence type or distance, it really is great for bringing people together.
With devices like the SHARI and AIOC board now being readily available for minimal cost it really is very easy to get onto the AllStarLink network and talk to people even if you live in an antenna restricted location.
Why be alone when you can use the Matrix ASL node ( 642332 ) and join in the conversation.
4: Node-Red
M0AWS – Updated NodeRed QO-100 Dashboard with PTT button
Node-Red is a low-code programming tool for event-driven applications.
Node-RED’s goal is to enable anyone to build applications that collect, transform and visualise their data; building flows that can automate their world. Its low-code nature makes it accessible to users of any background, whether for home automation, industrial control systems or anything in between.
I’ve been using Node-Red for a number of years now and have developed a suite of web app’s that control and monitor just about every aspect of my Amateur Radio hobby and IT infrastructure.
Node-Red forms an integral part of my QO-100 Satellite Ground Station providing control of both the uplink and down link radios whilst synchronising the VFO’s, controlling filter selection and more, all from one simple to use interface using nothing more than a web browser.
It doesn’t stop there, my AllStarLink (ASL) nodes are also managed through a user friendly Node-Red Dashboard that removes all the need for technical know how and makes ASL node management as simple as clicking on a button to connect or disconnect to the many global networks.
Much of this functionality is achieved without writing a single line of code. If you can use a mouse, drag and drop objects on the screen you can develop Node-Red web app’s, it really is that easy.
M0AWS Interactive Log Flow
It doesn’t end there, Node-Red is great for presenting data in easy to digest formats.
Whether it be HAM Radio Log data presented on an interactive world map or monitoring of your server, RaspberryPi, virtual machine or UPS using gauges and graphs, this can all be achieved easily with nothing more than a mouse. There’s no need to spend hours writing thousands of lines of code, just drag and drop a few nodes onto the screen and join them up. You’ll be amazed how easy it is.
I believe every Amateur Radio enthusiast should have Node-Red available in their radio shack. It’s easy to install on your RaspberryPi 4 or 5, Linux or Windows PC and Apple Mac with the same great functionality available on all platforms.
Once you’ve developed your first web app you’ll suddenly find a million more ideas will come into your head and before you know it, you’ll be where I am today with Node-Red at the centre of your radio hobby.
5: A Hermes Lite 2 HF SDR Transceiver
For years I used black box HF radios from the big 3 manufacturers along with the odd radio from the smaller enterprises like TenTec but, they all had their foibles and there was often nothing I could do about it.
My last acquisition from the big 3 was a Yaesu FTDX10, a competent hybrid SDR radio with a good receiver however, the menu system is terrible, the button layout not much better and the user experience not as good as it could be. Of course the software is closed source so there is nothing you can do about it. The radio did its job but, it wasn’t fun to use, it wasn’t what I really wanted and it didn’t put a smile on my face.
I looked at moving to software defined radios (SDR) but, with prices in the many thousands of pounds bracket and the software being closed source I came to the conclusion that they wouldn’t give me what I really wanted either.
So what was it that I was searching for?
Thinking long and hard about it I came to the conclusion that what I really wanted was a radio that gave me the same satisfaction that OpenSource software has given me for decades, namely an HF radio that I have complete control over, from the hardware through to the software and everything in between.
I wanted something that I could tailor to my exact needs. Something that was built using open hardware and open software, something where if I wasn’t happy with it I could change it, improve it and do the things I wanted with it.
At this point my search for the ideal radio headed in a completely different direction.
Xiegu XPA125b Cooler with Hermes Lite 2 cradle – front view
The Hermes Lite 2 SDR HF Transceiver (HL2) has been around for a number of years. I was first introduced to it by Michael, DK1MI and then Roger, G8VLR via the Matrix. Both Michael and Roger use the HL2 on a regular basis and have often waxed lyrical about how good it is.
Being designed by radio amateurs for radio amateurs it’s based on an open architecture from the ground up. Being an OpenSource junky this really appealed to me and as I looked deeper into it from both a hardware and software point of view I soon realised that it had the potential to be exactly what I was looking for.
It wasn’t long before I found myself on the Makerfabs website placing an order for the HL2 mainboard, filter board, I/O board and case. A couple of weeks later it arrived and I dived head first into the SDR rabbit hole.
2 years later and the HL2 has become my main HF radio in the shack. Partnered with a Xiegu XPA125B amplifier and PiHPSDR software running on my Kubuntu Linux PC it is everything I have been looking for in an HF radio.
I’ve made modifications to the software to suit my operating style and needs with the user interface being exactly how I want it, no unnecessary buttons or knobs, just the controls that I use on a daily basis cleanly placed in a logical, easy to use layout, the way I want it.
My understanding of software defined radio and how it works has improved a hundred fold. Having access to the software and being able to go through the code and understand the architecture has been an interesting journey and one that has enhanced my radio enjoyment considerably. I now have a smile on my face every time I go on air.
Do I miss the FTDX10?
No, not in the slightest!
So, those are the 5 things that I feel have revolutionised my radio amateur hobby and made it a more enjoyable experience. I’m sure over time I will add to this list as I venture down future rabbit holes in our wonderful radio hobby.
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.
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.
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.
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
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.
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.
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!
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
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.
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
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.
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.
1946 Philips receiver Serial Number plate1946 Philips receiver Licence Plate
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
Getting the internals out of the cabinet was fun, so many little screws holding the old valve electronics and tuning display in place.
1946 Philips Receiver – Internal View1946 Philips receiver – removing the original control knobs
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
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.
79 years worth of grime and dirt to be removed!Washing the Bakelite receiver case
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
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.