Problems with remote WSJT-X remote mode

5 posts / 0 new
Last post
km4hqe
Problems with remote WSJT-X remote mode

Hi All,

I noticed something that seems to be a resource bug. When I use WSJT-X remote mode, I noticed at the end of transmission on a given interval to the beginning of the next transmission interval; the task bar will freeze like all of the system resources are being consumed by the remote mode. I don't see that if I click on a CQ in WSJT-X. It just seems to happen if I try to open something in the task bar. It seems to take about 5 seconds from the time I click on the item in the task bar before i'm able to open what I clicked on. Anyone else seen this? I did a search and found what looked like a similar bug for fldigi remote mode that was fixed awhile back.

I'm running CQRLOG 2.3.0 on Kubuntu 18.04

73

Stan
KM4HQE

oh1kh
Problems with remote WSJT-X remote mode

HI!

This is a known problem caused by richmemo unit that is used for color printing of CQ-monitor.
If you monitor busy band for longer time you will notice that gap between decode start and final print of CQ-monitor will get longer and longer.
The JT9 process that is doing decode at wsjt-x side is already eating 80%-90% of midpower quadcore laptop and cqrlog/mysql search and print will take the rest.
And it seems that richmemo has some kind of memory leak that is slowly eating more and more of resources.

There are some things that will help, but they do not fix this problem.

1) do not collect history with CQ-monior. Check "nhst" to keep just latest decode's content (you actually do not need older data)

2) in middle of a period, when NewQSO form is focused, press Ctrl-J and again Ctrl-J to close and reopen CQ-monitor. This will remove reserved memory and start a new fresh richmemo for printing.

3) if you want history check "ntxt" from CQ-monitor and "CQ only" from wsjt-x main window. Then wsjt-x is collecting all CQs colored with same colors (selected by your color selection at CQ monitor). CQmonitor does send coloring information to wsjt-x by your log entries. Odd side is that you do not see other traffic than CQs from anywhere.
I have found that this works well for longer times as there is no richmemo printing used then.

Until someone does the fix for richmemo unit of Lazarus (or finds bug from elsewhere) we have to live with this.

You can look at resources used with console command:

top -d 0,2 -p$(pidof cqrlog) -p$(pidof wsjtx) -H

Note how high decoding will set these values when both programs are just started and again when they have been running some hours monitoring busy FT8 band.

--
Saku
OH1KH

km4hqe
Problems with WSJT-X remote mode

Hi Saku!

I do have history turned on.

I'll try what you recommend.

Glad I'm not the only one seeing this.

Thanks!

73

Stan
KM4HQE

oh1kh
Problems with remote WSJT-X remote mode

OK, Stan!

I'm curious to hear your comments. Did any of these 3 suggestions give any help?

--
Saku
OH1KH

km4hqe
Problems with remote WSJT-X remote mode

Hi Saku,

Checking no history may have helped a little. The machine I use is one I built. It has an AMD FX-4100 quad core processor with 16 GB of memory. When the FT8 transmission ends and WSJT-X decodes and starts over, top shows the CPU at 25 percent best I can see, because it changes so fast. At times the process will be in bold white for a very short period of time. WSJT-X will make it bold white and at times and CQRLOG will make it bold white at times. Maybe they will fix the richmemo bug before long.

73

Stan
KM4HQE