Flrig Download Linux ##BEST##
Wardex Walker
It is possible to give full gpio access and control privileges by elevating flrig with setuid root. But this is not advisable as flrig is also granted access to both serial and network services. There is a way to provide the access via a second program that does have the elevated privilege
Several debugging tools are available in flrig, including the ability to observe code execution in various parts of the program. The trace tool sends time annotated data to both a viewing dialog and a file named "trace.txt" which is written to the flrig files folder.
flrig will read various transceiver parameters and restore them upon closing. The next image shows the available read/restore parameters for the Icom 7200. If a parameter is not available (or coded) it will be disabled and grayed out. Check each parameter that you want to read and restore. Reading and restoring transceiver parameters takes time, especially on older transceivers with low baud rate serial i/o. Check "Use xcvr data" i\If you want flrig to NOT change the transceiver operating state when it begins execution.
flrig accepts remote control via an XmlRpc socket interface. fldigi uses this access method for reading and writing transceiver parameters via flrig. WSJT-X and several other third party programs also use this method. See flrig XmlRpc Command Structures.
You can have multiple instances of flrig running, each controlling a separate and unique transceiver. Doing this requires a separate configuration folder for each target transceiver. Either start flrig from a command line or copy the desktop launch icon and then modify it's "target" executable. In either case you will be adding a command line parameter
Note the double dash. The will be unique to each supported transceiver, for example: "C:\Users\\flrig.ic7200" on Win-10, "/home//flrig.ic7200" on Linux or OS X. You will have to configure each instance with the correct interface parameters.
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.
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.
"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 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 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"
Fldigi can talk either to rigctld or flrig's XML-RPC, and it does both very well. If this were our destination, either radio-connection (flrig or rigctld) will work. Summary - we can talk to the '850 with either flrig or rigctld. I've had excellent (contest / multi-day) stability with rigctld.
df19127ead