You probably did not run 'make install' as root.
all you have to do in the directory of the hamlib package is:
./configure
make
make check
sudo make install
this will (should) replace the previous hamlib.
if you wanna know what version default is, just type: rigctl -v
Do this in your home folder, not in the folder you extracted everything to.
If you do a standard ./configure; make; sudo make install, you will get the default installation path, this usually is /usr/local. So you'll still end up with 2 rigctld versions, the original one in /usr/bin, and the new one in /usr/local/bin and you still have to modify the path to rigctld in cqrlog.
I usually avoid installation of "home built" packages in the system file system but directly use the binaries created in the build directory. That does not always work, but in this case it is OK. You only need the rigctld binary for cqrlog.
You know that cqrlog is using the hamlib 3.0.1 if you find the TS590SG in cqrlog's rig list.
On my original machine, I installed a new, larger capicity SSD and installed all the software. A fresh install of Mint 20 and installation of MariaDB, then a clean install of CQRLog 2.4.0 (001), I have the old log database up and running without a problem. But I cannot get CQRLog to see my radio anymore.
I am running the same hardware as before when running Mint 19.2 and everything worked fine then. With Mint 20 installed, I can get FLdigi and WSJT-X to work properly and see and talk to the radio, but not CQRLog. After making the same settings as in Mint 19, CQRLog will poll the radio (I see the CAT light on the radio flash three times), but CQRLog will not display the radio frequency.
When I have CQRLog and WSJT-X running together, CQRLog reads the frequency from WSJT-X and logs it properly.
I am a member of the Dialout group.
All the hardware is the same as Mint 19.2 (except for new SSD).
Radio is Yaseu, FT-1000D (#103)
RigCtld is set the same as before (/dev/ttyS4) - also these are the same settings as FLDigi and WSJT-X.
Any thoughts? I'm at a complete loss to explain this condition.
CW init
Device: /dev/ttyUSB0
Last error nr: 0
Last error desc:OK
After sending null command
After sending echo command: 20
Firmware version: 23
Speed: 0
Speed: 26
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 * from view_cqrlog_main_by_qsodate where qsodate >= '2020-10-14' order by qsodate,time_on
LoadForm: frmNewQSO
Sending: fmv
Sending: fmv
Sending: fmv
Sending: fmv
Sending: fmv
Sending: fmv
Sending: fmv
Sending: fmv
Sending: fmv
Sending: fmv
Sending: fmv
Sending: fmv
Sending: fmv
Sending: fmv
Sending: fmv
Sending: fmv
Sending: fmv
Sending: fmv
Sending: fmv
Sending: fmv
Section:frmTRXControl
Saving window size a position (frmTRXControl) (height|width|top|left):334|317|86|211
Closing rigs...
1
1a
2
3
4
5
6
Section:frmDXCluster
Saving window size a position (frmDXCluster) (height|width|top|left):389|669|608|143
Closing Details window
Section:frmQSODetails
Saving window size a position (frmQSODetails) (height|width|top|left):124|318|451|210
Section:frmBandMap
Saving window size a position (frmBandMap) (height|width|top|left):490|278|87|532
Section:frmPropagation
Saving window size a position (frmPropagation) (height|width|top|left):76|155|119|813
Section:frmNewQSO
Saving window size a position (frmNewQSO) (height|width|top|left):767|1100|230|820
AProcess.Executable: killall Parameters: xplanet
select count(*) from cqrlog001.cqrlog_config
Saving ini file to database
WinKeyer closed
select count(*) from cqrlog001.cqrlog_config
Could it be that upgrading upgraded Hamlib?
In that case rig model numbers are changed. Now your debug shows rig model #103. With latest Hamlib the same rig has model #1003.
You can also add one parameter more to start parameters:
-vvvvv
to start command. Then you see debugging of rigctl and it may give a glue what is wrong.
A reselecting rig at preferences/trxcontrol shoud fix 103 to 1003, but to be sure you need 1003 use the command console first.
rig_init called
lowe: _init called
rig_register called
rig_register: rig_register (1004)
Unknown rig num 1003, or initialization error.
Please check with --list option.
Put 5 "v"s to get maximum debug output. Then we see what it says with old #103 rig model.
Leave parameter -t 4532 away. It works with rigctld but is not the same with rigctl. (I did not notice that at first place)
If rigctl stays running after initialization try to give "f" to get rig frequency.
You can also give "fmv" like cqrlog does. It should show frequency, mode and with some rigs also vfo (A or B).
TEST 1:
Results of the cmd line with 5 "v" option. So it looks like it is working.
TEST 2:
Used the "f" option afterwards, and it correctly displayed my radio vfo-a frequency of, 7.006.48 MHz
See screen shot - attached.
Results of that test shown at the end of this post.
CQRLog still doesn't show the radio frequency on screen.
RCQRLog no freq display 10-26-2020ESULT OF 1ST TEST:
bob@Ham-PC:~$ /usr/bin/rigctl -m 103 -r /dev/ttyS4 -s 4800 -vvvvv
rigctl, Hamlib 3.3
Report bugs to
rig_init called
yaesu: initrigs3_yaesu called
rig_register called
rig_register: rig_register (121)
rig_register called
rig_register: rig_register (127)
rig_register called
rig_register: rig_register (110)
rig_register called
rig_register: rig_register (105)
rig_register called
rig_register: rig_register (106)
rig_register called
rig_register: rig_register (107)
rig_register called
rig_register: rig_register (109)
rig_register called
rig_register: rig_register (120)
rig_register called
rig_register: rig_register (101)
rig_register called
rig_register: rig_register (122)
rig_register called
rig_register: rig_register (123)
rig_register called
rig_register: rig_register (111)
rig_register called
rig_register: rig_register (115)
rig_register called
rig_register: rig_register (113)
rig_register called
rig_register: rig_register (114)
rig_register called
rig_register: rig_register (128)
rig_register called
rig_register: rig_register (131)
rig_register called
rig_register: rig_register (116)
rig_register called
rig_register: rig_register (103)
rig_register called
rig_register: rig_register (124)
rig_register called
rig_register: rig_register (104)
rig_register called
rig_register: rig_register (125)
rig_register called
rig_register: rig_register (129)
rig_register called
rig_register: rig_register (132)
rig_register called
rig_register: rig_register (130)
rig_register called
rig_register: rig_register (117)
rig_register called
rig_register: rig_register (119)
rig_register called
rig_register: rig_register (118)
rig_register called
rig_register: rig_register (126)
rig_register called
rig_register: rig_register (133)
rig_register called
rig_register: rig_register (134)
rig_register called
rig_register: rig_register (135)
rig_register called
rig_register: rig_register (136)
ft1000d_init called
rig_open called
port_open called
serial_open called
serial_setup called
ft1000d_open called
ft1000d_open: write_delay = 175 msec
ft1000d_open: post_write_delay = 5 msec
ft1000d_open: read pacing = 0
ft1000d_send_dynamic_cmd called
ft1000d_send_dynamic_cmd: passed ci = 0x2a
ft1000d_send_dynamic_cmd: passed p1 = 0x00, p2 = 0x00, p3 = 0x00, p4 = 0x00,
write_block called
write_block(): TX 5 bytes
0000 00 00 00 00 0e .....
ft1000d_get_update_data called
ft1000d_get_update_data: passed ci 0x2f
ft1000d_get_update_data: passed ch 0x00
ft1000d_send_static_cmd called
ft1000d_send_static_cmd: ci = 2f00
write_block called
write_block(): TX 5 bytes
0000 00 00 00 02 10 .....
read_block called
read_block(): RX 16 bytes
0000 0c 0a b0 e8 00 00 00 02 02 00 01 02 00 00 00 ff ................
ft1000d_get_update_data: read 16 bytes
rig_get_vfo called
ft1000d_get_vfo called
ft1000d_get_vfo Priv VFO
ft1000d_get_update_data called
ft1000d_get_update_data: passed ci 0x40
ft1000d_get_update_data: passed ch 0x00
ft1000d_send_static_cmd called
ft1000d_send_static_cmd: ci = 4000
write_block called
write_block(): TX 5 bytes
0000 00 00 00 00 fa .....
read_block called
read_block(): RX 5 bytes
0000 08 20 00 10 00 . ...
ft1000d_get_update_data: read 5 bytes
ft1000d_get_vfo: vfo status_1 = 0x08
ft1000d_get_vfo: vfo status_2 = 0x20
ft1000d_get_vfo: stat_vfo = 0x01
Opened rig model 103, 'FT-1000D'
rig_strstatus called
Backend version: 0.1.0, Status: Alpha
RESULTS OF 2ND TEST:
Rig command: f
rigctl_parse: input_line: f
rig_get_freq called
ft1000d_get_freq called
ft1000d_get_freq: passed vfo = 0x20000000
ft1000d_get_freq: priv->current.vfo = 0x01
ft1000d_get_update_data called
ft1000d_get_update_data: passed ci 0x30
ft1000d_get_update_data: passed ch 0x00
ft1000d_send_static_cmd called
ft1000d_send_static_cmd: ci = 3000
write_block called
write_block(): TX 5 bytes
0000 00 00 00 03 10 .....
read_block called
read_block(): RX 32 bytes
0000 0c 0a b0 e8 00 00 00 02 02 00 01 02 00 00 00 ff ................
0010 0c 0a be f4 02 00 00 02 02 00 02 02 00 00 00 ff ................
ft1000d_get_update_data: read 32 bytes
ft1000d_get_freq: p0=0x0a p1=0xb0 p2=0xe8
ft1000d_get_freq: freq = 7006480.000000 Hz for vfo 0x01
Frequency: 7006480
Now we know that rigctld (at least rigctl) can communicate with rig.
Next carefully check that preferences TRXcontrol has right path to rigctrld. Paint and copy the path string from preferences and paste it to command console and press enter to be sure that rigctld exist and starts from that path. If no errors then it started. Give
killall rigctld
few times to be sure it turned off.
Check rig settings once more. No additional spaces etc. in strings. Right port,, device, right speed. Poll rate about 1000 to 2000
Other selectors in "default" positions.
Is "run rigctld at program start" checked?
And you do not run any other program that uses rig and is started before cqrlog? (wsjt-x , jtdx, fldigi, qsstv, etc...)
If all this is ok and no display do as follows:
Preferences/TRXcontrol change rig model to model 2 (Net Hamlib rigctld). Uncheck "run rigctld at program start". Close cqrlog.
Open console and give command:
/usr/bin/rigctld -m 103 -r /dev/ttyS4 -s 4800 -t 4532 -vvvvv
Note that it is now rigctld and that parameter -t 4532 is added.
Leave console open and start cqrlog. You should now see cqrlog polling rigctld in console. Any errors?
If it goes too fast change cqrlog's poll rate to 5000 or 10000 to get time to read console.
YES !
We did get further. Changing RIG model to "2 Hamlib NET rigctl" and unchecking "run rigctld at program start" caused the VFO frequency to be properly displayed in the CQRLog TRX control window, and in the command prompt window, the radio is continuously being polled at the correct rate. See attached screen shot.
OK.
I'm a bit confused ... Good that it works but now we have to clear out why rigctld does not start with cqrlog.
Goto preferences/TRXControl and restore rig settings to model 103 and speed, port, device as they was at start.
Very carefully check the "path to rigctld". For that, open command console and write:
whereis rigctld
You should get something like:
[saku@hamtpad ~]$ whereis rigctld
rigctld: /usr/bin/rigctld /usr/share/man/man1/rigctld.1
The first is the rigctld path , the second is the manual pages path. be sure that you have the first path written to "path to rigctld".
Then check that checkbox "Run rigctld when program starts" is checked.
Close preferences and close cqrlog.
open command console and give:
ps ax | grep rig
You should now get nothing, or perhaps a line with "color". That depends your Linux:
If you see a line with "rigctld" and your rig model "103" then give command:
killall rigctld
So many times that answer is "no processes" or similar.
Then start cqrlog, but keep console still open. When it is running give again:
ps ax | grep rig
Now you should see rigctld line with your rig parameters:
[saku@hamtpad ~]$ ps ax | grep rig
7791 pts/0 S 0:00 /usr/bin/rigctld -m 3073 -r /dev/icom7300 -t 4532 -s 19200 -C auto_power_on=0
7809 pts/0 S+ 0:00 grep --color=auto rig
If you do not see that it means that cqrlog could not run rigctld at program start.
Let's see this first. If it really does not run rigctld at program start we have to think why not.
OK, I tried everything you mentioned in the order you requested and here are it's still not displaying the rig frequency on the TRX control window. The path to rigctld is correct.
When I issued the command, "whereis rigctld" the line returned had a ".gz" at the end. I'm not sure if that makes any difference. When I issued the command, "ps ax | grep rig" the line returned did not show anything with rig or 103. No need to kill process. After starting CQRLog with the console open, I issued the command, "ps ax | grep rig" again and saw that rigctld was running.
gz is ok at the end. The manual pages are compressed, that's why gz. The binary itself seems to be in place.
Now this goes even more weird.
When you start cqlog and it starts rigctld and you see it with ps ax | grep rig command propery, it still does not work.
When you start rigctld manually and change rig model #2 at cqrlog/preferences/trxcontrol it shows frequency.
With current setup #103 model, cqrlog running and ps az| grep rig showing that rigctld is running with proper parameters, open console and give
telnet localhost 4532
or
telnet 127.0.0.1 4532
Use same what you have used in preferences/TRXcontrol next to Rig desc (above Device). There must be either one localhost or 127.0.0.1 (I noticed that column is nameless! It should have IP address of running rigctld)
when telnet starts give
f
and enter , do you see rig frequency?
If seen ok try to switch to "radio2" at TRXcontrol window, then back to "FT-1000D" Do you now see freq at TRXControl? (switching rigs restarts rigctld)
If it does not hep I'm out of ideas.
Starting rigctld from command line or script with proper parameters, but without "-vvvvv" makes is run backgroung and then starting cqrlog
with rig model #2 and unchecked "Rung rigctld at program start" seems to be only solution that works.
It shouldn't be this difficult to get TRX working in CQRLOG. I've tried several different combinations of OS's and versions of Mint and Ubuntu with still no results, that I'm absolutely confused. I'm considering dropping Linux from my shack and moving back to Windoze, although I really DO NOT want to do that. I just can't figure this out and have blown so, so many hours trying that I'm almost ready to give up.
Background refresher:
Old PC that was running Mint 19.1 with CQRLOG 2.4.0 and WSJT-X and FLdigi - machine had a small SSD hard drive, but everything ran perfectly.
System update in November:
Same PC hardware, but installed new 500GB SSD and a fresh install of Mint 20.0 - For the life of me, no matter what I try to do, I still cannot get the TRX window to show the radio frequency (I actually did have it working for a little bit yesterday ONLY, but cannot get it working again).
I did fresh installs of Mint 19.1 and 19.2 and 19.3 and 20.0 and 20.1beta and also Ubuntu 20.04.1 LTS. All had the same problem. Everything works in CQRLOG except for the TRX window frequency. WSJT-X and FLdigi alway worked first thing after a fresh install of either the OS or the application program software.
After each fresh OS install, the first thing I did was follow your instructions to install MariaDB and then CQRLOG - https://www.cqrlog.com/node/2998
sudo apt install mariadb-common mariadb-server mariadb-client
sudo apt install cqrlog
I mentioned earlier that the TRX window "was" working briefly yesterday - for the first time, but cannot figure out why it was working. Today, it is not working once again. I tried to start programs in different order CQRLOG, the WSJT-X and then FLdigi, and played with the start order of each, without any success. I tried starting and stopping the radio communications of each program as well, but no matter what I try, I cannot get it working again. FLdigi and WSJT-X just start working right away no matter what I do. They just work properly. Is there something different about the way CQRLOG handles rig control, and is there anything else you could think of? Would you be willing to use Teamviewer, to take a look at my system, from your house?
Usually problems with cqrlog appear with database connection. I think you have passed them by installing MariaDB and this rig CAT problem has nothing to do with it.
You say fldigi and wsjt-x are working "out of box". How ever with usual setup you an not run cqrlog and those at same time because cqrlog and them both are trying to use rig CAT via same serial port (or USB port).
Fldigi uses (perhaps) its own flrig to communicate with fldigi (or have you set it up to use Hamlib?) so we can not rely on that, but if wsjt-x is working it uses hamlib and proves it should work.
When you have installed wsjt-x it also installs hamlib. perhaps also later version than 3.3.
Try this:
Open console and give command: whereis rigctld-wsjtx
You should see something like:
Do you have there "/usr/local/bin/rigctld-wsjtx" like I do? The path may be different. the second item ending "gz" is the man page and we are not interested of that.
If you found that try command (if you path is same, otherwise fix path of rigctld):
/usr/local/bin/rigctld-wsjtx -l | grep 1000 (parameter is low case L )
You should get long list with end like:
rig_register: rig_register (33001)
1003 Yaesu FT-1000D 20201009.0 Stable RIG_MODEL_FT1000D
1004 Yaesu MARK-V FT-1000MP 20200731.0 Stable RIG_MODEL_FT1000MPMKV
1024 Yaesu FT-1000MP 20200731.0 Stable RIG_MODEL_FT1000MP
1025 Yaesu MARK-V Field FT-1000MP 20200731.0 Stable RIG_MODEL_FT1000MPMKVFLD
4001 Icom IC-PCR1000 20200323.0 Beta RIG_MODEL_PCR1000
10004 Lowe HF-235 20200112.0 Alpha RIG_MODEL_HF235
15001 Winradio WR-1000 20110822.0 Untested RIG_MODEL_WR1000
23001 Flex-radio SDR-1000 20200323.0 Untested RIG_MODEL_SDR1000
So your rig model will be 1003.
Now change this rigctld-wsjtx(+path) to preferences/TRXcontrol/path to rigctld. Check run rigctld at program start.
Find again your rig from selection list. Check that serial port is ok and polling rate around 1500.
Close preferences.
Either switch TRXcontrol to radio1->radio2->radio1 or use NewQSO/FIle/Refresh TRX/ROT control.
Both of them should reload rigctld.
Do you have frequency reading now? If you open console and give:
ps ax | grep rig
You should see "rigctld-wsjtx" running.
NOT like I have here the "original" rigctld running:
saku@hamtpad ~]$ ps ax| grep rig
4691 pts/0 S 0:00 /usr/bin/rigctld -m 3073 -r /dev/icom7300 -t 4532 -s 19200 -C auto_power_on=0
But like this (with your rig parameters):
[saku@hamtpad ~]$ ps ax| grep rig
4772 pts/0 S 0:00 /usr/local/bin/rigctld-wsjtx -m 3073 -r /dev/icom7300 -t 4532 -s 19200 -C auto_power_on=0
Did this give any help?
At the moment I do not have Teamviewer installed. How big time difference do we have? (here UTC+2)
Saku,
Cannot update update hamlib to latest version. I tried to install WSJT-X 2.2.2 because it installs latest version of hamlib, but there is a missing dependency that I cannot figure out how to resolve. Other people are having same issue with WSJT-X 2.2.2 install on Linux.
Please contact me directly to set up an online meeting - I will work around your schedule. WG9LID@comcast.net
Kazumasa,
You probably did not run 'make install' as root.
all you have to do in the directory of the hamlib package is:
./configure
make
make check
sudo make install
this will (should) replace the previous hamlib.
if you wanna know what version default is, just type: rigctl -v
Do this in your home folder, not in the folder you extracted everything to.
73,
Alex
If you do a standard ./configure; make; sudo make install, you will get the default installation path, this usually is /usr/local. So you'll still end up with 2 rigctld versions, the original one in /usr/bin, and the new one in /usr/local/bin and you still have to modify the path to rigctld in cqrlog.
I usually avoid installation of "home built" packages in the system file system but directly use the binaries created in the build directory. That does not always work, but in this case it is OK. You only need the rigctld binary for cqrlog.
You know that cqrlog is using the hamlib 3.0.1 if you find the TS590SG in cqrlog's rig list.
On my original machine, I installed a new, larger capicity SSD and installed all the software. A fresh install of Mint 20 and installation of MariaDB, then a clean install of CQRLog 2.4.0 (001), I have the old log database up and running without a problem. But I cannot get CQRLog to see my radio anymore.
I am running the same hardware as before when running Mint 19.2 and everything worked fine then. With Mint 20 installed, I can get FLdigi and WSJT-X to work properly and see and talk to the radio, but not CQRLog. After making the same settings as in Mint 19, CQRLog will poll the radio (I see the CAT light on the radio flash three times), but CQRLog will not display the radio frequency.
When I have CQRLog and WSJT-X running together, CQRLog reads the frequency from WSJT-X and logs it properly.
I am a member of the Dialout group.
All the hardware is the same as Mint 19.2 (except for new SSD).
Radio is Yaseu, FT-1000D (#103)
RigCtld is set the same as before (/dev/ttyS4) - also these are the same settings as FLDigi and WSJT-X.
Any thoughts? I'm at a complete loss to explain this condition.
Thanks and 73,
Bob, WG9L
Here is a copy of my of my log.txt file:
Cqrlog Ver:2.4.0 (001) Date:2019-10-27
**** DEBUG LEVEL 1 ****
OS:
Linux version 5.4.0-51-generic (buildd@lcy01-amd64-020) (gcc version 9.3.0 (Ubuntu 9.3.0-10ubuntu2)) #56-Ubuntu SMP Mon Oct 5 14:28:49 UTC 2020
SSL libraries:
libssl.so
libcrypto.so
Loaded 149346 LoTW users
Loaded 136581 eQSL users
Loaded 34579 SCP calls
*
User home directory: /home/bob/
Program home directory: /home/bob/.config/cqrlog/
Data directory: /home/bob/.config/cqrlog/database/
Memebers directory: /home/bob/.config/cqrlog/members/
ZIP code directory: /usr/share/cqrlog/zipcodes/
Binary dir: /usr/bin/
Share dir: /usr/share/cqrlog/
*
56 us states loaded
Grid map created
/usr/bin/mysqld
MySQLProcess.Executable: /usr/sbin/mysqld Parameters: --defaults-file=/home/bob/.config/cqrlog/database/mysql.cnf
--datadir=/home/bob/.config/cqrlog/database/
--socket=/home/bob/.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: 16 cDB_MAIN_VER: 16
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 103 -r /dev/ttyS4 -t 4532 -s 4800
RunRigCtld: TRUE
RigDevice: /dev/ttyS4
RigCtldPort:4532
RigCtldHost:localhost
RigPoll: 500
RigSendCWR: FALSE
RigId: 103
Starting RigCtld ...
rigProcess.Executable: /usr/bin/rigctld Parameters: -m
103
-r
/dev/ttyS4
-t
4532
-s
4800
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,info from freqmem order by id
FreqmemNR:0=16
FreqmemNR:1=17
FreqmemNR:2=18
FreqmemNR:3=19
FreqmemNR:4=20
FreqmemNR:5=21
FreqmemNR:6=22
FreqmemNR:7=23
FreqmemNR:8=24
FreqmemNR:9=25
FreqmemNR:10=26
FreqmemNR:11=27
FreqmemFirst:16 FreqmemLast:27
Sending: fmv
CW init
Device: /dev/ttyUSB0
Last error nr: 0
Last error desc:OK
After sending null command
After sending echo command: 20
Firmware version: 23
Speed: 0
Speed: 26
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 * from view_cqrlog_main_by_qsodate where qsodate >= '2020-10-14' order by qsodate,time_on
LoadForm: frmNewQSO
Sending: fmv
Sending: fmv
Sending: fmv
Sending: fmv
Sending: fmv
Sending: fmv
Sending: fmv
Sending: fmv
Sending: fmv
Sending: fmv
Sending: fmv
Sending: fmv
Sending: fmv
Sending: fmv
Sending: fmv
Sending: fmv
Sending: fmv
Sending: fmv
Sending: fmv
Sending: fmv
Section:frmTRXControl
Saving window size a position (frmTRXControl) (height|width|top|left):334|317|86|211
Closing rigs...
1
1a
2
3
4
5
6
Section:frmDXCluster
Saving window size a position (frmDXCluster) (height|width|top|left):389|669|608|143
Closing Details window
Section:frmQSODetails
Saving window size a position (frmQSODetails) (height|width|top|left):124|318|451|210
Section:frmBandMap
Saving window size a position (frmBandMap) (height|width|top|left):490|278|87|532
Section:frmPropagation
Saving window size a position (frmPropagation) (height|width|top|left):76|155|119|813
Section:frmNewQSO
Saving window size a position (frmNewQSO) (height|width|top|left):767|1100|230|820
AProcess.Executable: killall Parameters: xplanet
select count(*) from cqrlog001.cqrlog_config
Saving ini file to database
WinKeyer closed
select count(*) from cqrlog001.cqrlog_config
Saving ini file to database
1
2
3
4
5
6
Closing DXCluster window
Closing TRXControl window
Closing GrayLine window
Closing dDXCC
Deleting config file: 1cqrlog.cfg
Deleting config file: cqrlog.cfg
Closing dData
/home/bob/.config/cqrlog/database/Ham-PC.pid
p.Executable: kill Parameters: 17340
Hi !
Could it be that upgrading upgraded Hamlib?
In that case rig model numbers are changed. Now your debug shows rig model #103. With latest Hamlib the same rig has model #1003.
Open console give:
/usr/bin/rigctl -m 1003 -r /dev/ttyS4 -t 4532 -s 4800
Note that you give rigctl ("d" is dropped away)
If you can get frequency by giving
f(enter)
Yo have connection to rig. Q stops rigctl
You can also add one parameter more to start parameters:
-vvvvv
to start command. Then you see debugging of rigctl and it may give a glue what is wrong.
A reselecting rig at preferences/trxcontrol shoud fix 103 to 1003, but to be sure you need 1003 use the command console first.
Read also this message's link https://cqrlog.com/comment/8844#comment-8844
--
Saku
OH1KH
That did not work. Here is a copy of the results.
bob@Ham-PC:~$ /usr/bin/rigctl -m 1003 -r /dev/ttyS4 -t 4532 -s 4800 -vvvv
rigctl, Hamlib 3.3
Report bugs to
rig_init called
lowe: _init called
rig_register called
rig_register: rig_register (1004)
Unknown rig num 1003, or initialization error.
Please check with --list option.
Saku, any other thoughts?
Hi!
Ok, then you have still the old version of Hamlib.
Use same command, but old rig model 103
/usr/bin/rigctl -m 103 -r /dev/ttyS4 -s 4800 -vvvvv
Put 5 "v"s to get maximum debug output. Then we see what it says with old #103 rig model.
Leave parameter -t 4532 away. It works with rigctld but is not the same with rigctl. (I did not notice that at first place)
If rigctl stays running after initialization try to give "f" to get rig frequency.
You can also give "fmv" like cqrlog does. It should show frequency, mode and with some rigs also vfo (A or B).
"Q" exits from rigctl
Please let us know the results of this test.
--
Saku
OH1KH
Saku,
TEST 1:
Results of the cmd line with 5 "v" option. So it looks like it is working.
TEST 2:
Used the "f" option afterwards, and it correctly displayed my radio vfo-a frequency of, 7.006.48 MHz
See screen shot - attached.
Results of that test shown at the end of this post.
CQRLog still doesn't show the radio frequency on screen.
RCQRLog no freq display 10-26-2020ESULT OF 1ST TEST:
bob@Ham-PC:~$ /usr/bin/rigctl -m 103 -r /dev/ttyS4 -s 4800 -vvvvv
rigctl, Hamlib 3.3
Report bugs to
rig_init called
yaesu: initrigs3_yaesu called
rig_register called
rig_register: rig_register (121)
rig_register called
rig_register: rig_register (127)
rig_register called
rig_register: rig_register (110)
rig_register called
rig_register: rig_register (105)
rig_register called
rig_register: rig_register (106)
rig_register called
rig_register: rig_register (107)
rig_register called
rig_register: rig_register (109)
rig_register called
rig_register: rig_register (120)
rig_register called
rig_register: rig_register (101)
rig_register called
rig_register: rig_register (122)
rig_register called
rig_register: rig_register (123)
rig_register called
rig_register: rig_register (111)
rig_register called
rig_register: rig_register (115)
rig_register called
rig_register: rig_register (113)
rig_register called
rig_register: rig_register (114)
rig_register called
rig_register: rig_register (128)
rig_register called
rig_register: rig_register (131)
rig_register called
rig_register: rig_register (116)
rig_register called
rig_register: rig_register (103)
rig_register called
rig_register: rig_register (124)
rig_register called
rig_register: rig_register (104)
rig_register called
rig_register: rig_register (125)
rig_register called
rig_register: rig_register (129)
rig_register called
rig_register: rig_register (132)
rig_register called
rig_register: rig_register (130)
rig_register called
rig_register: rig_register (117)
rig_register called
rig_register: rig_register (119)
rig_register called
rig_register: rig_register (118)
rig_register called
rig_register: rig_register (126)
rig_register called
rig_register: rig_register (133)
rig_register called
rig_register: rig_register (134)
rig_register called
rig_register: rig_register (135)
rig_register called
rig_register: rig_register (136)
ft1000d_init called
rig_open called
port_open called
serial_open called
serial_setup called
ft1000d_open called
ft1000d_open: write_delay = 175 msec
ft1000d_open: post_write_delay = 5 msec
ft1000d_open: read pacing = 0
ft1000d_send_dynamic_cmd called
ft1000d_send_dynamic_cmd: passed ci = 0x2a
ft1000d_send_dynamic_cmd: passed p1 = 0x00, p2 = 0x00, p3 = 0x00, p4 = 0x00,
write_block called
write_block(): TX 5 bytes
0000 00 00 00 00 0e .....
ft1000d_get_update_data called
ft1000d_get_update_data: passed ci 0x2f
ft1000d_get_update_data: passed ch 0x00
ft1000d_send_static_cmd called
ft1000d_send_static_cmd: ci = 2f00
write_block called
write_block(): TX 5 bytes
0000 00 00 00 02 10 .....
read_block called
read_block(): RX 16 bytes
0000 0c 0a b0 e8 00 00 00 02 02 00 01 02 00 00 00 ff ................
ft1000d_get_update_data: read 16 bytes
rig_get_vfo called
ft1000d_get_vfo called
ft1000d_get_vfo Priv VFO
ft1000d_get_update_data called
ft1000d_get_update_data: passed ci 0x40
ft1000d_get_update_data: passed ch 0x00
ft1000d_send_static_cmd called
ft1000d_send_static_cmd: ci = 4000
write_block called
write_block(): TX 5 bytes
0000 00 00 00 00 fa .....
read_block called
read_block(): RX 5 bytes
0000 08 20 00 10 00 . ...
ft1000d_get_update_data: read 5 bytes
ft1000d_get_vfo: vfo status_1 = 0x08
ft1000d_get_vfo: vfo status_2 = 0x20
ft1000d_get_vfo: stat_vfo = 0x01
Opened rig model 103, 'FT-1000D'
rig_strstatus called
Backend version: 0.1.0, Status: Alpha
RESULTS OF 2ND TEST:
Rig command: f
rigctl_parse: input_line: f
rig_get_freq called
ft1000d_get_freq called
ft1000d_get_freq: passed vfo = 0x20000000
ft1000d_get_freq: priv->current.vfo = 0x01
ft1000d_get_update_data called
ft1000d_get_update_data: passed ci 0x30
ft1000d_get_update_data: passed ch 0x00
ft1000d_send_static_cmd called
ft1000d_send_static_cmd: ci = 3000
write_block called
write_block(): TX 5 bytes
0000 00 00 00 03 10 .....
read_block called
read_block(): RX 32 bytes
0000 0c 0a b0 e8 00 00 00 02 02 00 01 02 00 00 00 ff ................
0010 0c 0a be f4 02 00 00 02 02 00 02 02 00 00 00 ff ................
ft1000d_get_update_data: read 32 bytes
ft1000d_get_freq: p0=0x0a p1=0xb0 p2=0xe8
ft1000d_get_freq: freq = 7006480.000000 Hz for vfo 0x01
Frequency: 7006480
File:
Fine!
Now we know that rigctld (at least rigctl) can communicate with rig.
Next carefully check that preferences TRXcontrol has right path to rigctrld. Paint and copy the path string from preferences and paste it to command console and press enter to be sure that rigctld exist and starts from that path. If no errors then it started. Give
killall rigctld
few times to be sure it turned off.
Check rig settings once more. No additional spaces etc. in strings. Right port,, device, right speed. Poll rate about 1000 to 2000
Other selectors in "default" positions.
Is "run rigctld at program start" checked?
And you do not run any other program that uses rig and is started before cqrlog? (wsjt-x , jtdx, fldigi, qsstv, etc...)
If all this is ok and no display do as follows:
Preferences/TRXcontrol change rig model to model 2 (Net Hamlib rigctld). Uncheck "run rigctld at program start". Close cqrlog.
Open console and give command:
/usr/bin/rigctld -m 103 -r /dev/ttyS4 -s 4800 -t 4532 -vvvvv
Note that it is now rigctld and that parameter -t 4532 is added.
Leave console open and start cqrlog. You should now see cqrlog polling rigctld in console. Any errors?
If it goes too fast change cqrlog's poll rate to 5000 or 10000 to get time to read console.
Did we get any further?
--
Saku
OH1KH
Hi Saku,
YES !
We did get further. Changing RIG model to "2 Hamlib NET rigctl" and unchecking "run rigctld at program start" caused the VFO frequency to be properly displayed in the CQRLog TRX control window, and in the command prompt window, the radio is continuously being polled at the correct rate. See attached screen shot.
What is the next step at this point?
Bob, WG9L
File:
Hi Bob!
OK.
I'm a bit confused ... Good that it works but now we have to clear out why rigctld does not start with cqrlog.
Goto preferences/TRXControl and restore rig settings to model 103 and speed, port, device as they was at start.
Very carefully check the "path to rigctld". For that, open command console and write:
whereis rigctld
You should get something like:
[saku@hamtpad ~]$ whereis rigctld
rigctld: /usr/bin/rigctld /usr/share/man/man1/rigctld.1
The first is the rigctld path , the second is the manual pages path. be sure that you have the first path written to "path to rigctld".
Then check that checkbox "Run rigctld when program starts" is checked.
Close preferences and close cqrlog.
open command console and give:
ps ax | grep rig
You should now get nothing, or perhaps a line with "color". That depends your Linux:
[saku@hamtpad ~]$ ps ax | grep rig
7668 pts/1 S+ 0:00 grep --color=auto rig
If you see a line with "rigctld" and your rig model "103" then give command:
killall rigctld
So many times that answer is "no processes" or similar.
Then start cqrlog, but keep console still open. When it is running give again:
ps ax | grep rig
Now you should see rigctld line with your rig parameters:
[saku@hamtpad ~]$ ps ax | grep rig
7791 pts/0 S 0:00 /usr/bin/rigctld -m 3073 -r /dev/icom7300 -t 4532 -s 19200 -C auto_power_on=0
7809 pts/0 S+ 0:00 grep --color=auto rig
If you do not see that it means that cqrlog could not run rigctld at program start.
Let's see this first. If it really does not run rigctld at program start we have to think why not.
--
Saku
OH1KH
OK, I tried everything you mentioned in the order you requested and here are it's still not displaying the rig frequency on the TRX control window. The path to rigctld is correct.
When I issued the command, "whereis rigctld" the line returned had a ".gz" at the end. I'm not sure if that makes any difference. When I issued the command, "ps ax | grep rig" the line returned did not show anything with rig or 103. No need to kill process. After starting CQRLog with the console open, I issued the command, "ps ax | grep rig" again and saw that rigctld was running.
Here are the results (attached image).
Bob, WG9L
File:
HI Bob!
gz is ok at the end. The manual pages are compressed, that's why gz. The binary itself seems to be in place.
Now this goes even more weird.
When you start cqlog and it starts rigctld and you see it with ps ax | grep rig command propery, it still does not work.
When you start rigctld manually and change rig model #2 at cqrlog/preferences/trxcontrol it shows frequency.
With current setup #103 model, cqrlog running and ps az| grep rig showing that rigctld is running with proper parameters, open console and give
telnet localhost 4532
or
telnet 127.0.0.1 4532
Use same what you have used in preferences/TRXcontrol next to Rig desc (above Device). There must be either one localhost or 127.0.0.1 (I noticed that column is nameless! It should have IP address of running rigctld)
when telnet starts give
f
and enter , do you see rig frequency?
If seen ok try to switch to "radio2" at TRXcontrol window, then back to "FT-1000D" Do you now see freq at TRXControl? (switching rigs restarts rigctld)
If it does not hep I'm out of ideas.
Starting rigctld from command line or script with proper parameters, but without "-vvvvv" makes is run backgroung and then starting cqrlog
with rig model #2 and unchecked "Rung rigctld at program start" seems to be only solution that works.
Did I send this link already https://github.com/OH1KH/cqrlog/blob/loc_testing/compiled/setting_rigctl...
That is the way that then works.
--
Saku
OH1KH
Hi Saku,
Happy New Year...
It shouldn't be this difficult to get TRX working in CQRLOG. I've tried several different combinations of OS's and versions of Mint and Ubuntu with still no results, that I'm absolutely confused. I'm considering dropping Linux from my shack and moving back to Windoze, although I really DO NOT want to do that. I just can't figure this out and have blown so, so many hours trying that I'm almost ready to give up.
Background refresher:
Old PC that was running Mint 19.1 with CQRLOG 2.4.0 and WSJT-X and FLdigi - machine had a small SSD hard drive, but everything ran perfectly.
System update in November:
Same PC hardware, but installed new 500GB SSD and a fresh install of Mint 20.0 - For the life of me, no matter what I try to do, I still cannot get the TRX window to show the radio frequency (I actually did have it working for a little bit yesterday ONLY, but cannot get it working again).
I did fresh installs of Mint 19.1 and 19.2 and 19.3 and 20.0 and 20.1beta and also Ubuntu 20.04.1 LTS. All had the same problem. Everything works in CQRLOG except for the TRX window frequency. WSJT-X and FLdigi alway worked first thing after a fresh install of either the OS or the application program software.
After each fresh OS install, the first thing I did was follow your instructions to install MariaDB and then CQRLOG - https://www.cqrlog.com/node/2998
sudo apt install mariadb-common mariadb-server mariadb-client
sudo apt install cqrlog
I mentioned earlier that the TRX window "was" working briefly yesterday - for the first time, but cannot figure out why it was working. Today, it is not working once again. I tried to start programs in different order CQRLOG, the WSJT-X and then FLdigi, and played with the start order of each, without any success. I tried starting and stopping the radio communications of each program as well, but no matter what I try, I cannot get it working again. FLdigi and WSJT-X just start working right away no matter what I do. They just work properly. Is there something different about the way CQRLOG handles rig control, and is there anything else you could think of? Would you be willing to use Teamviewer, to take a look at my system, from your house?
thanks,
Bob
Hi Bob!
Usually problems with cqrlog appear with database connection. I think you have passed them by installing MariaDB and this rig CAT problem has nothing to do with it.
You say fldigi and wsjt-x are working "out of box". How ever with usual setup you an not run cqrlog and those at same time because cqrlog and them both are trying to use rig CAT via same serial port (or USB port).
Fldigi uses (perhaps) its own flrig to communicate with fldigi (or have you set it up to use Hamlib?) so we can not rely on that, but if wsjt-x is working it uses hamlib and proves it should work.
When you have installed wsjt-x it also installs hamlib. perhaps also later version than 3.3.
Try this:
Open console and give command: whereis rigctld-wsjtx
You should see something like:
[saku@hamtpad ~]$ whereis rigctld-wsjtx
rigctld-wsjtx: /usr/local/bin/rigctld-wsjtx /usr/share/man/man1/rigctld-wsjtx.1.gz
[saku@hamtpad ~]$
Do you have there "/usr/local/bin/rigctld-wsjtx" like I do? The path may be different. the second item ending "gz" is the man page and we are not interested of that.
If you found that try command (if you path is same, otherwise fix path of rigctld):
/usr/local/bin/rigctld-wsjtx -l | grep 1000 (parameter is low case L )
You should get long list with end like:
rig_register: rig_register (33001)
1003 Yaesu FT-1000D 20201009.0 Stable RIG_MODEL_FT1000D
1004 Yaesu MARK-V FT-1000MP 20200731.0 Stable RIG_MODEL_FT1000MPMKV
1024 Yaesu FT-1000MP 20200731.0 Stable RIG_MODEL_FT1000MP
1025 Yaesu MARK-V Field FT-1000MP 20200731.0 Stable RIG_MODEL_FT1000MPMKVFLD
4001 Icom IC-PCR1000 20200323.0 Beta RIG_MODEL_PCR1000
10004 Lowe HF-235 20200112.0 Alpha RIG_MODEL_HF235
15001 Winradio WR-1000 20110822.0 Untested RIG_MODEL_WR1000
23001 Flex-radio SDR-1000 20200323.0 Untested RIG_MODEL_SDR1000
So your rig model will be 1003.
Now change this rigctld-wsjtx(+path) to preferences/TRXcontrol/path to rigctld. Check run rigctld at program start.
Find again your rig from selection list. Check that serial port is ok and polling rate around 1500.
Close preferences.
Either switch TRXcontrol to radio1->radio2->radio1 or use NewQSO/FIle/Refresh TRX/ROT control.
Both of them should reload rigctld.
Do you have frequency reading now? If you open console and give:
ps ax | grep rig
You should see "rigctld-wsjtx" running.
NOT like I have here the "original" rigctld running:
saku@hamtpad ~]$ ps ax| grep rig
4691 pts/0 S 0:00 /usr/bin/rigctld -m 3073 -r /dev/icom7300 -t 4532 -s 19200 -C auto_power_on=0
But like this (with your rig parameters):
[saku@hamtpad ~]$ ps ax| grep rig
4772 pts/0 S 0:00 /usr/local/bin/rigctld-wsjtx -m 3073 -r /dev/icom7300 -t 4532 -s 19200 -C auto_power_on=0
Did this give any help?
At the moment I do not have Teamviewer installed. How big time difference do we have? (here UTC+2)
--
Saku
OH1KH
Saku,
Cannot update update hamlib to latest version. I tried to install WSJT-X 2.2.2 because it installs latest version of hamlib, but there is a missing dependency that I cannot figure out how to resolve. Other people are having same issue with WSJT-X 2.2.2 install on Linux.
Please contact me directly to set up an online meeting - I will work around your schedule.
WG9LID@comcast.net
Thanks,
Bob
Hi,
Please create a new topic please, this one is getting way to cluttered.
As a solution , the 590SG USB speed is standard at 115200, please try that , and make sure you are a member of the dailout group.
Alex
Hi steve,
We seem to have missed each other....
drop me an email if you still want/need my help at pa1sbm add live dot nl
73
Alex
Pages