SoundCard – M0AWS Amateur Radio

23 August 2026

Building MB7IBW 2m AllStarLink Internet Gateway

I’ve recently built another AllStarLink node to compliment my personal 70cm band SHARI node as I thought since I have a full duplex dual band handheld it would be great to have another node that I could connect to FreeStar or HUBNet at the same time as monitoring the Matrix node.

Rather than build another personal node I decided this time I would build a public node, obtain a callsign from the RSGB and make it available to the HAM’s locally on the 2m band.

This would make it possible for me to monitor both nodes at the same time using my Wouxun KG-UV9K full duplex dual band handheld whilst providing the local HAM community with access to the AllStarLink network.

Initially I thought I may be able to use my old Retevis RT85 handheld and AIOC board for the 2m node but, after a little testing it soon became apparent that it overheats during long overs (which are common on AllStarLink) and so, I needed to find another solution.

Chatting about this in the main Matrix HAM Radio room Steve, M0XVT sent me a message saying he had an old Key KM-4000 converted PMR radio that had been reprogrammed for the 2m band that he was looking to sell and that it might be ideal for the new node. Wasting no time, we came to an agreement and I was soon the proud owner of a converted PMR transceiver.

The KM4000 transceiver has a standard output of 15w, 10w more than I needed for the gateway and so I had to reduce the output. A quick search on the internet and I found the Thames Valley Repeater Group website that had all the information required to turn down the output.

I also had to reprogramme channel 1 to the frequency and CTCSS tone allocated to me by the RSGB so that in the event of a power outage when the radio came back on it automatically jumps to channel 1 which would be correctly setup for operation.

Unfortunately the software for programming the radio is only available for windows and so I had to build a virtual machine running windows 10 to be able to reprogramme the radio.

Once this was done I rewired the AIOC USB audio device to work with the KM4000 radio and built the AllStarLink node on a spare RaspberryPi 4.

For an antenna I made a simple end fed vertical dipole from some RG58 coax and mounted it 8m up on one of my Spiderpoles in the garden. Running a coax feed out to the antenna I did some tests into the Parrot to get the audio levels setup and checked that the DTMF codes were interpreted correctly and that the node switched connections without error.

MB7IBW Internet Gateway hardware at the M0AWS QTH

Once this was done I had a few test conversations with stations on the Matrix node and FreeStar to ensure all was fine and then set the gateway status to “Operational” on the RSGB website.

This worked fine for a while with myself and some local stations using the node regularly but, then the hot weather arrived and things started to overheat. The transceiver was getting incredibly hot in the 30c+ summer temperatures and the power supply was also running extremely hot and so I decided to add some cooling.

Cooling the PSU was simple, it has a perforated top panel to which I strapped a cooling fan. This worked great and brought the temperature of the PSU down considerably.

The radio wasn’t so easy to cool. It has a solid case cover top and bottom and so cooling wasn’t going to be a simple affair.

I decided to remove the covers and drill some holes into them to allow airflow through the unit and strapped a fan to the top cover to pull the hot air out. This worked well however, on both transmit and receive I now had a warbling sound on the audio that was caused by the motor of the fan when powered up.

I found that lifting the fan up away from the case of the radio the warbling audio disappeared and things were back to normal and so, I decided to design a cooling tube to fit to the top of the radio to allow full airflow from the fan but, with the fan raised up away from the radio to resolve the audio problem.

Jumping into my CAD software I quickly designed a cooling tower to fit on the top of the radio that would allow the fan to sit far enough away from the radio so as to not affect the audio whilst at the same time pulling the hot air out of the radio and drawing cooler air in through the bottom of the case.

I sent the design through to my Bambu Lab A1 Combo 3D printer and set the print job running.

The cooler worked great with the radio staying cool to the touch and no longer overheating and reducing O/P power.

It’s amazing how much dust and dirt is in the air from all the farming activities going on at the end of our garden and how much of it is sucked in by the cooling fan. Regular cleaning is a must!

The MB7IBW Internet Gateway has been on air since mid June 2026 and has worked well. It spends most of its time connected to either FreeStar or HUBNet with connections to the Matrix Node when we have our nets.

Details on Frequency, CTCSS etc can be found under the MB7IBW menu above.

Sadly the initial interest from local HAMs has now wained and I am mostly the only user of the gateway. I was hoping more people would use it and bring some life to the 2m band, I guess time will tell.

It’s been a fun project and was interesting to go through the callsign allocation process with the RSGB representative. It was much easier than I thought it would be.

I now have all the parts to build another Internet Gateway for the 4m band. Hopefully that may attract some more interest. It’s certainly worth a try!

More soon …

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 …

14 December 202515 December 2025

FreeDV audio routing with PiHPSDR and Hermes Lite 2

I’ve recently been trying out the FreeDV RADEv1 digital voice mode on the HF bands with great success. The audio quality is astounding when compared to the normal analog SSB mode. Using only 20w I’ve been surprised how successful I’ve been talking to stations in the UK and Europe as can be seen in my FreeDV Log.

FreeDV has been around for quite a few years with development being funded by an ARDC grant and financial sponsorship from the Software Freedom Conservancy.

So what is FreeDV?

To quote the FreeDV website:

“FreeDV is a suite of digital voice modes for HF radio. Our flagship mode is the Radio Autoencoder (RADE). You can run RADE using a free GUI application for Windows, Linux and macOS that allows any SSB radio to be used for high quality digital voice.“

And the most important part:

“All software is open source, released under the (a) GNU Lesser Public License version 2.1 (GUI and legacy FreeDV modes) and two-clause BSD license (RADE).“

FreeDV running under KDE-Plasma on Kubuntu PC

Looking at the digital voice (DV) community in the HAM Radio world, it’s stuffed full with proprietary DV modes from small software houses and black box transceiver manufacturers with no real OpenSource alternatives, until now.

Installing FreeDV is pretty simple regardless of which operating system (O/S) you use. Being a Linux user I grabbed the AppImage from the website and set about reading up on how it works and how it is configured.

I decided to take the two sound card approach since I have 2 USB sound cards connected to my shack Kubuntu Linux PC.

Configuring the audio routing isn’t straight forward as both the receive and transmit audio to/from the radio needs to be routed via the FreeDV app. To make this even more complicated I am using my Hermes Lite 2 SDR transceiver and PiHPSDR software, a complete OpenSource/OpenHardware Amateur Radio Station.

M0AWS FreeDV and PiHPSDR Audio Routing Diagram

Trying to clearly describe the audio routing using words alone would be impossible and very confusing so, I put together the diagram above.

Using two USB sound cards I’ve configured the system such that USB Sound Card 1 (an old Griffin iMic USB sound device) handles just the audio from/to the headphones and microphone. All the audio at this point in the system is analogue.

The second USB sound card, a cheap Plug and Play (PNP) USB audio device from Amazon, handles all the digitised signals from/to FreeDV and PiHPSDR.

Taking this 2 sound card approach keeps confusion to a minimum and separates the analogue and digital components of the audio routing.

So, how does this translate to the FreeDV and PiHPSDR audio settings?

Transmit Audio Chain

FreeDV Transmit Audio Settings

Starting at the beginning of the transmit audio chain, let’s look at the transmit audio settings in FreeDV.

Looking at the FreeDV Transmit audio settings screenshot below we can see that the
Input From Microphone to Computer device is set to:

alsa_input.usb-Griffin_Technology_Inc_iMic_USB_audio_system-00.analog-stereo

This is the microphone connection on the iMic USB device (USB Sound Card 1) and is the analogue transmit audio input to FreeDV.

The Output From Computer to Radio device is set to:

alsa_output.usb-0c76_USB_PnP_Audio_Device-00.analog-stereo

This is the digitised audio output from FreeDV (via USB Sound Card 2) to PiHPSDR and is used as the transmit audio that is sent to the Hermes Lite 2 transceiver.

PiHPSDR Transmit Audio Setting

To complete the transmit audio path we next need to look at the PiHPSDR transmit audio setting.

As can be seen in the screenshot above, the Local Microphone device in PiHPSDR is set to the Monitor of USB PnP Audio Device Analogue Stereo.

This effectively routes the digitised output audio from FreeDV (Output From Computer to Radio device) to the Input audio of PiHPSDR.

The reason for using the Monitor audio feed is because FreeDV does not recognise the Mic Input in PiHPSDR as a valid output device for FreeDV to use, hence we just need to monitor the FreeDV output device and use it as our input audio device in PiHPSDR.

This completes the transmit audio chain.

Receive Audio Chain

PiHPSDR Receive Audio Setting

Starting at the beginning of the receive audio chain we first look at the PiHPSDR receive audio setting.

In the screenshot above we can see that the receive audio output from PiHPSDR is set to
USB PnP Audio Device Analogue Stereo (USB Sound Card2). This is the DX station’s digitised audio as received by the Hermes Lite 2.

FreeDV Receive Audio Settings

Next let’s look at the receive audio setting in FreeDV.

The Input To Computer from Radio device is set to the monitor of the
USB PnP Audio Output Device:

alsa_output_usb_0c76_USB_PnP_Audio_Device-00.analog-stereo.monitor

This effectively routes the digitised audio output from the PiHPSDR receiver to the digitised audio input of FreeDV.

Once again we have to use the monitor of the USB PnP Audio Output device as FreeDV does not recognise the PiHPSDR output as a valid input device.

Next, the Output From Computer To Speaker/Headphones device is set to:

alsa_output.usb-Griffin_Technology_Inc_iMic_USB_audio_system-00.analog-stereo

This is the analogue audio output on the iMic USB Sound card (Sound Card 1) that routes the analogue audio to the headphones and completes the receive audio chain.

Summary

The audio routing required by FreeDV can appear very daunting when first attempting to configure it on the Linux platform but, hopefully the diagram and screenshots above will help in understanding the complete end-to-end audio chain that is required to make this mode work.

PiHPSDR can of course be replaced by your black box radio CODEC entries that will appear in the device lists shown above if you have your radio connected via USB. The config is basically the same but, just uses a different device instead of USB sound card 2 shown in the diagram above.

I hope this article is useful to those wanting to try FreeDV on the Linux platform and I look forward to hearing you on RADEv1.

More soon …