rigctld, TRX Control, WSJTX etc logic makes no sense

2 posts / 0 new
Last post
rigctld, TRX Control, WSJTX etc logic makes no sense

In CQRLog the handling of rigctld is nonsensical at best and problematic in some use cases.

There are two main issues.
1. rigctld is not auto launched when TRX control window is opened. This means that TRX control is non-functional.
2. rigctld is not auto closed when TRX control window is closed.

In the case that "Run rigctld when program starts" is enabled in settings, TRX Control is not closed (along with rigctld) when WSJT-X or FLDigi modes are enabled, causing a conflict between rigctld and WSJT-X or FLDigi.

We need a bit of logic to control this... here's my proposal that will prevent resource conflicts between WSJT-X, FLDigi and CQRLog:

  • In Preferences, replace "Run rigctld when program starts" with "Run rigctld when TRX control is active"
  • Don't launch rigctld until and unless the user opens TRX control.
  • When TRX control is closed, close rigctld unless it was running prior to CQRLog launch.
  • When a user enables either WSJT-X or FLDigi mode under File menu, close TRX Control and therefore close rigctld.
  • If a user goes to open TRX Control when WSJT-X or FLDigi mode is enabled warn them that TRX Control may prevent WSJT-X or FLDigi from working normally, and do they really want to do this?
rigctld, TRX Control, WSJTX etc logic makes no sense


I think you are now on wrong track.

TRXControl window open/close is not related to starting rigctld.
Rigctld is started at the program start (if checked at preferences), or before starting program.
If you start cqrlog from command line with parameter debug=1

[saku@hamtpad ~]$ cqrlog debug=1

Cqrlog Ver:2.4.0 (120) Date:2020-06-03
**** DEBUG LEVEL 1 ****

Linux version 5.6.15-200.fc31.x86_64 (mockbuild@bkernel03.phx2.fedoraproject.org) (gcc version 9.3.1 20200408 (Red Hat 9.3.1-2) (GCC)) #1 SMP Fri May 29 14:59:49 UTC 2020

There you can see that rig is polled all the time, not depending what window is open.

For using one rig and several programs that use rig cat behind same serial port is possible.
Please read this document to get view how it happens and see some example configs for programs: