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

5 posts / 0 new
Last post
K4VBB
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:

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.

wblairm
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 --> 127.0.0.1

SunSdr does not have the option to run from port 127.0.0.1. 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 :(

oh1kh
CQRLog with SunSDR

Hi!
K4VBB's idea follows the same idea I have documented some years ago: https://github.com/OH1KH/cqrlog/blob/loc_testing/compiled/setting_rigctl...

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.

BUT:
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 &" > ~/startmyrig.sh

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

Now you have script file startmyrig.sh 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.

~/startmyrig.sh

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 "127.0.0.1" 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).

--
Saku
OH1KH

K4VBB
oh1kh

oh1kh

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.

K4VBB
I'm not familiar with SunSDR

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