Hi
I was working with Cqrlog & Jtdx & GridTracker with no issue under Ubuntu 22.04.4 LTS. Being bored of Jtdx and the lack of updates I decided to move to a recent version of wsjtx.
So I installed wstjx and I realised that a new version of hamlib was also installed. The old version of hamlib is not deleted (I do not know how and I found no hint to do so).
After several tries to get it working, my last combination is, in Preferences of Cqglog TRX control window:
Path to rigctld binary field: the newly installed, /usr/bin/rigctl-wsjtx.
'Run rigctld when program starts' and 'compound poll' are ticked both. Rest of boxes unticked.
But radio does not work, fields like mode and frequency does not update on QSO window when I move the dial on the radio. However there is no problem to work with wsjtx from Cqrlog (FIle --> Remote mode wsjtx): data is shown properly and QSOs are stored perfectly will all fields ok.
After running with debug on, I get the following (extracted, please note that ttyICOM is a mapped port that always worked ok):
Settings:
-----------------------------------------------------
RigCtldPath:/usr/bin/rigctl-wsjtx
RigCtldArgs:-m 3073 -r /dev/ttyICOM -t 4532 -s 19200 --set-conf=serial_handshake=None,dtr_state=OFF,rts_state=OFF
RunRigCtld: TRUE
RigDevice: /dev/ttyICOM
RigCtldPort:4532
RigCtldHost:localhost
RigPoll: 500
RigSendCWR: FALSE
RigChkVfo FALSE
RigId: 3073
Starting RigCtld ...
rigProcess.Executable: /usr/bin/rigctl-wsjtx
Parameters:
-m
3073
-r
/dev/ttyICOM
-t
4532
-s
19200
--set-conf=serial_handshake=None,dtr_state=OFF,rts_state=OFF
Rig command: rigctld started!
Waiting for rigctld 1 @ localhost:4532
Error on connect: connection refused
Waiting for rigctld 2 @ localhost:4532
Error on connect: connection refused
Waiting for rigctld 3 @ localhost:4532
Error on connect: connection refused
Waiting for rigctld 4 @ localhost:4532
Error on connect: connection refused
Waiting for rigctld 5 @ localhost:4532
Error on connect: connection refused
Waiting for rigctld 6 @ localhost:4532
Error on connect: connection refused
Waiting for rigctld 7 @ localhost:4532
Error on connect: connection refused
Waiting for rigctld 8 @ localhost:4532
Error on connect: connection refused
Waiting for rigctld 9 @ localhost:4532
Error on connect: connection refused
Waiting for rigctld 10 @ localhost:4532
Error on connect: connection refused
RETRY ERROR: *NOT* connected to rigctld @ localhost:4532
Destroy rigctld
1
1a
2
3
4
5
6
Done!
Inspired by some topics from the forum, I typed from the terminal the following and I got the results whowns below, so rigctld-wsjtx seems to work ok:
/usr/bin/rigctl-wsjtx -m 3073 -r /dev/ttyICOM -t 4532 -s 19200 --set-conf=serial_handshake=None,dtr_state=OFF,rts_state=OFF
Rig command: f
Frequency: 14193000
Rig command: q
What am I doing wrong? Please help.
Best regards
Hi!
Yep, wsjtx does install it's own rigctld-wsjtx and so far it does not mix up things with previously installed rigctld. You can use it, and should, if it is new version.
By your debug it makes me think is it really "/dev/ttyICOM where your serial exist.
But if you can start rigctld manually and it works it must be right.
My suggestion is:
Start the rigctld from script like you do it manually. You can put that on PC startup, or execute manually as first thing before any Ham programs.
Then put rig type "Hamlib net rigctld" that is rig number #2 to all your programs. Uncheck "Run rigctld at program start" (but if I remember right Cqrlog does it if you choose rig type as "Hamlib net rigctld").
That way all programs will call script-started rigctld and it will then call the rig. No collisions.
See: https://github.com/OH1KH/cqrlog/blob/loc_testing/compiled/setting_rigctl...
--
Saku
OH1KH
Saku
Unfortunately it does not work. I start hamlib version 4.4 from the terminal or from startup, the one that worked perfectly a couple of days ago, I configure Cqrlog and Wsjtx to use Hamlib net rigctld, and the results are:
Cqrlog: the sunny side of the story, it works perfectly.
Wsjtx: it does not work in stable conditions. In fact it normally does not work. I reconfigure wsjtx to read directly from the tty port, and same results.
So, I dont want to bother, but ... any help will be greatly appreciatted.
Best regards
Hi!
If Cqrlog works perfectly the reason is inside wsjtx.
What is the version of it? And did you compile it from source or just install from ready compiled package?
What are the rig settings ?
Here are mine:
I use wsjtx-Al-Plus from Uwe, DG2YCB (with some modifications of my own). Both Hamlib and Wsjtx are self compiled, I do not use packet versions.
If you do not have wsjtx from UWE perhaps you could remove the current wsjtx and load AL-Plus from https://sourceforge.net/projects/wsjt-x-improved/files/WSJT-X_v2.7.1/ for testing.
--
Saku
OH1KH
Amazing!
It works nicely with wsjtx-Al-Plus since the very beginning with no additional settings. And 'official versions of wsjtx' did not work, not 2.6.1 neither 2.7.0rc.
Really amazing
Thanks!!!
... and after two days working ok, it does not work now. No setting was changed.
No idea what is happening...
I think I got it so let me share my experiences.
For some reasons, my previously installed version of hamlib (4.4) and the one that new versions of wsjtx installs (4.6) can not work at the same time, and the second one runs as soon as wsjtx starts.
So, before starting Cqrlog, I type in:
rigctld-wsjtx -m 3073 -r /dev/ttyICOM -t 4532 -s 19200 --set-conf=serial_handshake=None,dtr_state=OFF,rts_state=OFF
Rig model in Cqrlog preferences is set to '2 Hamlib NET rigctl', and same in wsjtx. And it seems to work.
Anybody can propose to set in TRX control the path of hamlib to run same command, but in all cases, the checkbox 'runctld when program starts' is disabled, no matter the command 'rigctld-wsjtx...' is run in a terminal window or not. Anyway I am in a better position than before and it seems to work smoothly. Let's pray!!!
Regards
Hi!
You are in right track. I case you have not read this (rather old document):
https://github.com/OH1KH/cqrlog/blob/loc_testing/compiled/setting_rigctl...
Other thing is that if you have two Hamlibs installed you may have two different libhamlib libraries that are part of Hamlib. If those two versions are very different the libraries do not work crossed.
Optimal situation would be to have only one version of Hamlib in PC.
--
Saku
OH1KH