Github – M0AWS Amateur Radio

2 May 20262 May 2026

Bring your old handheld to life with an AIOC

I’m sure there are many radio amateurs around the world today who have an old handheld radio sat on the shelf that works perfectly but, has been replaced by a new, shiny, all singing, all dancing model that gets used on a daily basis. I for one have fallen into this trap with the recent purchase of a very nice Wouxun KG-UV9K full duplex 2m and 70cm handheld.

On my shelf there is a cheap Retevis RT85 that gave sterling service for a number of years and even today is ready to continue that service, if only I had a need?

Well now I do!

Currently I have an AllStarLink node running on a RaspberryPi 3b connected to a SHARI device that operates on the 70cm band. This node works great and gives me the ability to chat with people all over the world from my trusty handheld. It does of course also give me access to the weekly Matrix AllStarLink Net that happens on our Matrix node ( 642332 ) every Thursday evening at 20:00 UK time, a great way of bringing the Matrix HAM Radio community together regardless of propagation.

For some time I’ve been wanting to bring another AllStarLink node online so that I can have a connection to HUBNET/FreeNet whilst keeping my current node connected to the Matrix node for our regular daily chats. Since my new Wouxun handheld is a full duplex unit it makes sense to bring a new node up on the 2m band as I can then monitor both at the same time easily. I do have a spare SHARI node however, it’s a UHF only unit and I don’t want another node on the 70cm band. This is where the old Retevis RT85 comes in to play.

The All In One Cable ( AIOC ) board is a very neat little CM108 compatible sound card and serial interface that is sold by Steve, KM9G of YouTube fame ( Temporarily Offline ) that plugs into any handheld radio that has the now pretty much standard Kenwood ‘K’ type mic connector.

The AIOC board really is tiny but, beautifully put together. The four large solder pads on the top and more on the underside are positioned such that the TRS plug solder lugs line up perfectly for soldering. Attempting to do this by hand would be impossible as it’s critical that the spacing between the two connectors matches that of the spacing of the sockets on the radio.

Searching online I found a very handy soldering jig on Github that enables you to hold both the TRS connectors and AIOC board in the perfect position for soldering.

Downloading the .STL file I quickly printed off a solder jig on my Bambu Lab A1 Combo 3D printer and fitted the components into place ready for soldering.

Fitting TRS connectors into the AIOC solder jig

Fitting AIOC board into the solder jig. — Fitting TRS connectors into the AIOC solder jig

Everything fitted rather snugly into the jig and I soon had the board and connectors soldered together. Test fitting to my Retevis RT85 I found the TRS plugs lined up perfectly and it slid into the sockets with ease.

I then thought about designing a case for the AIOC board so that the bare circuit was nicely protected but, quickly searched online and found that NA6D has already designed a case and made the .STL available publicly for download on Printable.com. I quickly grabbed a copy of the file and punted it off to my 3D printer to get to work on.

Once the print was complete I fitted the AIOC board and snapped it together ready for testing.

Fitting the AIOC into the 3D printed case.

AIOC case with 2 x TRS connectors in place. — Fitting the AIOC into the 3D printed case.

Now that the AIOC was production ready I moved on to getting the latest version of AllStarLink onto my RaspberryPi 4 that I had taken out of my RadioBerry based shortwave receiver that I am going to upgrade to a Hermes Lite 2 in a later project. The RaspberryPi 4 is perfect for AllStarLink 3, a 64bit app and operating system.

Using the RaspberryPi Imager I pulled the image down onto an SD card and slipped it into my Pi4. ( Instructions on how to do this are on the AllStarLink website here )

Booting the Pi4 for the first time I found that it went through a number of reboot and configuration cycles before it was ready for use.

Once ready I went through all the normal configuration of the Pi4 namely, static IP assignment, timezone config, security, port forwarding etc etc.

Having configured an AllStarLink node for myself and only just a few days ago for another HAM I was pretty familiar with the setup. Wanting to make sure there were no “gotcha’s” I also watched a couple of KM9G’s videos on Youtube to make sure I wasn’t missing anything.

Using the asl-menu command line app as user root I set about configuring Asterisk to work with the AIOC board. Much to my frustration I could not get Asterisk to recognise the AIOC board as an available sound device. I checked and double checked all the settings ensuring that I had selected “AIOC” in the available devices menu but found that Asterisk constantly errored saying it could not find the selected audio device. This went on for a whole day without success and so, I decided to put it to one side and come back to it later, a method I found that often worked.

A couple of days later I revisited the problem and had decided to take a different approach. Rather than continue going through the asl-menu app I decided to drop down to a lower level and go through the asterisk config files in the /etc/asterisk directory.

It wasn’t long before I found a file called res_usbradio.conf. Inside this file was the config for the AIOC board however, it was all commented out which meant it was disabled.

I’m guessing here but, I imagine this is what should get enabled when selecting AIOC in the available devices menu in the asl-menu command line app but, for some reason it doesn’t happen.

[general]
;usb_devices = 1209:7388    ;comma delimited list of usb
                            ;descriptors to allow.
                            ;format vvvv:pppp in hexadecimal
                            ;vvvv=vendor id, pppp=product id
                            ;
                            ;1209:7388 = AIOC (all in one cable)

Above is the disabled configuration which is easily edited to enable the AIOC device as shown below.

[general]
usb_devices = 1209:7388    ;comma delimited list of usb
                            ;descriptors to allow.
                            ;format vvvv:pppp in hexadecimal
                            ;vvvv=vendor id, pppp=product id
                            ;
                            1209:7388 = AIOC (all in one cable)

Once the updated file had been saved and I restarted Asterisk using systemctl the AIOC burst into life and Asterisk recognised it immediately. The Retevis RT85 switched between TX and RX and I was ready to check out the audio.

Setting the volume levels for both RX and TX via the command line tuning app I connected the node to my already existing node. Sure enough the two nodes connected without error and I was able to send and receive audio between them via the AllStarLink net.

Connecting the new node to the parrot I checked the audio levels to ensure it sounded ok and then connected it to the Matrix node where I had a brief chat with Ben, M8TKK.

All that is left to do now is to 3D print a case for the Pi4 so that it isn’t left naked and at risk of being shorted out on conductive surfaces and it’ll be ready for service.

I also plan to build another AllStarLink node using a 4m band handheld and another AIOC board and then will apply for MB7Ixx callsigns for the two new nodes. This will hopefully help to bring some life to the 2m/4m bands locally and introduce HAM’s both to the weekly Matrix Net and HUBNet/FreeStar via AllStarLink.

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…

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

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 …

5 March 2025

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 …

19 January 202511 August 2026

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.

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.

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

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

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

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

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.

main-uf2 Download

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