Hi all, recent user of CQRLOG on mint 19. I have FLDIGI and WSJT-X talking to FLRIG and I can get CQROLG to talk to FLDIGI but I would rather get it to talk to FLRIG. Just wondering if anyone is using this combo and could share their CQRLOG setup for FLRIG.
Thanks
73
Dave, N4XYZ
Mon, 2018-11-26 16:41
#1
FLRIG and CQRLOG
Hi!
At the moment there is no support for flrig. It uses xml-rpc interface to communicate with co-programs. So whole radio interfacing should be rewritten.
The easiest, but not very clever way, would be to write a plugin program that would communicate to flrig with xml-rpc and imitate rigctl to cqrlog with rigcrld commands.
Creating a new "rig" to hamlib would also solve this problem. A rig called flrig. There has been some conversation to get flrig support to wsjtx that is just similar situation.
But I have not followed that conversation and I do not know what is the current situation.
https://sourceforge.net/p/hamlib/mailman/message/35851050/
--
Saku
OH1KH
Saku, many thanks for the reply. WSJTX has FLRIG support with 1.9. As you say the rig you pick is "FLRIG FLRG". You can also see FLRIG FLRIG in the CQRLOG pull down rig menu. Thats why I thought I would ask the question.
73
Dave, N4XYZ
Dave, N4XYZ
Hi Dave !
I made a little study.
In hamlib version 3.3 it has rig called "flrig". Model number is 4. You can see it with command:
rigctld --list
How ever it might be that your linux does not have hamlib 3.3 as package. Do not worry.
If you have installed latest wsjt-x (v2.0rc4 at the moment) it will install also hamlib-wsjtx.
From command line you should be able to type:
[saku@hamtpad ~]$ rigctld-wsjtx --version
rigctl(d), Hamlib 3.3~git
Copyright (C) 2000-2012 Stephane Fillod
Copyright (C) 2000-2003 Frank Singleton
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
The command has extension "-wsjtx" and that must added in cqrlog "preferences/TRXcontol/Path to rigctld binary" string to get v3.3 in use.
Then just select model 4, flrig.
rigctld will talk to flrig via localhost address 127.0.0.1, port 12345, but for cqrlog config defaults 127.0.0.1 (or localhost) and port 4532 should be set for cqrlog to talk to rigctld as before (no change there).
I made a quick setup for ic7300 to flrig (that I do not normally use for anything). Then started rigcltd and cqrlog. It seems to work ok, but only a while then frequency disappears and comes momentary back if TRXContol is reset.
So it works in basic, but needs some setting to fix still.
So answer is YES, but settings needs further investigation. Flrig must be running when cqrlog (and rigctld) are started.
Feel free to test and report how it works !
--
Saku
OH1KH
On Tue 2018-11-27, Saku wrote:
"rigctld will talk to flrig via localhost address 127.0.0.1, port 12345, but for cqrlog config defaults 127.0.0.1 (or localhost) and port 4532 should be set for cqrlog to talk to rigctld as before (no change there)"
I have this connection - FLRig talks to my TS-850. Then, FRLig shares the rig over XML-RPC, port 12345. I test and verify this with rigctl, interactively, from the command-line.
I can then start rigctld with model 4, and it re-serves my rig using hamlib, port 4532. I test and verify this part interactively, from the command-line.
At this point, my rig is accessbile 2x: via XML-RPC on port 12345, and also via hamlib on port 4532. So, I use FLDigi and verify that BOTH methods of rig-access work - they do! FLDigi is happy to use either XML-RPC or hamlib.
Now, to bring in CQRLOG...
I find that CQRLOG cannot talk XML-RPC to FLRig. I wish it did, because I find that FLRig is super-responsive, and supports rig-control ... seemingly faster and more-robustly than hamlib.
So now, I start CQRLOG, and attach it to Model 2 (hamlib NET) on port 4532. CQRLOG receives the Mode and Frequncy properly.
But, as DXCluster spots arrive, I click on one of those, and CQRLOG issues a lot of commands which make my rig beep far too much, and the result includes an undesired change to VFO B!!
The attached screenshot shows:
-I am receiving on VFO A, 14.226MHz, USB
-I click a DX Spot, and CQRLOG sends correct data: 14.019 / CW
-a lot of rig-beeping happens, then the rig has been changed to VFO B!
-subsequent CQRLOG read/updates from rig show VFO B, 14.255MHz, USB
I can now make Mode / Filter / Frequency changes using FLDigi or FLRig, and they are smooth - with only single-beeps from the radio, and no weird VFO changes.
It seems to me that CQRLOG is sending too many commands, and sending incorrect commands. But I don't see this in the debug tracing... :-( Rig control is unhappy.
QUESTION 1: Have I missed a CQRLOG setting, or chosen an inappropriate setting, for this arrangement?
Thank-you!
-Gord VA7GP
File:
Hi Gord!
You do not have to start rigctld -m4 and then cqrlog -m2. Just start cqrlog check "run rigctld when program starts", select rig model 4 and port 12345.
That should work, but you must have always flrig running before cqrlog.
The vfo cahnge and beeps sound like problem with latest wsjt-x, IC7300 and Hamlib4.0. I had same kind of problems when wsjt-x controlled rig.
The solution was to use rigctld-wsjtx that came with latest wsjtx install.
It is newer than package version 4.0 and has latest fixes.
If you have installed wsjtx (the latest) you will have also rigctld-wsjtx in your linux. you can change that to cqrlog (or console tests) just give command:
whereis rigctld-wsjtx
To find full path. I assume you will find it from /usr/local/bin folder.
Rigctld-wsjtx is compiled with static libraries, so it does not use libraries from your computer, but ones that are inside that binary itself (that's why the binary is bigger in size. So libraries are always right version.).
If you can not have latest Hamlib installation package install latest wsjtx https://physics.princeton.edu/pulsar/K1JT/wsjtx.html and that will bring you rigctld-wsjtx to use that is almost the latest. Source from GitHub is little bit ahead as there as been more develop after wsjtx 2.2.2 release.
--
Saku
OH1KH
OK ... Thank you for your helpful suggestions, Saku. I am trying to get this to work..
I obtained the latest SourceForge hamlib-4 source, compiled it and tried your suggestion:
FLRig and FLDigi do generate a single beep / Morse-confirmation for each command, but these are single commands only (such as "change VFO frequency" or "Change Mode" or "Change Filter". When I double-click a a CQRLOG DX Spot, I suppose CQRLOG is issuing many commands quickly, which may produce many radio-beep confirmations quickly too....?
-Gord VA7GP
File:
Sorry Gord !
This is the right way:
Set device as "127.0.0.1:12345" (see picture)
I did test this long time ago and forgot how setup was made. So you do not need rigctld with -m2 in between. Just flrig and -m4 setting in cqrlog.
Drop the poll rate from 500.
1000 or 1500 will do fine.
File:
--
Saku
OH1KH
Hi, Saku!
It works! Using "Device" as you suggest now allows me to skip manual-start of rigctld. See attached image for settings.
Other notes:
Thank-you for your kind attention and help - I really appreciate it!
-Gord VA7GP
File:
Fine !
Neither do cqrlog support ipV6 !
I made also some tests and it seems that -m4 and flrig does not like that cqrlog sends "fmv"+LF
At least with IC7300.
Instead when changed it to send "f"+LF+"m"+LF+"v"+LF combination came more stabile and seems to work fine when controllin from TRXControl, or from Flrig controls.
If this works also without flrig I'm going to include it to fix where I fix the empty value parameters.
--
Saku
OH1KH
Just one thing I forgot to say:
If your rig supports cw keying via cat commands you can not use cqrlog keyer "hamlib" it does not work via rig model 4 "flrig". You have to use real rig model and direct rigcltd connection to rig to get cw keying to work via "hamlib"
--
Saku
OH1KH
Saku thanks for you time and effort. I fldigi to drive a microham (winkey). I will continue to experiment.
Dave, N4XYZ
Dave, N4XYZ