DXCluster selection slow to populate log entry

17 posts / 0 new
Last post
n1kx
DXCluster selection slow to populate log entry

I have been using CQRLog for a couple of years now on Ubuntu, and love it.  However, I have an issue which has plagued me most of the time.  When selecting a callsign from the Cluster window, it takes 10 seconds or more to appear in the log and to change the rig frequency. 
I can fix this on startup by opening another log first, then selecting "Open a new log file" to open the actual log I will be using.  If this is done, then no delay - the selection from the Cluster window almost immediately changes the rig and enters the callsign in the log entry form.  However, if I start up and go straight to the log I want to use, I always get a delay.
Anyone else have this behavior?  I assume it has something to do with rigctl.  Since I have a work around, it isn't critical, but I thought I would report it in case somebody knows what causes it and how I can fix it.
Thanks,
Dave, N1KX
 

ok2cqr
ok2cqr's picture
Re: DXCluster selection slow to populate log entry

Hi Dave,
 
this is very interesting. I've never seen it before. Could you run CQRLOG from command line with --debug=1 and and send me the output, please? The output will be long, maybe it would be better to move it to a file.
 
cqrlog --debug=1 >> debug.log
 
Run the CQRLOG, and try to click to any spot and wait till it appears in New QSO window. Then change the log and try it again. Thanks a lot!
 
73 Petr, OK2CQR

n1kx
Re: DXCluster selection slow to populate log entry

OK, I have the debug.log file to send you.  I'll send via email, I suppose.
 
Thanks!
Dave, N1KX

ea4ta
Mine lags the same with a FT

Mine lags the same with a FT-847. But is inmediate with a TS-590.
So rigctl in my opinion. I've improved some with pull time of 2.000 ms. But still lags and gets worse after several hours operating the Yaesu, no matter if I use COM, or USB to COM adapter.
 

n1kx
Re: DXCluster selection slow to populate log entry

I don't have any more trouble after I change logs.  Once I do that, the spots select and populate the log entry  quickly, no matter how long I have had the program running.  I also suspect something with rigctl, but have not found anything specific.

mw0ian
Re: DX cluster slow to populate log entry

Hi Dave, 
Having the same problem here, did you ever find a solution?
73 Ian

n1kx
Re: DX cluster slow to populate log entry

Nope, never did.  I have to open a different log first, then open the log I want to use.  Once I do that, it works.
 
73,
Dave
N1KX

mw0ian
Re: DX cluster slow to populate log entry

Yes its strange, i had Cqrlog on another machine but never had this issue.
Thanks Dave
73 Ian

n1kx
Re: DX cluster slow to populate log entry

Ian, I probably should have mentioned that I also changed system distros from Ubuntu to Fedora 21 and still have the issue.  I expect it is something to do with the specific machine, the USB->COM dongle and rigctl.  I have not figured it out yet, but if I do I will post my ideas here.  Petr assisted a bit when I first discovered it, but he also was not able to find a cause, even after looking at the debug logs.
 
Que sera, sera, I suppose.  I can live with it, considering all the great features the program provides.
 
Cheers es 73,
Dave
N1KX

sq9lbe
sq9lbe's picture
I have this issue with FT-891

I have this issue with FT-891. The call sign is placed in the new qso window immediately, but takes 9-10 seconds for the frequency to update. Well it changes the frequency for a split of a second then goes back to the previous one, and then after 9 seconds it changes back to the right one.
Changing poll does not help, nor changing between different logs.
Few years back I've had FT-857D and did not have this issue.

Thomas SP9TL (ex. SQ9LBE)
https://www.qrz.com/db/SP9TL

oh1kh
I have this issue with FT-891

Hi Tomasz!

What cqrlog and hamlib version are in use?
In command console issue
rigctld --version
and
cqrlog
to get them.

--
Saku
OH1KH

sq9lbe
sq9lbe's picture
Hi, Hamlib 3.3 CQRLog 2.5.2

Hi,

Hamlib 3.3
CQRLog 2.5.2

Thomas SP9TL (ex. SQ9LBE)
https://www.qrz.com/db/SP9TL

oh1kh
I have this issue with FT-891

HI !
Version 3.3 of Hamlib is rather old. Now the current version is 4.4
If your linux distribution does not have fresh package of Hamlib you can download the source from GIthub

git clone https://github.com/Hamlib/Hamlib.git
cd Hamlib
less INSTALL

File INSTALL gives very good instructions how to compile and install

--
Saku
OH1KH

sq9lbe
sq9lbe's picture
thnx. downloaded the Hamlib,

thnx. downloaded the Hamlib, but get error right from the start, and can't find a solution to that.

./configure does not work, "no such file or directory" what??

PS. I'm a total newbie to compiling stuff. I can never get to compile anything! :(

Thomas SP9TL (ex. SQ9LBE)
https://www.qrz.com/db/SP9TL

sq9lbe
sq9lbe's picture
when trying ./bootstrap it

when trying ./bootstrap it does not help either.

~/Hamlib$ ./bootstrap
Running 'autoreconf -i' to process configure.ac
and generate the configure script.
autom4te: cannot create autom4te.cache: No such file or directory
aclocal: error: echo failed with exit status: 1
autoreconf: aclocal failed with exit status: 1

Thomas SP9TL (ex. SQ9LBE)
https://www.qrz.com/db/SP9TL

sq9lbe
sq9lbe's picture
I've had a Linux expert help

I've had a Linux expert help me out, and it happened that the link provided to download the hamlib, downloaded some other or old, or incomplete version of Hamlib, thus ./configure, nor make, just did not work.
So we managed to install the latest Hamlib, but it did not solve the problem. It takes 10 seconds to correct the frequency in cqrlog.

Thomas SP9TL (ex. SQ9LBE)
https://www.qrz.com/db/SP9TL

n1kx
DXCluster selection slow to populate log entry

I was the original poster of this issue several years ago. I no longer have the issue, and I can't remember when it stopped. I am *pretty sure* it stopped when I upgraded hamlib during a system update a few years ago. At any rate, I think Saku is correct - update hamlib!

Hope you get things rolling again. Good luck and good DX!

73,
Dave
N1KX