Using the following configuration:
CQRLog Version: CQRLog 2.5.2(001) 2021-09-19
Hamlib Version: rigctl Hamlib 4.4~git Thu Nov 11 23:10:57 2021 +0000 SHA=8b5685
Rig: Yaesu FTDX-101D
Using the following command string to start rigctld:
/usr/local/bin/rigctld -m 1040 -r /dev/$ftdx -s 38400 --set-conf=dtr_state=OFF &
Problem:
In "New QSO" window, CQRLog incorrectly populates the "MODE" field with "Main". It cannot be changed manually, either. This results in a saved QSO with "Main" as the mode, as opposed to the mode the rig is set to (CW, SSB, AM, FM, RTTY, ect...), and must be corrected by editing the QSO after saving.
This data appears to be obtained by querying the 'VFO list' as opposed to the 'Mode list' from Hamlib.
How do I fix this?
Hi!
Looks like new rigctld is causing the problem.
After you have started rigctld open a console and telnet to localhost 4532
When connected give
fmv (and enter)
What is the answer?
Cqrlog uses fmv to poll rig and expects following response
:
[saku@hamtpad ~]$ telnet localhost 4532
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
fmv
145000000
FM
15000
VFOA
I guess your rigctd does not give proper answer.
Hamlib has failed to keep backwards compatibly and so responses and queries have changed. Cqrlog has major fix to this in "Commits on Oct 4, 2021", see: https://github.com/ok2cqr/cqrlog/commit/3130939fce17a076734a3338b541577b...
My suggestion is that you compile latest cqrlog from source and then play with rigctld parameter "--vfo" and cqrlog TRXControl's "Use \chkvfo" to find a working combination.
--
Saku
OH1KH
Here's the output from the fmv command:
k4vbb@montech:~$ telnet localhost 4532
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
fmv
7235000
LSB
2400
Main
I'll check out the link and see what I can come up with.
Thank you.
Yep!
That "Main" is too much there and gets mixed to mode with early versions of cqrlog.
As said before Cqrlog has major fix to this in "Commits on Oct 4, 2021".
Now you should get a cqrlog that gives date after Oct 4 2021 at startup instead of your " 2021-09-19"
There are two ways:
To compile from git hub source. Some messages about this subject:
New Ubuntu and latest cqrlog https://www.cqrlog.com/node/2984
Mint 20 Cinnamon and new cqrlog https://www.cqrlog.com/node/2998
Compile process goes same way in all linux brands.
The second one:
Download "newupdate.zip" from my web page, unzip it to get newupdate.sh to start in command console.
It will do the update and backups for you:
https://github.com/OH1KH/cqrlog/tree/loc_testing/compiled
Video of this subject:
https://www.youtube.com/watch?v=H_QLQhQyFVg
Longer one:
https://www.youtube.com/watch?v=Jt_D5sICJVo
--
Saku
OH1KH
How in the world did you get connected with new rigctl???
I can successfully access rig via: /usr/local/bin/rigctl -m 1040 -r /dev/ttyUSB0 -s 9600
This works. But cqrlog will not accept radio 1040. How did you set up cqrlog to accept the new rigctl version? Rigctl seems to be integrated into cqrlog.
Please help this novice..
Blair
kiyy
Blair
Hi Blair!
Rigtcld is not integrated to Cqrlog.
At "preferences/TRXControl/path to rigtcld binary" you should have /usr/local/bin/rigctld
Note the ending character "d" there are two binaries rigctl (runtime version) and rigctld (daemon version. That one Cqrlog uses).
Once you have right path Cqrlog "asks" all rig models from rigctld when preferences opens. You should have 1040 there.
If not, my first guess is:
You have got Hamlib version X when installed Cqrlog from package. Hamlib is one of Cqrlog packag dependencies.
Usually installing to /usr/bin/rigctld
Then you have downloaded later version of Hamlib and compiled that. It usually installs to /usr/local/bin/rigctrld by default.
Ok, now you have two rigctlds that is not a big problem for Cqrlog, but Hamlib installs also library part libhamlib to lib folder.
It is same place for all versions. How ever only other of rigctlds fits to the library part file. That may cause problems with programs that use Hamlib API for communicating to rig (like WSJT-X).
That is why you should get rid of the older Hamlib and keep only the new one. That may be problem if it is a packaged dependency. If you remove the Hamlib package it removes Cqrlog, and perhaps also some other programs.
I do not know Debian based (Ubuntus) linux command to remove just one package and keep the rest.
For fedora it is:
rpm -e --nodeps package_name
"Nodeps" prevent programs that depend on that package to be removed.
But first:
Check the "path to rigctld binary" to point to /usr/local/bin/rigctld And remember it ends to "d" even when you can do manual tests with /usr/local/bin/rigctl (without "d" endng")
Does that help?
If not next job is to check Cqrlog version. Latest version compiled from source is 2.6.0(001)
--
Saku
OH1KH