TRX control not working with Rig model 2 (rigctld)
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.
Digging some more, I do not
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
Re: Digging some more, I do not
Just fixed, I hope.
73 Petr, OK2CQR
I cannot get it to work in
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 :)
I am seeing the same issue on
I am seeing the same issue on cqrlog 0.9.2 on x86-64 Fedora 12.