I had CQRlog working with Hamlib rig model 2 (C API backend that talks to rigctld) but then it quit working and all efforts to get it working again have failed. Upgrading to 0.9.2 a few minutes ago did not solve the problem. Direct radio access does work (FT-920, model 114) but then reverting it back to model 2 causes rig control fails.
My settings for model 2 are:
Device: localhost:4532
Model: 2
Poll: 1500
Here is the output from starting CQRlog in the terminal:
$ ./cqrlog
[WARNING] Out of OEM specific VK codes, changing to unassigned
[WARNING] Out of unassigned VK codes, assigning $FF
Starting CQRLOG ...
An error has occured setting the serial speed:4800
An error has occured setting the serial speed:4800
An error has occured setting the serial speed:4800
OnCloseQuery - NewQSO
N0NB_2010-03-06_08-38-55.adi
The third serial speed error line is a result of trying to refresh TRX control.
As rig models 2 and 1901 (rigctld, rpc.rigd) are special backends that map the C API to the respective deamons, trying to set serial speed is not needed as invocation of the daemon has already taken care of that. Perhaps a special setting for these models should exist where the serial mode settings are disabled.
I am seeing the same issue on cqrlog 0.9.2 on x86-64 Fedora 12.
Digging some more, I do not even see a file descriptor for rig mode 2 (device is localhost:4532) in the lsof output for fldigi, nor do I see any open calls being made when stracing fldigi while doing a "TRX control -> Refresh".
$ rpm -q hamlib
hamlib-1.2.10-3.fc12.x86_64
hamlib-1.2.10-3.fc12.i686
Just fixed, I hope.
73 Petr, OK2CQR
--
http://HamQTH.com/ok2cqr
https://ok2cqr.com
I cannot get it to work in 0.9.4...
Checking with lsof, I see cqrlog has no network socket open to rigctld.
My "TRX control" settings are as follows:
Device: localhost:4532
RIG ID model: 2
Poll rate: 500
I have also tried it with just "localhost" as the Device, and it still did not work.
Was the fix for this issue included in 0.9.4? I did not see it in the changelog, either :)
It looks like cqrlog 0.9.5 does not know how to connect (over TCP) to rigctld, either.
Do the hamlib stubs need additional code to do the tcp connection to rigctld?
Or is this something hamlib is supposed to do automatically, when invoked the right way?