New beta version of CQRLOG available!

This beta version includes changes from Saku, OH1KH. Hi did really amazing job - simple Contest window, wsjt cq monitor, propagation from DK0WCY etc. You can download the betaversion from


Notes for WSJT-X Remote to another computer

VERY well done, Saku! I have WSJT-X talking from my windows machine to CQRLOG now!

I should note that in the new menu for this feature, there is an input for an IP address. This IP address should NOT be the IP address of the remote computer, but rather the local IP. I was able to make it listen on all interfaces by entering for this - INADDR_ANY, basically. On the WSJT side, the UDP server IP address should be the IP of CQRLOG's computer.

The CQ monitorying windows is also a very nice touch!

Wsjt-x remote and 2nd pc

Your notes are the same that I wrote to README.OH1KH that can be found from root of
Nice to hear that it works with your setup,too!

I'm now working with fldigi remote and have already a unit that can pick callsign from fldigi using xmlrpc. Just have to extend it so that all logging informaton is picked from fldigi.
I did send a pm to your email found from Did you receive it?


CQ monitor...

Really nice and useful feature. Lots of room for future ideas.

The RichMemo control seems to have a slow mem leak. After running for about 48 hours, the text was very slow to update. I'm not very knowledgeable about pascal tracing, but I'll try to run one and report back.

Thanks OMs!

CQ monitor

Have you cleaned wsjt-x with double click to its "erase" button?
When cqrlog asks status from wsjtx it answers with all lines that it has on band monitor and if it has been on for long the list is huge and cqrlog handles only one line per timer round.
Next time you notice slow appearing lines try to clean both wsjtx monitors with double click "erase".

Latest version (033) I have changed timer setting to dynamic. If line is received with 1000 ms poll polling is changed to 50ms and stays there until no more lines are received turning then back to 1000ms.
This should speed up decodings.

Source is at my if you cant wait untill it appears to official beta.


richmemo slowness resovled

HI, I was able to determine the cause of this problem. It comes from two WSJT-X instances sending to the same UDP port that CQRLOG listens to. Might be CQRLOG , it might be my systems' handling of UDP.


Hi Mike!

Sounds interesting, but could you explain a bit more how this can happen?
And how you noticed 2 instances? Tcpdump?
Do you use preferences/wsjtx/address "localhost" or "" or "" or pc's local network card's adress ?
I'm using currently (yep, it is "too wide" but left there after some tests)

Jarmo OH1MRR reported also slowness when running for long time, but after installng official latest version and overlayed it with test binary the slowness was away. He also told that if "no history" was selected there was no slowness, If unselected there was.

I need a glue how this happens as I have never have had any slowness here. (I usually do not leave PC on over night ;)

I have just uploaded 2.10-106 to Git/cqrlog-devel and to test binary website.
Cq monitor:Same color coding for locators as for calls. Some progress with DXChat window.

73 Saku


HI !

Today I noticed some slownes for first time after left PC running for few hours to 20m/FT8:
Closing monitor does not help. Just closing both programs will do.

This is very hard to reproduce. At least taking lot of time. I'll be glad if someone can find a way to fast reproduce.
After that it is easier to hunt the main reason.

Today I did upload all qsos this year again to LoTW as they now have adopted FT8 and using DATA substitute is no longer needed.
It give a warning of dupes and second confirmation "are you really sure". After passing those upload started.
It was not long (30kb) with just few hundred qsos.
How ever during upload there was just new decode of wsjt-x and all text were black on CQ-monitor !
On next decode all colors were normal again.

I do not know is this and slownes related to each other, or is this just something else.

I was using 2.10.-107 (devel) and I have raised UDP polling to 500ms and HiSpeed polling to 10ms from source to see if it has any
effect for slowness.

Fortunately this is not bug that prevents usage.
It is a property, like some M$ products have :)


same symptoms

Hi Saku, your experience is similar to mine.

To answer your earlier question, my two instances send to I have verified with tcpdump that WSJT-X is sending the UDP data immediately. Closing the 2nd instance improves but does not completely solve the problem.

This may be related to CQRLOG's udp message handling, it "feels" like a buffer is becoming excessively large somewhere. I have noticed that after a long running time, CQRLOG will be slow to populate the New QSO window.

I have an eight hour car trip to travel for the eclipse this weekend, so I'll have some time to look further.

thanks again for everything

CQ-monitor slowness


Decoding is now ultra fast with devel -112 (bugfixed 111).

But when left on for 6 hours @20m monitor printing was really slow. Stopping wsjt-remote and restarting does not help.
Same when restarting wsjt-x, no help.

When looked with "top" cqrlog has 3 threads, and at that point when I came back to check the situation, the main(?) thread
had used over 32 minutes cpu time. 2 other threads nearly nothing.

While cq-monitor was printing the main thread took around 70-90% cpu time and 5% of memory. Other times cpu load was low and memory used was around same.

There is something, but it is not memory eating problem. Things just slow (cpu gets loaded) while there is output to Cq-monitor.

Maybe I have to do "fake output " checkbox to pass by actual richmemo output to see if it is that routine, or mysql access.
On the other hand mysqld (MariaDB) (I have 34 threads, but they are not all for cqrlog) takes very little cpu load.
So it seems to be richmemo.

It is just so time taking to test anything as it will get slow so slow :D :D .D

Any ideas are welcome!


mysql performance penaltyX

Hi , I am operating a remote location and I confirm that mysql lookup does contribute to slowness of the WSJT monitor.

When connected over the internet via VPN to my home cqrlog database, the printing in the monitor is extremely slow. Connected to a local database instance the monitor is nice and fast.

There may multiple problems at play.


You have same kind of configuration as I use at boat or summer cottage.
Database is at home server and accessing is done via mobile internet and VPN.

No good for fast qsos like FT8 and contest working. Also if program asks at start about new DXCC and qslmgr loading it is better say NO.
Otherwise you may take another cup of coffee.

For that kind of operations either use local database or manual qso input using DL8BH's cqrweblog installed on home server's website.

But that is outside of normal operation. (Or is it ? :)