FLRIG and CQRLOG

12 posts / 0 new
Last post
N4XYZ
FLRIG and CQRLOG

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

oh1kh
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

N4XYZ
FLRIG CQRLOG

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

oh1kh
FLRIG CQRLOG

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

va7gp
FLRIG CQRLOG

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: 

oh1kh
FLRIG CQRLOG

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

va7gp
FLRIG CQRLOG

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:

  • when I try CQRLOG "run rigctld when program starts", select rig model 4 and port 12345, I see the problem where CQRLOG issues the -r switch, but wrongly populates it with the "Device". Putting the desired poll-rate into the "Device" dialogue allows CQRLOG to start rigctld, but it does not work (that is, it does not communicate with FLRig).

  • repeating my earlier situation: manually start rigctld -m 4 in a console, then "run rigctld when program starts", select rig model 2 and port 4532, this does work! It still makes my TS-850 beep a lot (!!), but at least it doesn't make the VFO switch incorrectly any longer. I can double-click a Bandmap / DXCluster entry, and my radio changes fine. But I still wonder about so many radio-beeps...

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: 

oh1kh
FLRIG CQRLOG

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

va7gp
FLRIG CQRLOG

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:

  • I explored IPv6 for use of ::1 in "Device" and it did not work. Looking further, with netstat, I find that FLRig does not listen on IPv6.

  • The default poll-rate of 500 seems to work very well. When I used hamlib directly to my radio (-m 2009 / previously -m 209 for 1700 to avoid errors. Not only do I find that FLRig is very responsive, it also seems to handle rapid-fire polling without error on either the radio or client side. I am happier with this quick polling-rate. For CQRLOG, the problems (communication errors, timeouts) arise not when polling/receiving updates, but rather when commanding action (DX spot double-click)... For the FLRig-to-radio link, the poll-rate is set at 250ms and seems rock-solid.

Thank-you for your kind attention and help - I really appreciate it!
-Gord VA7GP

File: 

oh1kh
FLRIG CQRLOG

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

oh1kh
FLRIG CQRLOG

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

N4XYZ
FLRIG CQRLOG

Saku thanks for you time and effort. I fldigi to drive a microham (winkey). I will continue to experiment.

Dave, N4XYZ

Dave, N4XYZ