SDR rig control AND CQRLog at the same time?? Of course --

10 posts / 0 new
Last post
SDR rig control AND CQRLog at the same time?? Of course --

There are a lot of things we like to do at the same time. Walk and chew gum, ignore your girlfriend while watching the game, the college girls that live down the street. And don't forget running CQRLog and your favorite SDR rig-control software at the same time. Some of these are harder to accomplish than others, while what's left remains within the realm of possibility. (If you know of a reliable method for the college girls, please post instructions!)

For now we're going to settle for running CQRLog in tandem with our SDR software that also controls our rig.

Here's how to do it:

Working installation of hamlib
Working installation of CQRLog
Working installation of your SDR software of choice (I use CubicSDR)

First we have to make sure rigctld is running BEFORE cqrlog starts. You can either start it from a terminal, or you can have the system start rigctld upon startup. I chose to start it at boot time. While I'm sure that there are many different ways to do this, here is how I went about it:

In past versions of linux the /etc/rc.local file took care of start up scripts at the tail end of the boot cycle. Later versions of linux no longer use rc.local, but the system is still configured to call upon that file should it exist. I'm running Ubuntu 18.04, so in my case the file does not exist. But that doesn't mean I can't make it exist. Here's is how I created the file and added the requisite contents:


printf '%s\n' '#!/bin/bash' 'exit 0' | sudo tee -a /etc/rc.local

Creating the file all by itself does nothing. We need to add content, and we need to make the file executable:


sudo chmod +x /etc/rc.local

Now we can run the file at startup, but without content it is still useless. Let's add the content, but be aware that the string we'll
need to add will vary depending on what kind of rig you're using. The basic command string format will look something like this:

/usr/bin/rigctl -m [your rigctld rig designation] -r [your serial/USB interface] -s [baud rate of your rig] &

Let's break this down into its constituent parts so that even a novice can understand what's happening.

-- this part just tells the computer to run the command 'rigctl' located in the directory '/usr/bin/'.

-m [your rigctld rig designation]
-- this part tells the computer what kind of rig you have, and therefore what inputs/outputs to expect from the rig. This value will be a number, and the easiest way to find it is to look in CQRlog.

File --> Preferences --> TRX control --> RIG model:

You'll notice that to the left of every model of rig listed in the 'RIG model' box there is a number. This is the number designator for your rig, and this is the number that you'll use in the command string. If you're using an FTDX-5000, the corresponding desginator is 132.
Another way to find it is to run the following command:

rigctl -l

Of course, this will produce a lot of output that you'll have to sort through, so you'll want to pare that down a little bit with 'grep'. In my case, I'm looking for an FTDX-5000, so my command string will look as follows, with the following output:

floridomd@GE72VR-7RF:~$ rigctld -l | grep 5000
(output omitted to save space)
126 Yaesu VR-5000 0.2 Alpha
132 Yaesu FT-DX5000 0.23 Alpha
215 Kenwood R-5000 0.6.1 Alpha
504 AOR AR5000 0.6.1 Beta
514 AOR AR5000A 0.6 Alpha

At the bottom of the output you'll see something like the output above. Since I was looking for the Yaesu FTDX-5000, we can see that my number designator is '132'

-r [your serial/USB port]
-- this will be the port that your rig is connected to on the computer.

If you're using serial port 0, it'll look like this: /dev/ttyS0
If you're using serial port 1, it'll look like this: /dev/ttyS1
If you're using USB port 0, it'll look like this: /dev/ttyUSB0

Get it? If you don't know which serial port your computer is connected to, type the following in a terminal to see what's connected:

dmesg | grep tty

Here's what you might see:

floridomd@GE72VR-7RF:~$ dmesg | grep tty
[ 0.117815] printk: console [tty0] enabled
[ 1.416085] tty ttyS9: hash matches
[ 19.714491] usb 1-3.1: cp210x converter now attached to ttyUSB0
[ 19.716321] usb 1-3.1: cp210x converter now attached to ttyUSB1

If you're still not sure, disconnect the rig and run the command again. Look for what's missing. To confirm, plug it back in, run the command again, and see what came back.

My rig (FTDX-3000) shows two active USB connections, only one of which is primary. Most non-Yaesu rigs will only show one connection. Since I know that my rig uses the cp210x converter, and the primary is connected to ttyUSB0, that's what I'll use in my command string in /etc/rc.local.

-s [baud rate of your rig]
-- this is the baud rate at which your rig is configured to talk to your computer over the serial port. Common baud rates are 4800, 19200, 38400. If your rig is old, it may only support 1200 or 2400. In any case, find out or set your rig's baud rate to something that is compatible with the computer AND your rig.

The last little bit of the string, the &, tells the computer not to bother using on-screen stdout as output. What this will amount to for you is that you won't have a terminal floating around in the background on your desktop waiting for input, or waiting to display output. Furthermore, if you were to close the terminal window, you'd shut down the process. This is not really a necessity, but it does clean things up a bit by allowing the process to run in the background, invisible to you unless you go looking for it.

Let's use my rig. But before we do, understand that rigctld does not have an entry for the FTDX-3000. Since the FTDX-5000 works for the 3000 as well, we'll use it's numerical designation:

Rig: FTDX-5000, numerical designation 132
Connected to USB0
running at 38400 baud

Now let's plug those in and see what the command string looks like:

/usr/bin/rigctld -m 132 -r /dev/ttyUSB0 -s 38400 &

This will be the command string that you'll place in the /etc/rc.local file. The entire file will then look like this:

/usr/bin/rigctld -m 132 -r /dev/ttyUSB0 -s 38400 &
exit 0

If you're using an ICOM IC-7410 on USB port 2 at 4800 baud, here's what your file should look like:

/usr/bin/rigctld -m 367 -r /dev/ttyUSB2 -s 4800 &
exit 0

If you're using a Kenwood TS-450S, connected to serial port 1, using 9600 baud, here's your file:

/usr/bin/rigctld -m 203 -r /dev/ttyS1 -s 9600 &
exit 0

Once properly configured, reboot. Once rebooted, let's see if the process is running with the following command:

floridomd@GE72VR-7RF:~$ ps -ef | grep rigctl
root 1521 1 0 18:45 ? 00:00:19 /usr/bin/rigctld -m 132 -r /dev/ttyUSB0 -s 38400
florido+ 5063 5054 0 22:02 pts/0 00:00:00 grep --color=auto rigctl

Get it? Good. Now let's move on to the CQRLog configuration.

Run CQRLog.
Go here: File --> Preferences --> TRX control --> RIG model:

Ordinarily we'd plug in the values that the serial port is using to communicate with the rig. But we're not going to do that here. Instead, we're going to use the rigctl designation number for Hamlib NET rigctl. That designator is '2'. Don't believe me? Let's check it out:

rigctld -l | grep Hamlib
(output omitted to save space)
1 Hamlib Dummy 0.5 Beta
2 Hamlib NET rigctl 0.3 Beta

We can see that rigctld has a designator for the Hamlib NET rigctl of '2'. So for 'RIG model' we're going to use the following menu choice:

2 Hamlib NET rigctl

Device: Normally we'd select the serial or USB port that the rig is plugged into. However, since rigctld is already communicating with the rig, we dont' want to cause an access violation. Furthermore, rigctld is already porting the input/output to TCP/IP, so designating the serial port here is not necessary. Instead, we'll use one of the IP addresses of the computer.
Here we have some choices, but some are better than others. We 'could' use the IP address assigned to one of the network interfaces. However, since most of us use DHCP for address assignment, this may not be reliable. Never fear, as each network-enabled computer comes configured with a local loopback address that never changes. That address is as follows:

Another option is to enter 'localhost' in this field, as /etc/hosts will resolve to, but to be safe just enter the IP address of That way if you break the /etc/hosts file in some way, it'll still work.

Enter the polling rate of your choice. This is the rate at which CQRLog will poll the rig for information.

I suggest leaving the port number at it's default of 4532. But should you have another process running on that exact same port number, you can change it here. You'll have to change it everywhere else that uses that port number to communicate to CQRLog, as well. Keep that in mind.

Serial Speed: I'm not 100% sure that it's necessary to configure this (I think it may be), but this will be the baud rate that your rig is configured to communicate with the computer. This configuration works for me.

DO NOT ENABLE "Run rigctl when program starts". Again, leave this unchecked. If you leave it checked CQRLog will attempt to run another instance or rigctld when the program starts. Since it's already running, it will not be able to bind to the serial/USB port, and you'll get an access violation. In simple terms, it won't work.

Everything else you can leave to the defaults.

Now it's time to configure the SDR software of your choice. This configuration will be much the same as the CQRLog configuration. For CubicSDR, the configuration should look something like this:

Rig Control --> Model --> Hamlib --> Hamlib NET rigctl
Rig Control --> Serial Rate --> 38400
Rig Control --> Control Port -->

You may need to re-enter the IF frequency of the rig. My FTDX-3000 IF frequency is 9000000. The IC-7410 should be 6445500. This will depend on how you have your IF tapped, and at what frequency it runs, but if you're running an SDR on your rig you should know this anyway.

And that's it. You should now be able to run your SDR software in paralell with your CQRLog. However, before we conclude there are a couple of things to know:

--There might (maybe) be a bit of lag. It takes more time to translate the serial/USB port output to TCP/IP output. You might notice this. You might not. Check and see. If your SDR software becomes too laggy to live with, you'll have to find another way.

--USB port designations don't always stay the same. You might plug in your rig into the same USB port, but instead of it having the normal ttyUSB0 designation, it may show up as ttyUSB1. This is especially true if you have more than one rig plugged into your computer. Upon start up, the one that responds first will get the lower tty designation. For those of us who only run one rig at a time, however, this is not a big issue. If it does happen, you have three choices:

--change the port settings in all your software
--power up your computer, rigs, and other USB devices in the same sequence every time.
--write a UDEV rule to statically designate which port will go with which rig (this is beyond the scope of this instructional, however) Please don't ask me how to do this because I'm not a UDEV expert, and frankly I have not gotten it to work for me.

That's it, and good luck.

CQRLog with SunSDR

Thanks for your very thoughtful response. HERE is the snag. You say:

. For CubicSDR, the configuration should look something like this:

Rig Control --> Model --> Hamlib --> Hamlib NET rigctl
Rig Control --> Serial Rate --> 38400
Rig Control --> Control Port -->

SunSdr does not have the option to run from port It's hardcoded to emulate the Kenwood TS480 and run from a few ports on the drop down; like ttyS0, ttyS4, ttyUSB0

I cannot run the best logbook with best SDR rig under linux - at least for now :(

CQRLog with SunSDR

K4VBB's idea follows the same idea I have documented some years ago:

He must mean that you should first start one rigctld from console command started by cron script or system startup/user login script using:

/usr/bin/rigctld -m 2028 -r /dev/ttyS1 -s 9600 -t 4532 &

Note few things:
- model number here 2028 is now what new rigctld (v4.0) uses with TS_480. With older rigctld the number has only 3 digits.
- last character "&" in line is important. That leaves rigctld running on background.

If you type this command in command console, then close that command console also rigctld is closed.
You must write a script file. Easiest way in command console is:
echo "/usr/bin/rigctld -m 2028 -r /dev/ttyS1 -s 9600 -t 4532 &" > ~/

After that set execute bit of new file:
chmod a+x ~/

Now you have script file in your home directory and running that from command console leaves rigctld running on background (or started from startup/login/cron ) even if you close console after giving that script command.


When you have this rigctld running with model and device settings of your SDR you open cqrlog and set there preferences/TRXControl having radio1 parameters:
radio one desc : "MySDR" "localhost" (or you can use "" instead of "localhost")
rig model: "2 NET rigctld" Device: (leave empty) Poll rate: "1000" Port: "4532"
Extra command line arg: (leave empty) Use CWR: (your choice to check) Run rigctld when cqrlog starts: "unchecked"
Radio one serial parameters: (leave all as "Default")

Now you should get cqrlog connected to background running rigctld started by your script and that rigctld talks to your SDR.
If you want to use any other program (wsjt-x , fldigi, qsstv... etc...) with SDR at same time, or one by one, set all those programs having same kind of rig settings as you did for cqrlog (I.E. those programs connect to your background running rigctld, not directly to your SDR).




I described 'one' strategy to start rigctl. My strategy starts rigctl at system startup from rc.local, leaves the process running in the background, and there is no window displayed. Of course, like you say, it could be run from the terminal as well, but may leave the issue you describe with closing the terminal window.

Your method is a little more flexible in that the shell script can be invoked either manually, or during system startup. This is better for those that want finer control over the process start/stop. I wish I would have seen your write up earlier, as it took me a bit to put all the pieces together.


Now all linux distros are going to use SYSTEMD, instead of old SysV. Old RC.xc are going to be
obsolete. RH based, like Fedora it is in use now.
As "old days" was easy to put starting script into /rc.d/init.d and symlink it start some runlevel
commonly did it at runlevel 3 last, what means @99rigup. Now SYSTEMD starts so called "services"
and belive me, it's hard to get system running at startup. This is Fedora system and not managed yet.
*buntu distros has still possible to do it old rc.x system way, but how long?


I'm not familiar with SunSDR

I'm not familiar with SunSDR's capabilities, but if you can, try using 'localhost' instead of

SDR rig control AND CQRLog at the same time?? Of course --

Not working here.

I entered in terminal:
printf '%s\n' '#!/bin/bash' 'exit 0' | sudo tee -a /etc/rc.local

When I go to the etc folder I do not find rc.local instead I have rc0.d rc1d and on but no local. I am running linux mint 19.3
seems like the issue is not creating the rc.local folder

? thanks 73 Jon


next question

So found how to create the rc.local file online at
now have the file but can not get the command into it. you say:

Now let's plug those in and see what the command string looks like:

/usr/bin/rigctld -m 132 -r /dev/ttyUSB0 -s 38400 &

This will be the command string that you'll place in the /etc/rc.local file. The entire file will then look like this:

/usr/bin/rigctld -m 132 -r /dev/ttyUSB0 -s 38400 &
exit 0

"this is the command string you will place in the rc.local file"
OK and mine is different for Ten Tec Orion so I have my command line changed accordingly however there seems to be nothing here as to how to get the command into the rc.local file. when I open it directly it is read only.... is there a terminal command I am missing or how do I make the rc.file editable? (tried the edit tab on the file, no joy)

I can manually run this in terminal and seems to work but would be nice to not have to do that each operating session.

Thanks for sharing this.



OK Got it and for others that may be Linux Challenged like me here are a few details for the above information that may help:

So first item on creating the rc.local file. I was thinking the above command was not doing that. I was looking in filesystem then the ETC folder and finding many sub folders some rc.1d and so forth. the rc.local is not a folder but maybe a text document? so scroll further down in ETC and it may be there.

I ended up using this as well to try and create it:
Either way once I knew where to look it was there.

I was able to figure out my command line for Ten Tec Orion from the instructions above:
/usr/bin/rigctld -m 1608 -r /dev/ttyS0 -s 57600 &

But the part about adding that to the rc.local file was stumping me. So googled that and found this:
Instructions as to how to edit the rc.local file....
command there that is used is: xed admin:///etc/rc.local

Then I could edit the file so I went to the top which looked like this:

exit 0

then I just moved exit 0 down a line and added the command line so now it looks like this:

/usr/bin/rigctld -m 1608 -r /dev/ttyS0 -s 57600 &
exit 0

click the save icon...

rebooted and ran the above suggestion in terminal
ps -ef | grep rigctl
and now I got it!
jon@jon-Precision-T3600:~$ ps -ef | grep rigctl
root 2022 1 0 16:39 ? 00:00:05 /usr/bin/rigctld -m 1608 -r /dev/ttyS0 -s 57600
jon 6993 6931 0 16:54 pts/0 00:00:00 grep --color=auto rigctl

Now the Orion which is 1608 in Hamlib is there my serial port ttyS0 is there and baud 57600 is there!!!

set up CQRLog for hamlib local host, Cubic SDR for Hamlib and the Port needs to be local host as well which took me a minute to figure out as it is not a choice.

After that they are playing great together.

BIG THANK YOU TO K4VBB For putting this together for us!!!!!!

I was a Ham Radio Deluxe user in Windows but not a huge fan of it. This was a lot of work to get set up but looks like a great replacement.
CQRLog for Logging
CubicSDR for panadapter with my SDRPlay Pro2
Fldigi many modes & interfaced to my WinKeyer USB
WSJTX for FT-8



Change string to this for Omni Vii

I put the Omni Vii on the desk and had NO readout or connection with it.

Tried all the above and no Joy.

Found this on a different thread and reposting it here for us Ten Tec users: Fixed the issues all together and will likely go to this with the Orion as well. Seems more stable...

Hi all,
After a long time of try and errors with my setup to get it stable, I found some hints.
My main problem was the fact that every manipulation at the rig (TenTec Omni VII - later also Orion) caused rigctld to stop working.
here is my command string for rigctld that finally works:
rigctld -m 1611 -r /dev/ttyS0 -t 4532 --set-conf=timeout=10000.0 -s 57600 --set-conf=data_bits=8,stop_bits=1,serial_handshake=None
It helps to add the config of data_bits, stop_bits and handshake - don't know why but it works ...
I think the timeout- parameter (in mS) is self-explaining.
Concerning the serial parameters, the manual of your Yaesu says : “4800,N,8,2” (4800 baud, No Parity, 8 Data Bits, and 2 Stop Bits)
So you should try:
rigctld -m 125 -r /dev/ttyS0 -t 4532 --set-conf=timeout=10000.0 -s 4800 --set-conf=data_bits=8,stop_bits=2 &
Let us know if this helps please.
73 de Peter - ON4EZJ