M0AWS – Page 3 – M0AWS Amateur Radio

8 October 202517 October 2025

RaspberryPi 500+

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 — 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 replacement

RaspberryPi 500+ M.2 NVME SSD Drive — RaspberyPi 500+ open for SSD replacement

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.

More soon…

19 September 202519 September 2025

Website Outage

Apologies for the website outage. This was caused by Zen Internet’s FTTP service going down just a few days after I switched over to it.

Hopefully it’ll stay online now and normal service will resume.

More soon …..

15 September 2025

Xiegu XPA125b Cooling System

I’ve been using my Xiegu XPA125b amplifier with my Hermes Lite 2 SDR transceiver for some time now and have found it to be a great performer. The only issue I have with the amplifier is that it is passively cooled with the operating temperature often reaching in excess of 50 degrees Celsius. There is an air vent on the right-hand side of the amplifier case and then a very small vent on the rear where the end of the PA heatsink is however, air flow is really poor and so the heatsink can get saturated with heat very easily.

Having recently purchased a Bambu Lab A1 Combo 3D printer I’d already decided I was going to have a go at designing and making a fan assisted cooling system for the Xiegu amplifier.

Having no experience and very little knowledge of 3D printing I dived in head first and hit the vertical learning curve head on. In a fairly short period of time I had put together a design that would work.

Designing the Xiegu XPA125b cooling system using tinkerCAD. — Designing the Xiegu XPA125b cooling system using TinkerCAD.

After 11 design versions and 3 x 3D prints I had a solution that fitted perfectly every time. Getting the 12v fans from Amazon was fairly cheap and I soon had the amp cooler working with a temperature reduction of 20-25 degrees Celsius during long waffle overs on the 80/60m bands. The amp now runs nice and cool with great airflow through the heatsink.

Next I wanted to add a Hermes Lite 2 cradle to the cooler solution so that two devices are neatly stacked together. Like the cooler design, I already had ideas in my head and just needed to get them down in the CAD package.

After some tinkering and 3 test prints I had a solution designed that not only created a cradle for the Hermes Lite 2 but, also a top shelf for my Daiwa CN901HP to sit on.

This brought the whole HF transceiver setup together nicely with all the components now being held in place securely.

Xiegu XPA125b Cooler with Hermes Lite 2 cradle - front view — Xiegu XPA125b Cooler with Hermes Lite 2 cradle – front view

Xiegu XPA125b Cooler with Hermes Lite 2 cradle - side view — Xiegu XPA125b Cooler with Hermes Lite 2 cradle – side view

The 3 fans on the side of the amp are silent which is great, there is a little noise from the air flowing through the case and out the vent at the back of the unit however, it’s barely noticeable. Keeping the case pressurized with cool air and forcing the heat out the rear vent has made a massive difference to the overall temperature of the amp even during long hours on air.

This has been a fun project and a great introduction to 3D printing, I’ve got so many more 3D print ideas now, I think I’ll be spending a lot of time in TinkerCAD.

I’ve just printed and put together a cooler and HL2 cradle for Steve, M0XVT and will be making them to order soon so, if you have a Xiegu XPA125b and want it to run a lot cooler then keep an eye on my website for details of how to buy one.

More soon …

28 August 2025

Joining the 3D Print Revolution

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.

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 part

Bambu Lab screw set for the AMS Stand — Bambu Lab screw packages labelled for each part

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.

BambuLab Scraper and Stand 3D Print — ambuLab 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 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 — 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.

More soon …

16 July 202518 July 2025

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)

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.

More soon…

3 July 20254 July 2025

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.

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

29 June 20257 February 2026

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

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

22 April 202523 April 2025

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

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.

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 …

17 April 202517 April 2025

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

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 …

9 March 202521 June 2025

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.

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.

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:

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