Wouxun KG-UV9K Purchase


For some time I’ve wanted a full duplex 2m/70cm handheld so I could have a go at working the LEO FM satellites during the summer months from the garden.

Searching through all the handhelds available today I came across the Wouxun KG-UV9K dual band, full duplex VHF/UHF radio.

Since I already own a Wouxun KG-UV980PL Quad bander (6/4/2m & 70cm) I’m familiar with the menu system and the very good build quality so I decided to research it further.

Wouxun KG-UV9K Full Duplex Hand Held
Wouxun KG-UV9K Full Duplex Handheld

Looking at the spec for the handheld it does everything I want and more whilst being reasonably priced.

Jumping onto the Martin Lynch and Sons website I found there were two listings, the radio on its own or the “Pro Pack”.

The radio on its own was £79.00 but, the Pro Pack was only £20 more at £99.00 and came with every option available for the handheld including a programming cable, 2 batteries and a rather nice carry case.

Wouxun KG-UV9K Pro Pack
Wouxun KG-UV9K Pro Pack

The full specification and other details for the “Pro Pack” can be found on the ML&S website but, here’s a brief summary:

Pro pack contains:

KG-UV9K Transceiver with 2 antennas

Two batteries
Two belt-clips
Software and transfer data Cable
Fast charger dock and Power Supply
Hand speaker mic
Battery eliminator
Manual
Wrist strap
Leather case
In-car charger
SMA-SO239 adaptor
Hands-Free kit

Like my Wouxun quad bander the handheld can also be configured as a cross-band repeater, something I’ve not yet found a use for but an interesting feature. Of course being a full duplex radio with two receivers you can listen to signals on 2m and 70cm simultaneously or transmit on one and listen on the other, a feature I’ve wanted for LEO satellite operations.

The radio is really easy to programme using CHIRP and easy to setup via the very logical menu layout. The hand held has a good solid feel to it and I’ve found the battery lasts a good 3-4 days even though I use it to chat with other stations via my AllStarLink node most mornings and the radio is left monitoring all day.

The larger of the two supplied antennas works extremely well having a relatively good gain. I can now easily get into my two local repeaters on 2m & 70cm from within the house, something I’ve never been able to do with my old Retevis RT85 even with a high gain antenna on it.

The receivers in the UV9K are head and shoulders better than that of the Retevis RT85, I’m hearing signals much stronger now and can even get into repeaters that I’ve never even heard on the old Retevis handheld.

The display on the Wouxun is bright and easy to read, even in bright sunshine which is great as I plan to use it outside a lot during the summer months.

The supplied speaker mic gets good unsolicited audio reports on transmit and has clear audio on receive with plenty of volume. The speaker mic doesn’t have any radio control buttons on it sadly, something I really like about the Wouxun UV980PL quad bander as you can control every aspect of the radio without touching the front panel. Would be a nice upgrade for the handheld if it every became available.

Overall I’m really impressed with the Wouxun UV9K Pro Pack. The radio performs very well, comes with every optional extra available and is a bargain at just £99.00.

If you’re looking for a full duplex handheld radio then I recommend you grab the Pro Pack before the offer ends.

More soon …

Xiegu XPA125B Button Press

For some time now I’ve been using my Xiegu XPA125B amplifier with my Hermes Lite 2 + I/O board combo with great success. With the amp changing bands automatically it really is nice to use.

With the multitude of remote controlled smart plugs available today I’ve now got the ability to switch the station on remotely however, there’s been one issue that has plagued me until now and that’s the Xiegu amp doesn’t come on when power is applied to it, you have to press the power button on the front of the amp before it will fire up.

This of course stops me from being able to fully use the station remotely as there’s no one there to press the power button on the amp, until now.

Chatting with Steve, M0XVT he discovered that if the power button is held pressed all the time the amp will come on when power is applied. This then gave me the idea of designing a button press device that I could 3D print and clip onto the front of the amp so that the button is always pressed.

M0AWS Xiegu XPA125B Clip on Power Button Press
M0AWS Xiegu XPA125B Clip on Power Button Press

The Xiegu amp has a very nice flange around the front edge of the amp case that lends itself nicely to clip on a simple button press device as shown above in my 3D design software.

The button press is designed so that the top is put on first and then the bottom is just snapped into place with a gentle push. This makes it easy to get on and off without marking the amplifier.

M0AWS Xiegu XPA125B Clip on Power Button Press
M0AWS Xiegu XPA125B Clip on Power Button Press

In just a few minutes I had the button press design uploaded to my Bambu Lab A1 Combo 3D printer and in no time at all the button press was ready for use.

As you can see in the photo above it fits snugly to the front of the amp gently holding the power button in so that the amp comes on when power is applied. Simple but, effective.

I’m sure I’m not the first person to have this problem and so, I’ve made the .STL 3D print file available for download below.


I hope this is of use to people who want to be able to use their Xiegu amp remotely without leaving the power on all the time.

More soon …

Node-Red APC UPS Dashboard

Living in a rural area we have a very unreliable mains power supply and so I have to protect all the IT equipment in my home lab with an uninterruptible power supply (UPS).

Over the years I’ve found APC UPSs to be super reliable and use them extensively around the house to keep important services running during power outages.

Running a combination of Debian and Ubuntu operating systems on my servers and virtual machines (VMs) I’ve always used the apcupsd daemon to interface with the UPS for automated shutdowns etc.

The apcupsd daemon does have a very simple web interface that can display 3 items of information at a time but, I decided it would be nice to have a view showing all the information on one dashboard.

Node-Red APC UPS Flow
Node-Red APC UPS Flow

The Node-Red flow is pretty simple and is based around the apcrequest node that connects directly to the apcupsd service on port 3551.

Note: You must configure the apcupsd service as a NIS server in the
/etc/apcupsd/apcupsd.conf config file.

Most of the info is collected via the apcrequest node however, I found that getting the events information via the node to be unreliable and so I used a BigSSH node to connect to the computer to get the UPS events information directly from the log file.

The simple flow collects the data, formats it into a useable format and then passes the data on to the dashboard GUI objects for display, it really is very simple.

Node-Red APC UPS Dashboard
Node-Red APC UPS Dashboard

The resultant dashboard clearly displays all the information needed including line voltage over time. I was surprised to see such a swing in the incoming voltage but, now understand why I get so many low line voltage and over voltage events on the UPS.

The events log is displayed in a scrolling text area on the dashboard with colour highlighting.

If you’d like to create a dashboard for your APC UPS then the flow can be downloaded below.


More soon …

Sign the partition to allow UK HAMs to put up antennas

There’s a new partition that has been started in the UK to allow UK licensed radio amateurs to install antennas and masts without planning permission.

https://petition.parliament.uk/petitions/755675

Partition to allow UK Radio operators to install antennas and masts.
Partition to allow UK Radio operators to install antennas and masts.

If you’re reading this and are a licensed UK Amateur Radio operator please click the link above/below and sign the partition so that we may highlight the subject with the UK government as the RSGB has failed to do this for us for decades now even though members keep asking them to do more on the subject.

https://petition.parliament.uk/petitions/755675

More soon …

Node-Red ADIF to Log Map Flow

Following on from my previous article on using Node-Red to build interactive log maps I’ve now reworked the flow to make it more efficient with less Javascript.

The original flow had a function that handled the issue of FT4 contacts being recorded in two different ways depending on which app you use for your FT4/8 operations.

<mode:4>MFSK <submode:3>FT4
or
<mode:8>MFSK FT4

The code I wrote to handle this wasn’t particularly elegant and so I decided to remove the code entirely and just use a simple change node.

M0AWS New node to handle FT4 more efficiently
M0AWS New node to handle FT4 more efficiently

This is the great thing about Node-Red, there’s always more than one way to do something.

With this fix in place and the old code stripped out of the format generic payload function, the new flow is much tidier and easier to comprehend.

M0AWs Updated ADI Log Map flow
M0AWs Updated ADI Log Map flow

With testing complete and the two maps now live on my website the flow is finally ready for release into the wild.

If you fancy presenting your ADIF logs in a more visual, interactive format then just download the flow below and import it into your Node-Red flow editor.


Don’t forget that you will need to change the path to the log files in the file read nodes to suit your setup and change the location data in the My QTH trigger to match your callsign and location. Other than this the flow should just work.

More soon …

Using Node-Red to build interactive log maps

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
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 SSB / CW / FreeDV Interactive Log World Map
M0AWS Interactive Log Map Layers Menu
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 layer menu 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
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
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.

More soon …

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

FreeDV Transmit Audio Settings
FreeDV Transmit Audio Settings

PiHPSDR Transmit Audio Setting

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

PiHPSDR Transmit Audio Settings
PiHPSDR Transmit Audio Settings

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.

PiHPSDR Receive Audio Setting
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.

FreeDV Receive Audio Settings
FreeDV Receive Audio Settings

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 …

Virtual Machines on RaspberryPi 5

RaspberryPi computers are now moving into the realm of being powerful enough to replace the traditional desktop PC. My most recent purchase, a RaspberryPi 500+ is proof of this as it has been my daily desktop PC since it’s arrival.

One of the things I use heavily are virtual machines. They’re great for developing, prototyping and running new services. With the ability to snapshot, rollback and backup in an instant, virtualisation helps to reduce the development and test time for many of the programs and services that I’m playing with.

With RaspberryPi computers now supporting 16GB of RAM and M.2 SSD drives there is no reason for not taking advantage of virtualisation.

To this end I decided to test running some virtualised loads on my new 500+ with the plan to deploy to 16GB Pi5’s with SSD drives in place of more expensive Intel based computers.

On my Intel based machines I use QEMU, KVM and Virt-Manager to manage the multitude of virtual machines (VMs) I have running here. Since this is a solid, high performance platform for running VMs I decided to take the same route on the 500+

Installing the necessary packages is extremely simple, just one simple apt command:

sudo apt install qemu-kvm libvirt-daemon-system libvirt-clients virt-manager bridge-utils

Note: If you’re using Debian 13 (Trixie) then the apt command to use is:

sudo apt install qemu-system-arm libvirt-daemon-system libvirt-clients virt-manager bridge-utils

The qemu-kvm package doesn’t exist in Debian 13 and so you have to replace it with the qemu-system-arm package.

To be able to create and run VMs you need to add yourself to the libvirt and libvirt-qemu groups.

sudo usermod -a -G libvirt your_username
sudo usermod -a -G libvirt-qemu your_username

Of course you can do it the old-fashioned way by editing the /etc/group file and adding your username to each group.

You’ll need to create a bridged ethernet device for the VMs to use to access the ethernet interface on your RaspberryPi.

If like me you don’t use NetworkManager the easiest way to create a bridge is to define it in your /etc/network/interfaces file.

For this example I am using an IP Address of 192.168.0.100, gateway on 192.168.0.1 with a netmask of 255.255.255.0 and DNS nameserver on 192.168.0.5.

The normal entry in the interfaces file would look like this:

# Main ethernet
auto eth0
iface eth0 inet static
address 192.168.0.100
netmask 255.255.255.0
gateway 192.168.0.1
dns-nameservers 192.168.0.5
dns-domain lan.local
dns-search lan.local
#
#

To create a bridge this entry needs to change to:

# Main ethernet
# Setup Bridge called br1 on eth0
allow-hotplug eth0
iface eth0 inet manual
auto br1
iface br1 inet static
address 192.168.0.100
network 192.168.0.0
netmask 255.255.255.0
broadcast 192.168.0.255
gateway 192.168.0.1
dns-nameservers 192.168.0.5
bridge_ports eth0
bridge_stp off
#
#

Once this is done reboot your RaspberryPi and check you have access to your local LAN and of course the internet. You will now also inherit the two new groups that you added yourself to above.

Note: If you are using NetworkManager open the network settings app and create a bridge on eth0. You can also use the nmtui copmmandline app if you prefer.

At this point you’re ready to create your first virtual machine.

It’s important to have an arm64 version of Linux in ISO format that you can use to install into your VM. My preferred distro is Debian and so I downloaded the Debian 13 Arm64 netinst ISO from the debian.org website.

From the main menu start “Virtual machine Manager” or on the commandline type:

virt-manager
QEMU Virtual Machine Manager
QEMU Virtual Machine Manager

Click the Create new VM button and then navigate to where you saved your ISO file and select it as the installation media.

Virtual Machine Manager - Local install media
Virtual Machine Manager – Local install media
Virtual Machine Manager - Select ISO file
Virtual Machine Manager – Select ISO file

Once you’ve chosen your ISO you’ll need to configure the actual VM. Start by setting the amount of RAM and number of virtual CPUs you want the VM to have.

Virtual Machine Manager - Configure RAM and CPU
Virtual Machine Manager – Configure RAM and CPU

Next set the size of the virtual disk that the VM will use.

Virtual Machine Manager - Create virtual disk
Virtual Machine Manager – Create virtual disk

Finally, give the VM a name and set its network device to br0 as created above. Click finish and your VM will boot.

Virtual Machine Manager - Name VM and select bridge interface
Virtual Machine Manager – Name VM and select bridge interface

Now it’s just a case of going through the standard Debian install process to build your Debian VM.

Virtual Machine Manager - Boot ISO
Virtual Machine Manager – Boot ISO
Virtual machine Manager - Running standard Debian install
Virtual machine Manager – Running standard Debian install

Once the installation is complete and the VM has rebooted you will have a functional Debian computer ready to use for whatever you like, just like a physical PC but, in virtual form. You’ll find that the VM runs as fast as the actual physical machine thanks to the kernel based virtualisation.

Virtual Machine Manager - Running VM
Virtual Machine Manager – Running VM

For more information on Virtual Machine Manager take a look at the Ubuntu Server documentation.

More soon …

Coding a new version of adi2html in Python3

I’ve spent some considerable time of late coding a new version of adi2html that I use to convert my ADIF log files into online web pages for all my HAM Radio logs.

The old version that I wrote quite some time ago was written using BASH shell which was quick and easy at the time but, as the logs grew in size it got slower and slower to process the ever increasing number of log entries.

Now I’m retired I have the time to revisit these things and write better, more modern versions of my various programs that run silently in the background.

Writing the new version of adi2html in Python3
Writing the new version of adi2html in Python3

It’s taken a little over a week to put this code together, test and debug it, I don’t like to rush these things!

I’ve finally put v1.2 into production today.

The 585 lines of code produce a very nice, modern looking web page and can be used to convert any ADIF file into HTML. The code is extremely quick, taking less than a second to process almost 2500 log entries, a huge improvement over the old version of adi2html.

New look M0AWS Log web page
New look M0AWS Log web page

All of my logs are available here on my blog under the Logs menu above, feel free to have a look at them.

I now need to rewrite the log search functionality so that it uses the same format of presentation for the results.

More soon …

RaspberryPi OS 13 Networking tidy up & broken lm-sensors

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

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

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

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

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

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

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

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

sudo apt install ifupdown

Step 2 – Disable NetworkManager:

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

(Optional but tidy: )

sudo apt purge network-manager

Step 3 – Disable Netplan

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

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

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

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

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

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

Example for DHCP:

auto eth0
iface eth0 inet dhcp

If you use Wi-Fi:

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

Step 5 – Enable the traditional networking service

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

Then confirm:

ip a

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

Step 6 – (Optionally) Clean residual files

Remove leftover NetworkManager/Netplan configs to avoid confusion:

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

Verification

Check which subsystem is active:

systemctl is-active NetworkManager
systemctl is-active networking

Expected output:

inactive
active

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

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

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

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

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

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

# Loopback
auto lo
iface lo inet loopback

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

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

Check both IP Addresses appear on the same interface:

ip a show eth0

For the example above you’ll see:

inet 192.168.1.10/24
inet 192.168.1.11/24

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

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

vcgencmd measure_temp

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

alias cputemp="vcgencmd measure_temp"

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

More soon …