The Switch to Linux

For those with eagle eyes, you may have noticed a couple of things a little off about my latest computer screenshots – the use of flrig and different looking menus on the apps. As mentioned, I have now moved my radio shack computer from Windows to Linux.

Why Change?

Things really reached a tipping point earlier this year when it became apparent that the existing desktop running windows 10 would not support Windows 11 due to the CPU model. No matter what tips and tricks I tried to bypass the TPM & CPU checks, the installer just refused. With security patches no longer available from October this year and also a security professional for my day job, I had little desire to have an unsupported device on my home network.

This was not the only reason. I’ve also been growing more and more uncomfortable with Microsoft’s push to force the use of a Microsoft Account to use Windows 11 and more concerning is the roadmap that heavily leverages the use of Copilot and other controversial features. I am very much against the current “AI hype train” and the peddled belief that ChatGPT, CoPilot, and DeepSeek are going to save the world.

Finally, with development of Ham Radio Deluxe apparently stagnating and the availability of a viable alternative, it was time to make the switch.

Which Linux Distribution to Run?

There are literally hundreds of linux distributions to choose from, usually tailored around package manager, hardware support and optimisations. There are even a handful of distributions that are made for amateur radio.

For me though, my choice was one of the earliest Linux distributions: Debian

  • Debian has a slower release cycle compared to some other desktop distributions like Ubuntu and Fedora. I don’t particularly want to be needing to do a major system update every year. Debian releases are typically every 3 years, with 5 years Long Term Support available.
  • Debian is incredibly stable both as an OS and with it’s software packages. Having had nightmares under Linux Mint of applying software updates to ham radio apps in the past under linux, only to have them stop working and needing to be re-compiled from source code to make work again, having software stability is important
  • Debian uses the “apt” package management system, which I am already very familiar with
  • Debian runs headless via RDP without a noticeable performance hit. While testing distributions, I found some distributions relied on graphics hardware acceleration, and when the graphics card was not activated by a detected monitor, the whole computer would turn to molasses in performance.
Photo of my radio Shack.

Remote access to a GUI desktop for Linux has been important to me, as my radio desk typically has no room for a monitor + keyboard + mouse, meaning I typically access my radio from my main computer in the home office, or with the use of a tablet mobile device.

(don’t be fooled by the desk – that workspace is only big enough for a 15″ laptop screen. I had thought about getting one of those “portable monitors” seen recently, but there would be very limited space on for a keyboard/mouse after that.

The Alternative Apps

I think everyone appreciates that it is rare to be able to pick up an application from windows and be able to use it straight up in Linux – though there are some tricks to maybe achieve this. Alternative applications needed to be found:

Windows AppLinux App
Rig ControlHRD (Rig Control)flrig + hamlib
Log BookHRD (Log Book)Wavelog
Traditional Digital (RTTY, PSK)HRD (DM780)fldigi
Satellite TrackingHRD (Sat Tracker)gpredict
Weak Signals (WSJT-x)wsjt-x + GridTrackerwsjt-x + GridTracker
SSTVMMSTVQSSTV
Logbook of the World (LotW)HRD + TrustedQSLWaveLog, TrustedQSL
Contest LoggingVKCL , N1MMWavelog? (TBC)
Packet Radio (AX.25)N/A – External TNCN/A – External TNX and/or axtools

Whilst this covers 95% of the applications I use, there are still a couple that will require Windows, but the good news there is that they don’t require direct access to radio hardware, so I should be able to run those in a virtual machine on my main desktop:

  • IC-9700 Programmer
  • TYT MD-380 Updater/Programmer (which itself is a VM in virtualbox)

The Linux Experience So Far

Flrig

I would be lying to say it’s been smooth sailing to get this far. Below are some of the observations I have made as part of the transition that have caused some difficulty:

Screenshot of flrig

One of the challenges has been around rig control for multiple rigs and the use of flrig. This has been particularly necessary as the client used by Wavelog for automatic logging requires flrig.

Flrig as an application does not support multiple rigs in one instance, so the application needs to be run multiple times, referencing different configurations. I have have setup desktop shortcuts to do this, with the command:

flrig --config-dir /home/bcshort/.flrig/<radio>

Where <radio> is the name of the radio config folder – e.g “IC9700”

Notably, this also allows me to set up specific ports for XML-RPC servers from flrig, and this becomes important because not all applications support flrig and only support hamlib!

Hamlib

Hamlib in recent years has tended to be the de-facto open-source cat control application for many due to its general ease of use with other applications. However it has no GUI of its own, relying on developers to build the support into their own applications. Notably some developers will only support hamlib, with no flrig support. I have found this a particular issue with gpredict, which is rather important for satellite tracking and doppler shift.

Thankfully, hamlib supports FLrig! so in a roundabout-janky way you can use this command to connect to the flrig xml-rpc server to provide a hamlib interface for those particular applications:

rigctld -m 4 -r 127.0.0.1:<port> &

Where <port> is the flrig xmlrpc port.

In the case of running multiple rigs, you may need to specify separate hamlib listening ports with the -t argument:

rigctld -m 4 -r 127.0.0.1:<port-radio1> -t 4532 &
rigctld -m 4 -r 127.0.0.1:<port-radio2> -t 4533 &

QSSTV

QSSTV is another such application that supports hamlib only, and requires the flrig bridge described above, however it does have a peculiar quirk in that enabling CAT control causes the application to pause every second or so. This is demonstrated in the image below by the “dragging” of the spectrum in the waterfall (highlighted in red):

Screenshot of QSSTV and the dragging effect described as pause in the application.

Right now, the easy workaround is to disable the hamlib CAT control. However, my ability to transmit SSTV remains untested – I can configure PTT by use of the serial port directly, but until I have a need to transmit, I don’t know how successful that will be.

Should that be successful, I don’t actually believe the need for CAT radio control through the application would be necessary, as that can be managed outside of the app with flrig.

Is Linux a Future-proof Solution?

I want Linux to be a future-proof solution for amateur radio operations, but it too is not without it’s challenges.

I feel like the linux amateur radio community is still rather niche and as a result is a limited amount of developers doing a limited amount of work in maintaining and creating radio related applications. These limitations are resulting in the existing applications becoming anachronistic behaviour and UI. This creates a feedback loop of less people wanting to use the app, so less development effort is made.

The adage of “you get what you pay for” definitely rings true. As a non-developer, I am forever appreciative of the work of those who do maintain and develop applications for the community at no cost. Coding is hard.

Being a smaller community, There are some core projects where there is no contingency where the project owner stop developing. Such is the case of gpredict, which appears to be the only satellite tracking software of it’s kind under Linux, but has not had a new release since 2018. While you can argue the software can be forked – it’s unclear whether any new features or bugfixes will ever be merged into the current branch.

However, massive leaps are being made in other areas that support the linux community – we’ve already seen containerisation and cloud services bring rise to web based logging and significant development happening in this area. Similarly as software defined radio hardware grows in popularity, we’re seeing more and more work going in to provide applications and support for these devices.

Even Ham Radio Deluxe has Linux support on their roadmap. This would significantly lower the entry bar for most users to start using Linux as their primary radio OS.

I think the next 5 years will be particularly telling for the Linux radio community as to whether Linux can break out of its niche and become a viable desktop environment for the everyday amateur operator.

Closing Thoughts – The Journey Has Only Just Started

With Wavelog giving me the means to unshackle myself from logging with Ham Radio Deluxe and with alternative software being generally available for most of the things that interest me, Linux has become a viable option in the radio shack again.

There are still challenges in moving to Linux though and unless you are ready to dive deeper into troubleshooting, you might find yourself in a world of pain pretty quickly. Amazingly this has not changed in the last decade since I last attempted to use Linux in the shack.

I did say my journey has just started, and thats because there is still a lot of work to do to make the computer truly feel like something I am comfortable in using. My next steps also require me to start making things available such as SSTV images to transmit, setting up other applications (like the web browser) properly, and ensuring that I can back up the computer in the event of a hardware failure.

This however is a start, and hopefully the beginning of new friendship.