On my shack-pc (debian bookworm 64bit), I encounter the following problem:
when cqrlog is started, in the new QSO-window there is a default value of 2113.0000 for the frequency, which I cannot change!
cqrlog alpha 134 / 135 gtk2
I use remote database
What could be the cause for that?
Regards,
OE5JWL
Hi!
Have you tried 1). ?
With 2). you can change the dropdown menu values and order.
--
Saku
OH1KH
Yes, I tried this. Does not help.
The value of 2113.0000 is not in the frequency list. It appears in the new qso window, can not be deleted - if I try to erase, it appears again immediately.
cqrlog not useable at all now on this machine ....
Also, I noticed, that when debug is on, cqrlog tries to connect to a rig continuosly - how can this be switched off?
Johann OE5JWL
Ok!
First:
Is there rig or not?
If there is, what are the TRXControl settings? (perhaps attach the cqrlog start debug too)
In case you have rig connected you should check the Hamlib side. There is something wrong.
Check you have just One Hamlib installed.
Did you install some Ham program that installs Hamlib as dependency and then compile Hamlib by yourself from source you may have mixed Hamlib libraries that can cause weird things.
If you do not have rig connected you could try to use rig model #1, Hamlib dummy.
check "Run rigctld at progam start", host localhost, port 4532
When Cqrlog is up and running you should see that dummy defaults to 145Mhz.
If you write kHz to call column and press enter it should move to that frequency which is the easiest way to change frequency.
Then if you have unchecked Mode "Auto" you are able to override Dummy rig's mode.
--
Saku
OH1KH
First, I have no rig online to control.
2nd, the problem is connected to rigctl - if I disable starting rigctld by remove of the checkmark in the settings, the fixed frequency problem disappears - but then I get a popup message on program start to enable debug to see what's wrong.
I have the hamlib dummy selected and there are no other hamlibs installed except the one from the debian repository to my knowledge. When rigctl is enabled, I see 145 MHz in the console - but in the QSO window there is 2113.00000 fix - can not be altered.
When rigctld is disabled, I see the following on the console with debug enabled:
Settings:
-----------------------------------------------------
RigCtldPath:/usr/bin/rigctld
RigCtldArgs:-m 1 -t 5432
RunRigCtld: FALSE
RigDevice:
RigCtldPort:5432
RigCtldHost:localhost
RigPoll: 500
RigSendCWR: FALSE
RigChkVfo FALSE
RigId: 1
Not started rigctld process. (Run is set FALSE)
Waiting for rigctld Poll 1 @ localhost:5432
Error with rigctld: Error on connect: connection refused
Waiting for rigctld Poll 2 @ localhost:5432
......
......
Johann OE5JWL
Ok Johann!
Why there is port 5432 that rigctld is trying to catch?
By default, if you do not give any special port parameters rigtcld will use port 4532 that should be in TRXControl settings.
--
Saku
OH1KH
Let see it again.
It is not wrong to use 5432 port, but you must be sure it is not used by your linux machine for other purpose.
That's why it is more safe to use default port 4532.
If you need more rigs (more rigctlds running) the safest values for port are over 10000. I have three rigs defined here.
IC7300 that uses rigctld running at port 4532
IC706 that uses rigctld runing at port 14532
Dummy that uses rigctld running at 24532
Those are running before cqrlog starts, all the time, that is why port numbers are different.
In "normal" use when Cqrlog starts rigctld you can use same 4532 for all as swithing rig will restart rigctld, the only one that is then running.
OK, you may use 5432 but I wonder why there is text
"RunRigCtld: FALSE" that causes "Not started rigctld process. (Run is set FALSE)" later on.
That means you have not checked "Run rigctld at program start".
Here is my setup for dummy rig. The port can be also 4532 where I use 24532 for reasons explained.
--
Saku
OH1KH
Just to be sure I downloaded newupdate.zip from https://github.com/OH1KH/CqrlogAlpha/tree/main/compiled and started update process for GTK2 version. After it was installed I started it and my dummy rig works ok with the version
So there should not be any error in the Cqrlog binary.
My rigctld is self compiled from https://github.com/Hamlib/Hamlib
Have you tried to create a new log to see if Dummy works there? All settings are log based.
--
Saku
OH1KH
I checked to use ports 4532 or 14532, same result. When rigctld is enabled in the settings, the fixed frequency effect occurs.
the rigctld I have on my system by rigctld --version reported is: rigctl Hamlib 4.5.4 Jan 10 01:31:41Z 2023 SHA=921cc5
(comes from debian bookworm stable)
I have cqrlog on a 2nd debian system running, which shows the same behavior.
Disabling rigctld results in the annoying message at start telling me the missing rigctld.
I use the same version "Ver. Alpha_(135)_Gtk2
I tried to use the qt-version, but this one refuses to start:
cqrlog-qt: symbol lookup error: cqrlog-qt: undefined symbol: QGuiApplication_setFallbackSessionManagementEnabled
Not a very nice situation in the moment ....
OK!
Try this:
preferences/TRXControl:
Put cursor into "Rig model" column.
Press Ctrl+A to get current model selected
Press Del key to clean up the column
Press OK to close preferences
Next time you start Cqrlog it should open without rigctld error.
You can not set frequency by typing kHz to NewQSO/call column, you have to select it from "Freq" selector, or type it (MHz) to "Freq" column without touching the selector part.
TRXControl window will show 0.0000 as frequency and "1 is not set" or "1 None" (after restart of cqrlog) as current rig.
Does this work?
--
Saku
OH1KH
Running QT5 version needs libQT5pas-1 package to be installed first.
Same with QT6 but I think Debian based systems do not have libQT6pas packages yet (?).
Fedora 40 and 41 has them both.
--
Saku
OH1KH
Ok,
Removing the rig model from the settings helps. Good!
Concerning the QT5 version, I have libqt5pas installed. But despite that, the reported message appears and cqrlog refuses to start.
(cqrlog-qt: symbol lookup error: cqrlog-qt: undefined symbol: QGuiApplication_setFallbackSessionManagementEnabled)
Johann OE5JWL
Fine!
Nice to hear your success.
It could be that you should compile QT5 version from source. Perhaps the result would run then.
You just need to install Lazarus and libqt5pas-devel packets and issue
make cqrlog_qt5 && sudo make install
when in source root directory.
With Fedora 40 there was a problem with QT5. Cqrlog compiled ok, as well as it did with GTK2 and QT6, but QT5 version died at start splash.
They fixed something after my error report and after system update compiled QT5 version started to run.
With Fedora 41 I have not seen any similar problems.
--
Saku
OH1KH
Thank you for the quick support!
Johann OE5JWl
HI Johann!
I have fixed CqrlogAlpha 136 (still only devel source phase) so that leaving either Model or Host empty disables tries to catch the rig.
Same works also with rotators (ROTControl).
Leaving Host empty is easier than clean up the model selector column.
Thanks for pointing out the usage without rig!
--
Saku
OH1KH