FTDx10 & Fedora Linux

April 25, 2026 VE5NDK Nathan

FTDx10 & Fedora Linux

I have become increasingly frustrated with Microsoft and windows, their forcing steep hardware requirements for windows 11 that forces people to abandon/throw away perfectly good computers in order to run windows 11, their forced requirement of needing a microsoft account to log into windows rather than a local account, their regular system breaking updates and their shoe-horning of AI into every part of Windows.

I had taken a look at all the software I need and the current state of linux and decided it was time to move to linux full time for all my computing needs.

My favorite distributions of linux are Debian Minimal KDE and Fedora KDE. I am currently running Fedora 43 KDE.

My Rig

I have also recently purchased a Yaesu FTDx10 and have started interfacing that with my linux computer. The interesting thing with linux is there are typically no drivers to install, they are built into the system.

Connecting to Linux

I was able to just plug my radio into the PC and received a pop-up notifying me of the new hardware. But I needed to verify the port so that I could select the correct one in the software I will be using.

ve5ndk@Lighthouse > ~> lsusb

I unplugged the usb cable again, ran the lsusb command to see everything connected to the machine, then connected the usb cable and ran lsusb a second time and took note of the differences.

Bus 002 Device 007: ID 0424:2512 Microchip Technology, Inc. (formerly SMSC) USB 2.0 Hub Bus 002 Device 008: ID 10c4:ea70 Silicon Labs CP2105 Dual UART Bridge Bus 002 Device 009: ID 08bb:29c3 Texas Instruments PCM2903C Audio CODEC

These are the entries that correspond to the radio connection. The Silicon Labs CP2105 is the one we are interested in. So we run another command to find the port. We are going to run the dmesg command.

ve5ndk@Lighthouse > ~> dmesg CP210x ttyUSB0 ttyUSB1

The dmesg (diagnostic messages) command is a core Linux utility used to examine and control the kernel ring buffer. It is primarily used for troubleshooting hardware detection, driver initialization, and low-level system errors.

There will be alot of information, I scrolled to the bottom of the output to find the recent entries, and listed only the one that interests us. The CP210x ttyUSB0 ttyUSB1. These are the port names, similar to Com ports regular and enhanced on windows. Ports are in the /dev folder in linux, so /dev/ttyUSB0 and /dev/ttyUSB1.

Next step setting up rig control.

Setting up Rig Control

I chose to use rigctld which is part of hamlib library. It acts as sort of a router for incoming connections to your radio.

We need to find out the rig number for the radio we are using so we run the rigctl -l command to list them all and find the entry corresponding to the unit we are trying to connect to.

ve5ndk@Lighthouse > ~> rigctl -l 1042 Yaesu FTDX-10 20241118.9 Stable RIG_MODEL_FTDX10

For the FTDx10 we can see that our rig number is 1042.

We need to run the command sudo rigctld -m 1042 -r /dev/ttyUSB0 -s 38400 -p CAT

sudo – tells the service to run as root or super user
rigctld is the service / command we are running
-m 1024 specifies my yaesu ftdx10
-r /dev/ttyUSB0 specifies the port (in windows this would be com 5 or similar)
-s 38400 specifies the baud rate
-p CAT specifies the control method

This worked, I was then able to go to my logging software, Qlog, and complete the setup in order to connect to the radio. In Qlog you go to Settings > Equipment > Rigs and define a new profile for the radio you want to use. You give the profile a name, select the interface, in my case I choose hamlib and then Hamlib NET rigctld. You choose your features you want access to and then at the bottom you are given a spot to put your hostname and port, this is where rigctld is running.

In my case rigctld is running on the same machine as Qlog, and other software I will be running. We enter localhost or 127.0.0.1 as the address, and the default port is 4532.

After saving this and leaving settings I was able to connect. I tested a few things out and this seemed to work, however, I needed to leave the terminal window open to keep the rigctld service running and I would need to run the command everytime I wanted to use rig control. Well on linux you can also setup to run the command as a service, automatically, and every time your computer starts. Let’s set this up!

Running rigctld as a Service

Ok, so in order to run rigctld as a service we must first define the service in a file, with the options we need, then start the service to test it out and check its status, if everything is working great we can enable it to always run in the background.

Let me show you how we do this.

We start with creating a file using a text editor, i will use nano, it is what I am familiar with.

ve5ndk@Lighthouse > ~> sudo nano /etc/systemd/system/rigctld-ftdx10.service

We need to run the command with superuser permissions as we are going to write the file rigctld-ftdx10.service to /etc/systemd/system/ which is not writable without admin permissions.

This will open the nano editor, and we need to paste in or type in the following. You can copy by highlighting this text and pressing ctrl-shift-c and then paste into nano or other editor with ctrl-shift-v.

[Unit] Description=rigctld Hamradio rig controller - Yaesu FTDx10 After=syslog.target network.target [Service] Type=simple ExecStart=/usr/bin/rigctld -m 1042 -r /dev/ttyUSB0 -s 38400 -p CAT ExecReload=/bin/kill -HUP $MAINPID RestartSec=60 Restart=always User=rigctld Group=rigctld [Install] WantedBy=multi-user.target

Lets explain the above code.

[Unit]
Description=rigctld Hamradio rig controller – Yaesu FTDx10
After=syslog.target network.target

In the [Unit] section the description line is just that, lets us define the description for the system, this can be anything. The second line After= specifies that the syslog.target (system logging services) and network.target (networking system) should be up and running first before starting rigctld as a service.

[Service]
Type=simple
ExecStart=/usr/bin/rigctld -m 1042 -r /dev/ttyUSB0 -s 38400 -p CAT
ExecReload=/bin/kill -HUP $MAINPID
RestartSec=60
Restart=always
User=rigctld
Group=rigctld

In the [Service] section we define the details of the service.

Type=simple, specifies the type of service.

ExecStart=/usr/bin/rigctld -m 1024 -r /dev/ttyUSB0 -s 38400 -p CAT defines the path to the command we want to run and the run time parameters, this is the same as the initial command we ran above.

ExecReload=/bin/kill -HUP $MAINPID
RestartSec=60
Restart=always

These lines are responsible for killing the process and restarting it if there are issues.

User=rigctld
Group=rigctld

These lines tell the system to run the service as the rigctld user and group with the permissions that they have. You may have to ensure that the rigctld user belongs to the dialout group.

In the [Install] section we have the following:

[Install]
WantedBy=multi-user.target

This just says the machine needs to be in a specific run level, where most system services are up and running.

OK, so now that we have gotten that all into our file we need to save it. In nano we save the file by pressing ctrl + O, which writes out to file, we press enter to accept the file name. then we press ctrl + X to exit nano.

Running the Service

To run the service we call systemctl command.

ve5ndk@Lighthouse > ~> sudo systemctl start rigctld-ftdx10.service

We have started the service and now we need to check that it has run correctly and started with no issues. We do that by running the command again but this time with status instead of start.

ve5ndk@Lighthouse > ~> sudo systemctl status rigctld-ftdx10.service

This shows us the service is running, we can try to connect from our software like Qlog, WSJT-x, etc..

If all is working, we can enable the service to automatically run. We do this by running the command again but swapping in enable instead of start or status.

ve5ndk@Lighthouse > ~> sudo systemctl enable rigctld-ftdx10.service

Thats it, each time you start your computer the service is running.

Testing it Out!

So I fired up Qlog, connected to the radio, then fired up WSJT-x, and configured that and connected to the radio.

I made some FT8 contacts, and at the end of each of the successful contacts, it prompted me to log the contact and it showed up in Qlog.

It worked flawlessly, or so I thought.

Small Snag

While I was operating on 40m and 20m, I had the radio setup with 40m on VFOA and 20m on VFOB so I could switch between them while hunting for people calling CQ.

What I noticed was that whatever mode VFOA was set to, the mode would not change when switching to VFOB. EG:// on 40m the mode is LSB and even though on VFOB, I had it set to 20m and USB for the mode, it would not change in Qlog and if I logged the contact on VFOB it would have the wrong mode set, further if I changed the mode in Qlog it would change the mode one both VFO’s at the same time.

I was not sure if the issue was with Qlog or with hamlib library. I decided to submit a bug request on the github page for the Qlog software project and in the mean time I just logged the contact and then edited it afterwards to ensure the correct mode for the band I was operating on.

Github response:

Since I don’t have this rig, I’m afraid I can’t easily help you. QLog displays whatever it receives from Hamlib. If I were you, I would try connecting to your rigctld via telnet and sending the command m. At the same time, I would have QLog running and connected. If the result of the m command and what QLog shows differ, that’s suspicious.

In general, QLog calls a Hamlib function equivalent to “get mode”; if Hamlib reports this unexpectedly, there is nothing QLog can do about it.

Another thing to try is disabling Split mode (if you have it enabled). Based on experience with the current development branch of QLog, Split can have unexpected side effects with some rigs, and unfortunately, it is not a QLog issue.

Last but not least, you didn’t mention which version of Hamlib you are using. That can also play a significant role.

He responded extremely quickly and cleared up how Qlog functions, which pointed me to hamlib being the culprit.

In the meantime, another contributor on github started testing out what I had submitted, he confirmed the issue I had reported and confirmed the issue with hamlib.

He provided some code for a work around and the maintainer for Qlog implemented the work around in commit f157fd0.

You can follow at the following links on github:

Hamlib rigctld switching between VFO A/B doesnt change the band mode
Qlog Commit f157fd0