Do we ever want to start rigctl or rigctld on a non-powered rig?
Maybe should do this on all rigs?
TS590S rigctl could not start with power off as firmware version is needed.
And many other things require the rig to be up when rigctl is started.
We won't let set_powerstat fail the startup just in case.
Various SDR consoles are supported by the TS-2000 back end, ensure
that commands unsupported are not sent to them. Added a flag that
shows back end is talking to an emulation like SmartSDR or PowerSDR.
This issue came to light with the HDSDR program which has no ID
command response. For these awkward cases try an FA command to check
if the rig responds then use that same FA command for set command
verification. Otherwise use the ID command as before.
Kenwood, modern Yaesu rigs and many SDRs use an auto information
mechanism that broadcasts unsolicited rig state changes, Hamlib does
not support this and turns off the function. Because several passive
devices rely on this information to detect band changes for example
this change adds code to save the AI state on start up and restores it
on exit. These devices do no need the broadcasts since when an
application using Hamlib is running as necessary state polling by the
application provides continuous rig state updates.
Buffer size is now an input parameter only as the return data length
is implicit since a null terminated C string is returned. Better
precondition checks are impelmented.
There was an inconsistency in whether the CAT terminator character is
included in returned messages. It now follows the comment in
kenwood_transaction() i.e. strips of the terminator and returns a
message length that reflects that.
Allows for a single ';' for verification with the Elecraft XG3 single
character commands.
Allow for rig specific instance data (needed by the Elecraft XG3 that
is a bit different from the rest of the Kenwood/Elecraft group).
Do not send a startup command to turn off AI mode to the Elecraft XG3
as it doesn't have that command or mode.
Restore the positive RTTY mode enabled check to the Elecraft K2 as it
appears that the MD6; and MD9; comamnds are valid even when RTTY mode
is disabled on the rig.
The function kenwood_cmd doesn't add value and it uses a reply buffer
that is not required. Also the use of a reply buffer disables the
verification of commands that have no reply feature. Substituted
kenwood_simple_cmd calls that do the job correctly without a reply
buffer.
Added delay to busy retry loop when sending commands to rig.
Implemented retries on wrong length repies from rig also with a delay.
These rigs can opt to ignore set type commands when they are
busy. This means that sending a set command like FAnnnnnnnnn; to set
the frequency can fail. The rig should send "?;" when busy but since
no reply is normally expected it is not convenient to read for a reply
after a set command since it will block until timeout. This change
sends an "AI;" command after a command that is not expected to reply,
this should guarantee a reply of some sort allowing any busy reply to
be read without blocking and initiate a retry of the original set
command. The "AI;" command is chosen because it is available on all
rigs AFAIK and at least on Elecraft is guaranteed to be processed even
when the rig is busy.
This rig is largely similar to the TS-590S but for some reason Kenwood
have changed most the EX command ids. Even though hamlib makes little
use of the EX command, it probably will need to for future
functionality implemenattion. Hence the new rig id.
Two patches:
The first adds support for the Flex 6K series of SDR radios. These
radios have a CAT application that runs on a windows machine, and
exposes a network socket that can be opened for CAT commands. This back
end connects to that network socket and provides an interface. I've
tested pretty thoroughly using a Flex 6700 but I don't have the other
models available (6500 and 6700R). CAT support on these models is
evolving with frequent updates from Flex, and this back end does not
reflect the latest features to be added. I hope to get to them soon.
The second patch makes the easycomm interface more robust by flushing
the serial port and clearing the buffer.
Steve, AI4QR
Merge branch 'for-upstream' of https://github.com/sconklin/hamlib into sconklin-for-upstream
Defects in the TS590s f/w can be addressed selectively according to
revision.
Enable kenwood_open function for TS590s.
For some reason the TS590s did not use the kenwood_open function, as
fetching the firmware revision may be required for this rig and it is
done in that function; it has been enabled.
The TS50S has the old FN and SP commands rather than the newer FR/FT
commands, added code to support these commands allowing split
operation to be commanded on the TS50S.
The TS480 had no split VFO functions enabled, added normal modern
Kenwood split VFO and mode handing functions.
GCC 4.8.x revealed an error in the way the destination buffer size was
calculated for storing the K3 firmware revision. Now, instead of
declaring the array in the kenwood_priv_data structure, it is declared
as static in elecraft.c and a pointer is now assigned in the
kenwood_priv_data structure. This allows for proper calculation of the
array size for strncpy().
For the K3 RIT/XIT are now explicitly turned On/Off by calling
rig_get/set_func() and passing RIG_FUNC_R/XIT and the status of 1 or 0.
When setting the RIT/XIT offset by calling rig_set_r/xit, an offset of 0
will clear the RIT/XIT offset but will no longer turn the RIT/XIT
function Off. Likewise, an offset can be set but not active until the
RIT/XIT function is explicitly turned On.
The K3 will swap VFOs with the frontend's implementation of
get_split_mode when the backend's definition in rig_caps is NULL. These
functions simply return -RIG_ENAVAIL when called to preserve the K3's
operating state.
git-svn-id: https://hamlib.svn.sourceforge.net/svnroot/hamlib/trunk@3057 7ae35d74-ebe9-4afe-98af-79ac388436b8
Implemented kenwood_cfg_params structure to allow RIT/XIT tokens to be
available to all Kenwood backend rigs (Fine Step and Voice announce are
also defined). K2/K3 rigs can only set/get RIT/XIT.
Updated README.k2/k3 for RIT/XIT functions and prior updates.
git-svn-id: https://hamlib.svn.sourceforge.net/svnroot/hamlib/trunk@3031 7ae35d74-ebe9-4afe-98af-79ac388436b8
K2 backend will now scan for installed RTTY mode and filters per
mode upon rig_open(). Implemented get/set mode in K2. The get_mode()
function checks the filter bandwith and returns that for the width
value and the set_() function will select and set an appropriate
filter based on the width passed in.
git-svn-id: https://hamlib.svn.sourceforge.net/svnroot/hamlib/trunk@3021 7ae35d74-ebe9-4afe-98af-79ac388436b8
and check max length in kenwood_cmd(). This fixes an overrun with
long commands like in th_set_freq().
Patch from Charles, AA1VS, +edit.
git-svn-id: https://hamlib.svn.sourceforge.net/svnroot/hamlib/trunk@2976 7ae35d74-ebe9-4afe-98af-79ac388436b8
Michael Black