Remote PTT must always be either RIG_PTT_RIG_MICDATA or
RIG_PTT_NONE. Also take care not to override any locally set PTT type
as it is feasible to use a local hardware PTT at the client end with
remote CAT control. Maybe an odd arrangement but Hamlib does not
preclude it. This is all done while preserving the accuracy of the
ptt_type value in dump_state requests.
https://github.com/Hamlib/Hamlib/issues/259
set_vfo_opt can now dynamically change vfo mode on rigctld
So this example now works...does some non-vfo stuff then switches to vfo mode
rigctl -m 2 F 14074000 V VFOB F 14076000 V VFOA f V VFOB f set_vfo_opt 1 f VFOA
rigctl commands v,V and S have been changed to not require VFO arguments
New API function rig_set_vfo_opt -- only implemented for Net rigctl as it doesn't apply to any other rigs
This needs to be validated on the rigs to see the individual behavior
It only gives an error when read_only=0, read_only=1 does not give any error
We want the behavior of actually setting the rig display to be based on this flag
https://github.com/Hamlib/Hamlib/issues/227
Protocol 1 is setting=value. Order does not matter. Can be multiline.
And is forward compatible as new values will just generate warnings on older versions
On Icom rigs, for example you will see "currVFO" if no VFO has been set
Eventually we will start showing MainA/MainB SubA/SubB for rigs that have that capability
Put a looplimit on icom_get_ant_count trying to get autodetect to work
Changes to icom_get_ant_count to try and get this working
Added dummy antenna # args to rigs that don't care i.e. only have 1 antenna
ICOM test via rigctl
Rig command: w \0xfe\0xfe\0x58\0xe0\0x03\0xfd
Reply:\0xFE\0xFE\0x58\0xE0\0x03\0xFD\0xFE\0xFE\0xE0\0x58\0x03\0x00\0x50\0x09\0x14\0x00\0xFD 17
Rig command: W \0xfe\0xfe\0x58\0xe0\0x03\0xfd 17
Reply:\0xFE\0xFE\0x58\0xE0\0x03\0xFD\0xFE\0xFE\0xE0\0x58\0x03\0x00\0x50\0x09\0x14\0x00\0xFD 17
Rig command: w FA;
send_cmd: error = Invalid parameter
Rig command: W FA; 14
send_cmd_rx: error = Invalid parameter
ICOM test via rigctld
Rig command: w \0xfe\0xfe\0x58\0xe0\0x03\0xfd
Reply:\0xFE\0xFE\0x58\0xE0\0x03\0xFD\0xFE\0xFE\0xE0\0x58\0x03\0x00\0x50\0x09\0x14\0x00\0xFD 17
Rig command: W \0xfe\0xfe\0x58\0xe0\0x03\0xfd 17
Reply:\0xFE\0xFE\0x58\0xE0\0x03\0xFD\0xFE\0xFE\0xE0\0x58\0x03\0x00\0x50\0x09\0x14\0x00\0xFD 17
Rig command: w FA;
Reply:RPRT -1
Rig command: W FA; 14
Reply:RPRT -1
Kenwood test via rigctl
Rig command: w FA;
Reply:FA00014074000;
Rig command: W FA; 14
Reply:FA00014074000;
Rig command: w \0x46\0x41\0x3b
Reply:FA00014074000;
Rig command: W \0x46\0x41\0x3b 14
Reply:FA00014074000;
Kenwood test via rigctld
Rig command: w FA;
Reply:FA00014074000;
Rig command: W FA; 14
Reply:FA00014074000;
Rig command: w \0x46\0x41\0x3b
Reply:FA00014074000;
Rig command: W \0x46\0x41\0x3b 14
Reply:FA00014074000;
So we can now do this...write once to see how many bytes you get back
Rig command: w \0xfe\0xfe\0x58\0xe0\0x03\0xfd
Cmd:\0xFE\0xFE\0x58\0xE0\0x03\0xFD\0xFE\0xFE\0xE0\0x58\0x03\0x00\0x00\0x09\0x14\0x00\0xFD 17
Then use 'W' to write the command with the # of bytes to expect -- no timeout this way
Rig command: W \0xfe\0xfe\0x58\0xe0\0x03\0xfd 17
Cmd:\0xFE\0xFE\0x58\0xE0\0x03\0xFD\0xFE\0xFE\0xE0\0x58\0x03\0x00\0x00\0x09\0x14\0x00\0xFD 17
Fix declarations after statements
Remove some !rig checks...we either don't need them or need them everywhere with a new error code
If you pass a NULL rig you get what you deserve :-)
Now responds with hex string just like the input and the # of bytes
Will get hex string response for any binary data from rig from any command
Next step is to implement W command for known # of bytes in response to avoid the timeout
This found tons of errors in rig_debug statements
So this patch cleans up all the files that were producing warnings or errors
This should fix a few segfaults when running with debug turned on