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:

PREREQUISITES:
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:

CREATE THE FILE:

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:

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.

/usr/bin/rigctl
-- 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.

Example:
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:

#!/bin/bash
/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:

#!/bin/bash
/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:

#!/bin/bash
/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:

127.0.0.1

Another option is to enter 'localhost' in this field, as /etc/hosts will resolve to 127.0.0.1, but to be safe just enter the IP address of 127.0.0.1. 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 --> 127.0.0.1

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.