Hi,
Now that I have CQRlog up and running again, one thing keeps bugging me.
Even though I use the proper settings for my radio, a frequency and/or mode are rarely, if at all, displayed in TRX control.
Nor can I reliably send a bandswitch command from TRX control. I have the pollrate at 10 seconds (10000) milliseconds.
Weird thing is that when rigctld running solely in a terminal it reads everything. I can send commands to the TS-850 and it responds accordingly.
I can use the /usr/bin/rigctld as well as the new hamlib in /usr/local/bin/rigctld.
Both work. Although sluggish when receiving parameters. But no difference between the two.
When started from terminal, I see rigctld started! Also, I hear my radio beep once or twice.
It shows this:
Rigcommand: fmv
sending: fmv
sending: fmv
sending: fmv
and so on but the radio does not seem to send anything back (as it does when rigctld is running standalone in a terminal).
Because receiving parameters from the radio is very sluggish I set the pollrate at aforementioned value.
Another thing I noticed, when sending a command like M in a terminal and giving the frequency, mode and bandwidth, pressing "enter" lets the radio respond immediately.
In a nutshell: in and from CQRlog TRX control nothing works and standalone in a terminal it's fine, though sluggish receiving.
There's another one which puzzels me..... :)
Sidenote: CQRlog would only have to send fm instead of fmv i.m.h.o.
What I tried so far:
All kinds of different settings, default settings, different port, extra commands with manual settings and more.
By the way, it used to run fine before.
HI !
The last sentence "By the way, it used to run fine before."
What have happened between "it worked" - " it does not work any more" ?
Updates to OS? Changes of wiring?... groundings?
10000 is rather long polling gap. It should work with 1000-2500 even if baudrate is 4800 (that can be with some rigs).
Also the parameters 8bits, no parity, 2 stop bits (2 for kenwood).
But if it works from terminal those should be ok.
Have you tested extra parameters :
timeout: "Timeout in ms"
Default: 0, Value: 0
Range: 0.0..10000.0, step 1.0
and
poll_interval: "Polling interval in millisecond for transceive emulation"
Default: 500, Value: 500
Range: 0.0..1000000.0, step 1.0
Both set by line:
-C, --set-conf=parm=val[,parm=val]*
Set config parameter. e.g. --set-conf=stop_bits=2
At least with TS-50 the poll rate extension helps a bit. It is different than cqrlog polling as this parameter affects
how rigctld polls rig via serial line.
And you are right. As Icom user I also like to see only "fm" as icoms cannot answer to "v". And it is not needed in cqrlog.
How ever there are some parts of source code where vfo is handled. But the code is not in use.
Either it is a old feature, or feature that has never ended to production state.
--
Saku
OH1KH
Hi Saku,
I did upgrade my Linux Mint 17.3 to 18.3. And also installed CQRlog 2.3.0 (001).
But since I didn't use CQRlog for a long time (due to inactivity), I am not sure where or when it went wrong.
The hardware has not changed at all. A true serial port and the same interface cable. I even tried another serial pot but that didn't help either.
The long polling gap is because I see the radio responding in anywhere between 1 and 8 seconds. That is when using fmv. f only is almost immediately, fm is some two or three seconds.
I used to set the rig setting to the TS-950SDX (213) which worked better than 209 but that does not work anymore. Rigctrld starts but the radio does not even beep.
As for the extra parameters, I must be making a syntax error. Rigctrld says something like invalid command and does not start.
I'd like to test the timeout parameter but can seem to get the syntax right.
One more curious thing: this week I had it working reasonably fine. Turned out I had two instances of CQRlog running.
I am, unfortunately, unable to reproduce this. At least not working. I even started like three instances.
Also, I fired up W7 in a VM and some program called "commander" works just perfect on the same hardware.
Of course, that would not use hamlib.
I wish I had some programming skills so I could try to change "fmv" to "fm".
Hi,
I should have used a different topictitle, more like "CQRlog no reading in TRX control while rigctld is running and connected to the radio"
I am not sure if this is a clue but I have to use "rigctl" and not "rigctld". Using the latter seems to keep rigctrld from running.
In CQRlog as well as in a terminal.
It doesn't matter if I use the "new" hamlib or the one from 2015. Which seem to be my systems standard hamlib.
I also got the timeout to be accepted by hamlib by putting --set-conf=timeout=xxx. Where xxx is a value.
Tried many values but to no avail.
HI!
> I wish I had some programming skills so I could try to change "fmv" to "fm".
I suspect it does not help. But you can try it. I just did...
1) open command console.
2) write:
hexedit (enter)
if you get error you have to install "Hexedit" . Otherwise you get prompt "File name". Then stop with Ctrl+C and jump to step 4
3) write:
apt-get install hexedit
4) once installed make backup from cqrlog exec. Write:
sudo cp /usr/bin/cqrlog /usr/bin/cqrlog.bak
5) copy cqrlog to /tmp. Write:
cp /usr/bin/cqrlog /tmp
6) Edit binary. Write:
hexedit /tmp/cqrlog
7) binary file opens.
7.1) press "tab" key to get cursor to ascii side
7.2) press Ctrl+S and enter fmv as search string.Press enter.
7.3) you get cursor to"f" to this point:
009421F0 56 46 4F 42 00 00 00 00 00 00 01 00 00 00 00 00 VFOB
00942200 FF FF FF FF FF FF FF FF 09 00 00 00 00 00 00 00 .
00942210 53 65 6E 64 69 6E 67 3A 20 00 00 00 00 00 00 00 Sending:
00942220 00 00 01 00 00 00 00 00 FF FF FF FF FF FF FF FF .
00942230 04 00 00 00 00 00 00 00 66 6D 76 0A 00 00 00 00 .@..... fmv
7.4) press space f m. I.E. replace f with space, m with f and v with m ("fmv" ---> " fm")
7.5) press again Ctrl-S. It asks to save. Answer with y (yes)
7.6) search string appears again. Press enter and you get cursor to f to this point:
00942960 6F 6E 6E 65 63 74 65 64 20 74 6F 20 68 61 6D 6C onnected to haml
00942970 69 62 00 00 00 00 00 00 00 00 01 00 00 00 00 00 ib.ding:
00942980 FF FF FF FF FF FF FF FF 04 00 00 00 00 00 00 00 .
00942990 66 6D 76 0A 00 00 00 00 00 00 01 00 00 00 00 00 fmv.... fm
7.7) repeat steps 7.4) , 7.5) and 7.6) again. At 7.6) it says now "not found".
7.8) Stop by pressing Ctrl+C twice.
7.9) copy modified cqrlog to /usr/bin. Write:
sudo cp /tmp/cqrlog /usr/bin
8) test what happens when you run cqrlog.
9) If you want old file back stop cqrlog and then write:
sudo mv /usr/bin/cqrlog.bak /usr/bin/cqrlog
Maybe doing backup from your logs before trying this is not bad idea!!
--
Saku
OH1KH
HI!
rigctl is a command line version of rigctld that is the daemon that runs on background.
rigctl is good for testing parameters. Just remember to uncheck "Run rigctld at program start" from cqrlog/preferences/trxcontol.
If you have run cqrlog with this setting and stopped it open console and give:
ps ax | grep rig
If this gives line that has rigctld in it the daemon has not yet stopped. Then type
killall rigctld
So many times it says no more process left.
Then, having that "Rung rigctld....." unchecked, first type in console:
rigctl (and all prameters your radio needs) with one extra parameter -vvvvv
You should now have running rigctl at your console. Then start cqrlog and watch command console.
As having -vvvvv you should see lot of debug data at console. If it is too much stop cqrlog then stop rigctl by giving Q(enter) (or Ctrl-c)
and start again with less v. Like -vvvv or -vvv
.
That way you maybe can find out something. And also test parameters like timeout or poll_interval.
--
Saku
OH1KH
Hi Saku,
Thanks for all the useful information. I will dive into a bit of programming when things are working like they should.
So I did all you said in your second post. Turned out I had to reboot in order to get rid of anything mentioning rigctl(d).
It's also important to uncheck "Show communication with TRX in console". If I did not do that, rigctld was still started by CQRlog.
Started rigctl in a terminal with the correct parameters, including -vvvvv for my 850. Radio responds as expected.
Then I started CQRlog but CQRlog does not do anything with rigctrld at all. Seems logical to me since it doesn't call for it.
Of course I used the same path (/usr/bin/rigctl) for both the console (terminal) and set in CQRlog. So there is no confusion.
I then realized that one can start more than one instance of rigctld. So I guess I need a way to tell CQRlog to use the one I had already open in the terminal.
CQRlog will normally start it's own instance.
Hard to get erroneous output ......
Tjalling PA3GOS
>I then realized that one can start more than one instance of rigctld. So I guess I need a way to tell CQRlog to use the one I had already open in the terminal.
You should NOT do that! ONLY one instance of rigctl or rigctld is allowed. Othewise there will be chaos at serial line between your rig and PC.
When you test with rigctl cqrlog should not start rigctld of its own. It does not if you uncheck "Run rigctld at program start". At least it should not.
When you uncheck this change also rig model to "2 Hamlib Net rigctld". Then press OK, and stop cqrlog.
Sorry I forgot to say that you have to change rig model at cqrlog/preferences/trxcontrol.
To be sure that no rigctld is still running give that" "ps ax ...." I mentioned before.
Then start rigctl from command console.
serial port name instead.
Give also IP port as start parameter to be sure it will be 4532. Otherwise cqrlog does not see rigctl.
Here is example with my rig.
I just tested it once again and when cqrlog rig model is "2 Hamlib Net rigctld" and we have "-t 4532" parameter cqrlog will see rigctl
Note that my serial port is named by the rig. Use your own parameters, but take the "-t 4532" with them.
/usr/bin/rigctl -m 373 -r /dev/icom7300 -t 4532 -s 19200 -vvvvv
Then start cqrlog and it should "see" your rigctl ok.
You can then look what cqrlog says for frequency and mode (and what are the possible errors) and you may also check
frequency and mode by giving f and m to "Rig command:" prompt at console screen.
If you have not read this please check it, too. http://www.saunalahti.fi/~sakny/bin/cqrlog2/setting_rigctld_for_all_prog...
--
Saku
OH1KH
Hi again Saku,
Found a way to, at least, see something. I typed " --set-conf=timeout=2000 -vvvvv" in the extra commandline box.
This is what happened:
Starting RigCtld ...
/usr/bin/rigctl -m 209 -r /dev/ttyS5 -t 4532 --set-conf=timeout=2000 -vvvvv --set-conf=stop_bits=2,serial_handshake=None,rts_state=ON
rigctl, Hamlib 3.3
Report bugs to
rig_init called
initrigs3_kenwood called
rig_register called
rig_register: rig_register (213)
rig_register called
rig_register: rig_register (201)
rig_register called
rig_register: rig_register (225)
rig_register called
rig_register: rig_register (203)
rig_register called
rig_register: rig_register (204)
rig_register called
rig_register: rig_register (216)
rig_register called
rig_register: rig_register (224)
rig_register called
rig_register: rig_register (205)
rig_register called
rig_register: rig_register (207)
rig_register called
rig_register: rig_register (209)
rig_register called
rig_register: rig_register (210)
rig_register called
rig_register: rig_register (222)
rig_register called
rig_register: rig_register (214)
rig_register called
rig_register: rig_register (230)
rig_register called
rig_register: rig_register (221)
rig_register called
rig_register: rig_register (229)
rig_register called
rig_register: rig_register (238)
rig_register called
rig_register: rig_register (202)
rig_register called
rig_register: rig_register (211)
rig_register called
rig_register: rig_register (206)
rig_register called
rig_register: rig_register (208)
rig_register called
rig_register: rig_register (215)
rig_register called
rig_register: rig_register (226)
rig_register called
rig_register: rig_register (217)
rig_register called
rig_register: rig_register (233)
rig_register called
rig_register: rig_register (220)
rig_register called
rig_register: rig_register (223)
rig_register called
rig_register: rig_register (227)
rig_register called
rig_register: rig_register (234)
rig_register called
rig_register: rig_register (231)
rig_register called
rig_register: rig_register (239)
rig_register called
rig_register: rig_register (237)
rig_register called
rig_register: rig_register (228)
rig_register called
rig_register: rig_register (219)
rig_register called
rig_register: rig_register (232)
rig_register called
rig_register: rig_register (236)
rig_register called
rig_register: rig_register (240)
kenwood_init called
kenwood_init: if_len = 37
rig_token_lookup called
rig_confparam_lookup called
rig_set_conf called
rig_confparam_lookup called
rig_set_conf: timeout='2000'
rig_token_lookup called
rig_confparam_lookup called
rig_set_conf called
rig_confparam_lookup called
rig_set_conf: stop_bits='2'
rig_token_lookup called
rig_confparam_lookup called
rig_set_conf called
rig_confparam_lookup called
rig_set_conf: serial_handshake='None'
rig_token_lookup called
rig_confparam_lookup called
rig_set_conf called
rig_confparam_lookup called
rig_set_conf: rts_state='ON'
rig_open called
port_open called
serial_open called
serial_setup called
ser_set_rts called
ser_set_rts: RTS=1
kenwood_open called
kenwood_get_id called
kenwood_transaction called
kenwood_transaction: cmdstr = ID
serial_flush called
write_block called
write_block(): TX 3 bytes
0000 49 44 3b ID;
read_string called
rigctld started!
Connected to localhost:4532
read_string(): RX 6 characters
0000 49 44 30 30 39 3b ID009;
kenwood_open: found match 009
kenwood_get_trn called
kenwood_set_trn called
kenwood_transaction called
kenwood_transaction: cmdstr = AI0
serial_flush called
write_block called
write_block(): TX 4 bytes
0000 41 49 30 3b AI0;
write_block called
write_block(): TX 3 bytes
0000 49 44 3b ID;
read_string called
read_string(): RX 6 characters
0000 49 44 30 30 39 3b ID009;
rig_get_vfo called
kenwood_get_vfo_if called
kenwood_get_if called
kenwood_safe_transaction called
kenwood_transaction called
kenwood_transaction: cmdstr = IF
serial_flush called
write_block called
write_block(): TX 3 bytes
0000 49 46 3b IF;
read_string called
read_string(): RX 38 characters
0000 49 46 30 30 30 30 37 31 35 30 30 30 30 20 20 20 IF00007150000
0010 20 20 2b 30 30 36 30 30 30 20 34 37 30 31 30 30 +006000 470100
0020 30 30 30 38 20 3b 0008 ;
Opened rig model 209, 'TS-850'
rig_strstatus called
Backend version: 1.0.1, Status: Beta
Rig command: Sending: fmv
Sending: fmv
Sending: fmv
Sending: fmv
Sending: fmv
Sending: fmv
Sending: fmv
Sending: fmv
I noticed that in between the fmv's there's no output. I still have to read everything myself.
Thanks for being patient with me,
Tjalling PA3GOS
Hi,
How weird that hamlib 3.3 is used according to the above. I defined the path to /usr/bin/rigctl where a version from 2015 is residing.
Just read that the latest stable version shoud be hamlib 3.2.
It's an enigma to me.
3.3 can be found at https://sourceforge.net/projects/hamlib/
Has been some time.
<p>Jarmo</p>
Hi,
I did lots of testing and it is somewhat usable now!
Starting rigctl including -t 4532 in a terminal works of course. But only in that terminal.
CQRlog does not see it because it looks for rigctld.
So starting rigctld with -t 4532 included works. CQRlog finds rigctld and shows frequency, mode and band.
But it takes several seconds to update the above when I tune to some other frequency. Hardly a problem though.
What is a problem is that clicking on a "Band" button is veeeerrrry slow. It usually takes up to several minutes to actually change band.
I did not try it with the cluster or bandmap because, for some reason, I can connect to the telnet clusters just fine but they don't show any DX.
That's a new problem.....
What I did not do is use a name for the serialport. I used /dev/ttyS5 instead. Is that a problem?
So far I did not pay much attention to this because I am not sure how to set a name. Nor am I too sure it will matter anyway.
Oh, don't get me wrong. I did not start more than one rictld. All I meant was that CQRlog would also start one of it's own when enabled.
By the way Saku, a great write-up you got there! Very educational and a good read.
Tjalling PA3GOS
It's still very strange that when CQRlog starts rigctld, it will not work as expected.
While manually doing the same thing works.
Hi Saku,
I went on experimenting. So far so good.
I played with many different "timeout" settings as well as polling rate.
Found an acceptable solution by setting the "timeout" at 500 and polling at 9000.
That way the radio responds to frequency changes within a few seconds.
Frequency readout in CQRlog is slow but fast enough for a QSO.
Also I did reprogram the executable and now it sends fm.
Thank you very much for al the effort you put in teaching me.
It is also quite helpful to not "overwork" rigctrld and/or the radio.
Again, thanks for what you did to help me out.
Now I need to get spots in my DX Cluster window..
If I can't fix it on my own, I will open up a new topic..
73 Tjalling PA3GOS
Hello,
I think I have similar problem with my Elecraft K2
CQRlog, no reading in TRX control, while rigctld is running and connected to the radio.
When I start CQRlog, with the rigctld box checked, rigctld is starting. BUT I have NO FREQUENCY DISPLAY in the qso window.
Below is the line I obtain, when I run ps aux
/usr/bin/rigctld -m 221 -r /dev/ttyUSB0 -t 4532 -s 4800 --set-conf=data_bits=8,stop_bits=2,serial_parity=None,serial_handshake=None
I then unckecked the box Run rigctld when program starts.
I started manually rigctld in a terminal, copying the line obtained with ps aux. Then I started CQRlog.
Now the frequency of my rig is displayed in the QSO window.
Weird....
Any explanations. Any trick to solve this issue ?
Regards, Pierre F5MOG
Hi,
The most easy thing you might give a try is to go to File> Refresh TRX/ROT Control.
So start CQRlog normally and try the above.
If it does not work: what is your output of cqrlog --debug=1 in the terminal?
Might be a timing issue.
73, Tjalling PA3GOS
Hello Tjalling,
Thank you for your reply
I fresh started CQRlog in debug mode, from a terminal.
Below the output of CQRLOG.
In short what I can see
a) rigctld is starting normally (as per debug, and running, as per ps aux)
b) I have a message rigctld started! Connected to localhost:4532
b) I have a message TMySQL57Connection : Server connect failed. ?????
c)I have a message rotctld started! Connected to localhost:4533 ....which seems strange to me, since this rotctld box is un-checked in CQRLOG. However, according ps aux, rotctld does not seem to run .
Not sure I understand what you call timing issue. Is there a parameter linked with time, which needs to be adjusted somewhere in CQRlog ??
Pierre F5MOG
pf@pf-fitlet2:~$ cqrlog --debug=1
Cqrlog Ver:2.3.0 (001) Date:2018-06-17
**** DEBUG LEVEL 1 ****
SSL libraries:
/usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
Loading libmysqlclient: /usr/lib/x86_64-linux-gnu/libmysqlclient.so.20.3.11
**************************
MySQL version: 5.7
**************************
**********************************
MySQL version assigned: 5.7
**********************************
Loaded 125958 LoTW users
Loaded 120289 eQSL users
Loaded 37928 SCP calls
*
User home directory: /home/pf/
Program home directory: /home/pf/.config/cqrlog/
Data directory: /home/pf/.config/cqrlog/database/
Memebers directory: /home/pf/.config/cqrlog/members/
ZIP code directory: /usr/share/cqrlog/zipcodes/
Binary dir: /usr/bin/
Share dir: /usr/share/cqrlog/
TConnection to MySQL: 5.7
*
56 us states loaded
/usr/sbin/mysqld --defaults-file=/home/pf/.config/cqrlog/database/mysql.cnf --datadir=/home/pf/.config/cqrlog/database/ --socket=/home/pf/.config/cqrlog/database/sock --port=64000
Trying to connect to database
TMySQL57Connection : Server connect failed.
Trying:1
select * from tables where table_schema = 'cqrlog_common'
SELECT log_nr,log_name FROM cqrlog_common.log_list order by log_nr
use cqrlog001
use cqrlog001
use cqrlog001
use cqrlog001
use cqrlog001
SELECT * FROM cqrlog_config
select * from db_version
[UpgradeMainDatabase] Old version: 15 cDB_MAIN_VER: 15
select * from cqrlog_common.db_version
SELECT * FROM cqrlog_common.dxcc_ref ORDER BY ADIF
SELECT * FROM cqrlog_common.dxcc_ref ORDER BY ADIF
Settings:
-----------------------------------------------------
RigCtldPath:/usr/bin/rigctld
RigCtldArgs:-m 221 -r /dev/ttyUSB0 -t 4532 -s 4800 --set-conf=data_bits=8,stop_bits=2,serial_parity=None,serial_handshake=None
RunRigCtld: TRUE
RigDevice: /dev/ttyUSB0
RigCtldPort:4532
RigCtldHost:localhost
RigPoll: 1000
RigSendCWR: FALSE
RigId: 221
Starting RigCtld ...
/usr/bin/rigctld -m 221 -r /dev/ttyUSB0 -t 4532 -s 4800 --set-conf=data_bits=8,stop_bits=2,serial_parity=None,serial_handshake=None
rigctld started!
Connected to localhost:4532
Settings:
-----------------------------------------------------
RotCtldPath:/usr/bin/rotctld
RotCtldArgs:
RunRotCtld: FALSE
RotDevice:
RotCtldPort:4533
RotCtldHost:localhost
RotPoll: 500
RotId: 1
rotctld started!
Connected to localhost:4533
FreqmemSql:select id,freq,mode,bandwidth from freqmem order by id
FreqmemFirst:0 FreqmemLast:0
CW init
select * from view_cqrlog_main_by_qsodate LIMIT 500 OFFSET 0
LoadForm: frmMain
SELECT COUNT(*) FROM cqrlog_main
select count(*) from (select distinct adif from cqrlog_main where adif <> 0 and (adif not in (2,8,19,23,25,26,28,30,39,42,44,55,57,58,59,67,68,81,85,93,101,102,113,115,119,127,128,134,139,151,154,155,164,178,183,184,186,193,193,194,196,198,200,208,210,218,220,226,228,229,231,243,244,255,258,261,264,267,268,271,307,488,493))) as foo
select count(*) from (select distinct dxcc_id.dxcc_ref from dxcc_id left join cqrlog_main on dxcc_id.adif = cqrlog_main.adif WHERE cqrlog_main.adif<>0 and (dxcc_ref NOT LIKE '%*') AND (qsl_r = 'Q')) as foo
SELECT * FROM profiles WHERE visible > 0 ORDER BY nr
SELECT * FROM profiles WHERE nr = 1
SELECT * FROM profiles WHERE visible > 0 ORDER BY nr
SELECT * FROM profiles WHERE nr = 1
select locator from profiles where nr = 1
select locator from profiles where nr = 1
1-JN37MP;Elbach;K2-qrp;
select * from view_cqrlog_main_by_qsodate where qsodate >= '2019-01-28' order by qsodate,time_on
LoadForm: frmNewQSO
Sending: fmv
Sending: fmv
Sending: fmv
Hi Pierre,
I compared some lines with my newly installed Mint 19.1. It seems you don't have to worry about the "server connection failed" line.
I have that too. Maybe the MySQL server starts a bit later because it seems not to lead to any problem.
Now, what happens if you start CQRlog normally and refresh TRX/ROT control from file menu?
I ask this because, sometimes, I get no readout either. But after a refresh everything is fine.
Also, I notice you changed the port settings. Although they work with a separately started rigctld, you might try to leave the port settings default.
Just to check if it has any effect.
So, again, try to refresh TRX/ROT from file menu and see if it works.
If not, we'll have to go from there.
73, Tjalling PA3GOS
Hello,
With all the tests and trials I did, I came to the conclusion that rigctld NEEDS to run BEFORE CQRLOG is started.
Therefore I did 2 things
1)make sure rigctld is (almost )continuously running. I used the method recommended by Saku. If rigctld is not running, it will start automatically within one minute.
http://www.saunalahti.fi/~sakny/bin/cqrlog2/setting_rigctld_for_all_prog...
2) automatically start rigctld when I start the computer. I added the ¨rigctld_start.sh¨ described by Saku in the Linux Mint list of programs which are starting automatically.
This method is working.
However, if I refresh the TRX/ROT control from the CQRLOG file menu, I am loosing the freq/mode display, and I have to restart cqrlog, making sure that rigctld is running before. A minor constraint, since the refresh TRX/ROT is not often used, once set with the correct parameters.
I feel connecting my Elecraft K2 Rig was not user friendly in CQRLOG. t It took me some time to set it up, but at least it is giving me the result I wanted.
Thanks to the forum, which was of great help.
Regards, Pierre
Hi Pierre,
Good thing you solved it so it's reliably working. I found the other thread as well where Saku helped you out.
If you read this whole thread, you will see I learned a lot from Saku as well.
In my Mint 18.3 installation I need to have rigctld running as well before starting CQRlog.
But, in my case, I had to use Hamlib radio model 2.
So for many setups things seem different..
Now, with Mint 19.1, I have no issues at all. Except, sometimes I have to refresh TRX/ROT control to get a readout.
But that is hardly worth mentioning. In fact, that indicates I should start rigctrld after CQRlog... How weird can it get...
Nevertheless, I am glad you sorted it all out. And all the hassle was worth it. And we learned a thing or two on the way as well.
73, Tjalling PA3GOS