Hamlib or Flrig or Omnirig for Transceiver CAT Control?

	
Topic	Hamlib or Flrig or Omnirig for Transceiver CAT Control?
Subtopic	CAT Control via TCP
Equipment Required	Computer + Internet + your Ham workstation
Costs	You should already have the equipment
Document last reviewed and updated (reviewed each year)	3rd September 2023 – tested all Instructions for accuracy
	

Introduction

After you have been involved with Amateur Radio for while, you are starting to look for the improvements in efficiencies bringing much of the software together to work with each other. If you have not already, you will realise that Transceiver control utilising CAT (Computer Aided Transceiver) becomes the central part of this. By now you have come across the names Flrig, Hamlib, Rigctl, Omnirig and a smattering of others.

For many of you, especially those getting into FT8, the most common “connection” you will make is WSJT-X direct to your transceiver via a COM port.

After a while you will realise that you can setup Flrig as your middleware software, and have WSJT-X talking via Flrig to your Transceiver. You will probably then find then find that you can setup Fldigi to work via Flrig as well. You might find a few other applications that work through Flrig as well. You feel that you have achieved some integration and probably will stop there for a while.

Now to be fair, if that is the path you followed, you are probably a Windows user (nothing wrong – I am a Windows user as well), and found many guides on how to set it up, with simple installation files, no compiling, so in most cases the easiest route to success.

You might have looked at Hamlib, but the documentation left you unsure of the concepts, what the difference is with Hamlib and Rigctl and Rigctld, and web pages that say your rig is supported and others saying it isn’t, and others talking about compiling it. Your eyes glazed over and as you have something working, you decided to look at it later. Just to clear up one thing, Rigctl and Rigctld are parts of Hamlib, even though many articles are written and fail to explain what they are and what they do.

And you probably had a quick look at OmniRig if you are a Windows user, but started becoming confused with version 1 and 2 and some apps only supporting version 1 or only version 2 (although there is an increasing number having both as options), but there are also other apps not supporting Omnirig at all.

I fully recommend the use of Dummy load connected to your Rig whilst you are testing CAT control applications. Whilst you would generally be careful, it is possible that with incorrect serial settings, that it could accidentally transmit at 100W or more. Remember CAT controls the power settings as well.

Selecting the Transceiver CAT Control for you

Now the purpose of this article is not to tell you which one is better, as only you can make that decision, but I will give you some guidelines to point you in the right direction.

Operating Systems supported

Lets look at what operating systems are supported, by each of the popular ones…

Flrig – Windows / Linux / Mac OS X

Hamlib – Windows / Linux / Mac OS X

Omnirig – Windows

Now when I am looking for an application to settle on, I am interested in learning once, developing a deeper understanding of the product, and knowing that I can use that same software on Windows or a Linux system (and the same applies for Mac, but I don’t use Macs). You might think to yourself, that you won’t touch Linux, but you should not discount this. Even using a Raspberry Pi with a prebuilt setup (e.g. DigiPi from KM6LYW or Build-a-Pi from K4ACK) might actually be part of your setup one day.

Applications that are updated and well documented

Another thing to look at is how often these applications are updated, and the rigs that they support…

Flrig – updated within the last 3 months that this article was written and looking through the release notes – updated regularly, documented release notes and almost all rigs supported that support CAT

Hamlib – updated within the last 6 months that this article was written and looking through the release notes – updated regularly, documented release notes and almost all rigs supported that support CAT

Omnirig – Windows – this is not clearly apparent, but the latest omnirig 2.1 exe file appears to be 2019, the ini file for the supported rigs is not as comprehensive as Hamlib or Flrig, and from what I can see, the program ceased development 1.9 and another developer picked it up and released 2.1, but development does not appear be regular, and even the links to the ini file on the site points to nowhere and no release notes appear to be in existance. Also the list of rigs supported seems to be a lot less than Flrig and Hamlib. Whilst many Yaesu and Icom rigs are covered, many others are missing such as the Xiegu and I am sure there are others.

TCP Server support…

Finally there is one more criteria that is worth looking at that is the ability to support CAT Commands over TCP, with the software acting as a Server. Now for some of you, you may not have even looked at this, or knew it was available.

What this means is that you can control you transceiver from your main PC that has your applications on it, or you can control or read your transceiver from another PC. Lets look at some benefits and reasons why this is useful

• Allows multiple applications on one PC to be able to access the the transceiver CAT control e.g.Log book and WSJT-X without COM port sharing errors
• Allows a digital radio application to run on one PC, whilst running a logbook app on another networked PC
• Allows remote control of your rig from another PC
• What’s even better is that FLRIG Net mode is selectable as a rig under Hamlib, and the reverse is the same under FLRIG, Hamlib net mode is selectable, so you can choose what the primary CAT control app you want to use.
• Another benefit you might not have considered is using a device like a Raspberry Pi (or similar), running Hamlib sitting next to your rig, connected by USB to the rig and Networked with applications all applications accessing the rig over the network

This following diagram may help visualise what we are talking about with the two popular scenarios

As the author (David W1HKJ) of the FL range of applications (e.g.fldigi, flrig, etc) stated in one of his forum posts and explains a lot in a couple of sentences.

“If your transceiver is supported by flrig then use it and the xmlrpc server.  Hamlib version 4.0 has an xmlrpc flrig client built-in, so you can pick flrig as the “transceiver”.  That means than any application that can link to hamlib can also use flrig as it’s control agent.  flrig’s xmlrpc server is multi-client.  That means flrig, fldigi, flwkey, wsjtx, etc can all be accessing the transceiver without serial port conflict”

As you can see in the diagram below, we can have several applications all communicating to and from the transceiver via the FLRIG with the XML-RPC Server.

So what is XML-RPC? It is a Remote Procedure Call method that uses XML passed via HTTP as a transport.

Ok so what is Rigctld and how to talk to this? We can do that using almost any language that you can send a command using TCP Sockets and text based commands and this includes Perl / PHP / Python with a typical piece of Perl code being print $socket “F 14250000\n”; which will change the frequency on the rig to 14.250.000MHz.

And if you are not a programmer and want to be involved, Node-RED (if you have not heard of it, another subject in itself), it has wrappers/programming libraries for controlling your rig through Hamlib or XMLRPC via the FLRIG Server.

You can install HAMLib and set this to talk to FLRIG as well, which is great if you have an application that only supports talking to HAMLib

And yes, if your mind is already thinking a couple of steps ahead, if you have applications that just need CAT Control (e.g. no audio), such as a logging application, it can be on a different networked workstation and there applications that can redirect the audio over TCP, so in effect with a Raspberry PI, you could design your own LAN Remote control unit like Yaesu’s add on LAN unit. In fact Build-A-Pi (one of the popular projects) has the ability to install PulseAudio on it which means in theory you can redirect the audio – I personally have not delved that far….but a strong possibility.

However, lets stick to the basics for the moment, which is just reliable, multiple connections from applications, with middleware interfaces that are supported by most applications,and that is the key. This is not going to suit all applications, with users of the latest SSTV Yoniq application being among them, as they chose to support OmniRig only (or using the COM ports direct), so if you do a lot of SSTV, then you will not l need to close your other applications that are using the COM ports.

Personally, I have no interest in running Omnirig as I am interested in future proofing my setup & learning (if possible) and Omnirig does not appear to support further integration like Flrig and Rigctld. That is my personal view, but I support any developer that puts the effort into providing applications like this and that includes Omnirig, it’s even written in one of my favourite languages (Delphi) which I have used since 1983 (before you start looking to see when Delphi was released – I started with Borlands Turbo Pascal on CP/M in 1983 which over time morphed into Delphi).

To see how popular Hamlib is, the following site shows many of the applications we are talking about and how to configure each one to use Hamlib

https://wfview.org/wfview-user-manual/hamlib-rigctld-emulation/

This article is now going to setup both FLRIG and HAMLIB, but not just the basic app but we are going to extend the setup so that the applications run as Servers. If you have already setup FLRIG or Hamlib in their basic mode and have it running, then hopefully you will see how to modify it. If you have not used the applications at all, then these will take you through the install process, but pick one as you can only have one running, otherwise they will compete for the COM port.

Installing and setting up FLRIG

We want to get the latest version of the software, so we need to go to the following URL

http://www.w1hkj.com/

In the list on the landing page, you need to download the latest FLRIG software

Click on NEXT

Leave the Destination Folder as default and click on INSTALL

This will complete the install and leave a FLRIG icon you your desktop

Click on this Icon and you will get the following screen

You will realise that it is pretty inert, you can move the sliders, there are no frequencies showing, no flashing lights. This is because it is not configured, and not connected to your transceiver.

So that is our first step…..

We need to confirm what ports are being used for your Transceiver connection

As per the FT-DX10 manual the ports are used as follows (as per the Yaesu’s technical guide)

“These ports offer the following functions:

• Enhanced COM Port: CAT Communications (Frequency and Communication Mode Settings)
• Standard COM Port: TX Controls (PTT Control, CW Keying, Digital Mode Operation)“

Ok, so it looks like we need to use the Enhanced COM port for CAT control, but you will see that on a computer, this port varies depending on the computer, and its peripherals.

So we need to go into the Windows device manager to determine which COM port is the Enhanced Com port

In this case, it is COM5….so now that we have this information we can proceed.

So lets go to the following menus… CONFIG >>SETUP>>TRANSCEIVER>>XCVR

So as a minimum, we need to set the following items

1. You need to select your rig from this list (this is important to use if it is available as it preconfigures some items)
2. If you started FLRIG first without your transceiver turned on or connected, you may need to click on UPDATE, so it recognises the USB Com ports.
3. You need to select the COM port that is used for CAT control (again, you may need to read your transceiver guides to identify which Com ports you need to use. In the case of the FT-DX10, it uses two Com Ports. One is for the CAT control, and the other is for the Audio
4. You need to select the correct baud rate for you Transceiver. Now this is usually one of two things, either a fixed baud rate that is set at the factory for your transceiver, or one you can set on your transceiver in its configuration menus. Either way is fine, but this baud rate you set in FLRIG must be the sane as your transceiver
5. & 6 … The rest of the numbered settings work for me, you may need to understand what your transceiver requires and set these accordingly

Finally, if you think you have them all right, click on INIT (7) and if it has connected, it will show up Connected with the green Diamond

And under PTT-Generic, you normally leave it as defaults (or should look similar to below

Now I will make something clear, when configuring FLRIG, selecting the right Transceiver, will populate some of the configuration fields for you and usually correct for the transceiver. However if you are trying to use a tranceiver in the configuration that is close enough (as your exact rig is not listed), then you cannot rely on the defaults and need to seek assistance on forums or guides if it does not work for you.

Now I will also provide some advice whilst you are “testing”

1. Stick a dummy load on your transceiver – I can’t stress this enough – whilst setting up, you have very little control (just turning your power down to 5W will not work – FLRIG might by error turn it back to 100W or more)
2. Use a decent USB Lead (note, I have not stated expensive here). It just needs to be USB lead with ferrite “eggs” on both ends. with various rigs over time, the amount of time wasted locating issues due to RF affecting the “cheap” USB leads. As a backup (if you cannot find them) try passing your USB Lead a couple of turns through a clamp-on ferrite core, however nothing beats a decent well built lead with confirmed shielding.
3. If you are testing FLRIG with a transceiver (whether it is well supported or not), perform some rapid changes of frequency on your rig and see if FLRIG keeps updating (note it may lag – but it should not hang and should finally show the final frequency that your rig ended up on. Issues with this may point to your settings incorrect…
4. The next test is clicking on the PTT button on the FLRIG console and confirm your rig goes into TX mode, and immediately click it back again.
5. Finally just run around the FLRIG console testing that all the sliders and buttons create a corresponding action on your transceiver.

These are the two main functions we want to confirm

1. CAT Control via FLRIG
2. PTT Control via FLRIG

Make sure that everything is working before we move forward. If everything is working, we need to make one more configuration change in FLRIG.

Installing HamLib / Rigctl

Go to the URL https://sourceforge.net/projects/hamlib/files/latest/download and click on the download button

At the the of writing, the file name was hamlib-w64-4.5.5.exe

Execute this and it is likely the following windows will appear

Click on MORE INFO

and the following screen will appear

Now, I will state that this warning does come up for a reason and generally its because the app we are running is not “known” by Microsoft and in many cases this will always occur, epecially for applications that are regularly updated and ported from other applications. It is up to you to decide if this has come from a reputable source and whether you want to run it, but in my case, I know what it is and wanted to run it.

So I clicked on RUN ANYWAY

Just install with all the defaults

When it has completed the install, take a read of the README Files that were installed, in particular, the README.w64-bin file which has some pretty important information.

I do not need to repeat the Readme details verbatim, but you need to set some environment variables in Windows

I will state that the readme file is out of date with how to add the environment variable, but you will work your way through it (or at least find some guides on the Internet.

You might be wondering why you did not have to do this for other apps like WSJT-X or more most other installations. You will find this common where an application is available on multiple platforms, quite often originating on a Linux platform and then cross-compiled for other platforms including Windows. This means that it does not come with an installer, (the extra pieces that set environment variables, perform cleanup or check for instances alreadyy running etc). If it does have an installer, it is a generic installer, which includes install directory paths and not much else.

So we have to do a little but sometimes to finish the install, and that includes reading the README files.

So in a nutshell, the executable directory needs to be added as a path for other programs run without having to be told what directory holds the executable files for HAMLIB . I will let you on a secret, even this is not for required for some applications to use hamlib, as their command line may include the exact path, but there is absolutely no issues with using absolutes.

If you want to make sure that you have completed this successfully, open up a DOS Window (cmd.exe)

type path <enter>

You will now notice that the path we added is now part of the path (and semicolons are in place)

And we will do one more test…we are going to run a HAMLIB command from the DOS prompt, without prefixing it with a directory, relying on the path being set correctly.

type rigctl<enter>

If everything is correct, it will request a Rig command…if that comes up, press CTRL-C to stop the program and close the DOS window. We have confirmed the path is correctly set

Now we need to build the rigctl command line with a little bit of research

Confirming your Rig Number

type

rigctl -l

this will list off all the rig configurations compiled in this version of hamlib

We are going to improve on this command by using grep to search for the exact rig I am using (you will look for yours)

rigctl -l | grep FTDX10

This will then provide a small list where I can confirm the correct rig number.

So in my case, the rig number is 1042 – Note this number down (your rig of course) – we are going to need it
If grep is not showing your rig, try the manufacturer instead (e.g rigctl -l | grep Icom)…this will be a longer list to search through…but may assist you finding your RIG

Finding your USB Comm Port

Now plug in the CAT USB Cable from your rig

In windows run devmsc.exe

Now look under Ports and you should see the Virtual ports created by the FTDX10 or your rig (if you have not done so already, you may need to install the device drivers which normally you can get from the radio manufacturers website). In my case I know that COM5 is the port I need.

Confirm your Baudrate for your CAT interface

Read you manual or check google for your default baud rate for your CAT interface. In some cases, this can be set in the radio configuration, so you might get it from there.

In my case, the manual for my rig says 38400

So make sure you document these items

Your table should look similar, possibly with different settings……

Building our command line and testing

Now we have those deatils lets build our command line…..

So with those details above, my command line will be the following

rigctl -m 1042 -r COM5 -s 38400

which if I execute this on the command line, it should come up with the following screen if everything is working correctly

As you can see, that appears to be working, however if you are looking closely, you will see that the model number has been changed.

I have found with the Windows version of rigctl, that there is some sort of communications issue with the FTDX10 settings, that does not exist when using the FTDX101D which is model 1040. So I will for the moment use the FTDX101D settings, until I have enough time to look at this closer and possibly recompile hamlib.

If this works for you, now we can complete our final commandline which is

“C:\Program Files\hamlib-w64-4.5.5\bin\rigctld.exe” -m 1040 -r COM5 -s 38400 -t 4532

Now you will notice a few more changes……

We are now using rigctld which is the daemon.

We now have -t 4532 on the command string which allows us to communicate via TCP to the rigctl server over the network.

Now you can run this command line from CMD.EXE window, leaving that Window open. You should be able to able to use Putty to open a telnet session to that port (4532) and issue commands.

As you can see we are getting responses, so this is working

Now, I will leave you to get this command to run everytime you boot Windows if you want to make a it a permanent application. Each Windows version has its nuances and permissions issues to work through which again is outside the scope of this article.

In a related article, we are going to install hamlib on a Raspberry Pi, which will form part of a CAT Control Server, that will start Rigctl on boot, and as a bonus, we will run hamclock on this Pi as well. https://vkhamradio.com/hamlib-rigctld-and-hamclock-raspberry-pi/

Summary

This was not meant to be all encompassing but more of an introduction (if you had not used it before) to the world of CAT control via TCP, and how the applications use it.