Is it possible to use, now or in the future, flrig to get rig frequency, mode, etc into CQRLog? Since flrig can provide quick menu option changes, it would be nice to use it to also get rig data for CQRLog and at the same time use flrig to make menu changes without quiting rigctld and/or CQRLog.
Any insight or direction would be greatly appreciated. Thank you...
73 - Paul - N9GXA
Hello Paul,
it is on my TODO list. I'm going to rewrite TRX control and use rigctld instead of libhamlib directly. It could solve a lot of problems.
I'm going to release new version 1.3 after fix some bugs. eQSL support is complete, program now gets UTC time directly from the system, I reworked all statistics. Then I want to have something like bug hunt month or something like that. CQRLOG is growing and has many bugs. I suppose after bug month will be version 1.4. So this new trx control should be in 1.5.
73 Petr, OK2CQR
--
http://HamQTH.com/ok2cqr
https://ok2cqr.com
Hello Petr,
Thanks for the reply and information. Always looking forward to the next version. You do fine work.
I am using rigctld now, though. Should this not work? It seems too, but am looking for a way to change menu items via a program while CQRLog is running and it seems to me that libhamlib and rigctld only has access to the main rig information.
Maybe it is not possible to use flrig with fldigi and/or cqrlog at the same time?
Again - Thank you.
73 - Paul - N9GXA
Trying to run Flrig along with a Hamlib app won't work well due to device contention and either program becoming confused from responses to commands it did not issue, etc.
One of the things I would like to do in Hamlib 3.0 is to bring direct command access to the main API. This would allow programs to send and receive raw command strings to a given radio. It would be the app's responsibility to act on the data correctly, of course. This would allow custom macro commands for the K3 and other rigs.
The original goal of Hamlib to provide a virtual rig interface and then map the various rigs to that interface was never fully realized by any backend except perhaps the Dummy rig. The obvious reason is that most everyone authoring code has been satisfied to reach a basic level of operation. Then there are rig command implementations that beg to be left alone!