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.
For Kenwood transceivers the FA/FB/FC command smust be used to get a
VFO frequency, the IF command returns the Tx frequency when
transmitting. The function kenwood_get_freq_if() doesn't adjust for Tx
status or assign the frequency to a specific VFO.
The K2 initialization was checking if RTTY mode was available by
sending an MD6; command and they querying the mode to check if it
worked. The latest kenwood routines now fail if an invalid command is
sent to the K2 initialization need only try the MD6; command to see if
RTTY is available 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.
The K2 RTTY and RTTY-R modes should be modeled as PKTLSB and PKTUSB
respectively since they are AFSK modes.
Also ensured that Kenwood mode sets do not try and set RIG_MODE_NONE
as it makes no sense.
Many APIs emulate direct VFO addressing by using caps->set_vfo() or
caps->vfo_op(..., RIG_OP_TOGGLE) to simulate direct addressing of a
non-current VFO. The mirrored function call to revert back to the
original current VFO was not checking for errors. This is not
unreasonable but it turns out that some rigs can arbitarily fail doing
VFO changes or swaps (e.g. Yaesu FT-450).
I have added checks to these calls but only fail with the error if the
API call being wrapped does not fail itself. This allows the mirroring
VFO operation to be completed, if possible, even if the wrapped
function could not be completed, hence as before, making every effort
not to change the rig state unnecessarily.
The read_string() function was changed to return a -RIG_ETIMEOUT error
when timing out after having read some characters. This caused a back
end to fail because it was using a read_string() with an invalid stop
character and relying on the timed out read_string() to fetch the
data. This patch reverts to the prior behavior of returning a null
terminated buffer and read bytes count if at least one byte has been
read.
Icom users, who use the K9JM CI-V router to protect their PW-1
amplifiers from damage due to Icom's broken CI-V protocol handling,
require a 1s delay after opening the serial port. This is due to the
router using an Arduino & Arduino USB adapter that employs a
bootloader which holds the RS-232 interface for 1s after reset (DTR
releases reset). Hamlib already has a retry and timeout mechanism
which was set to 3 and 200ms respectively for most Icom rigs. This
change increses that timeout to 1s. The increaased timeout will have
little or no impact on clients as it only comes into play if there is
a problem.
After testing on an FT-450D which tends to send busy responses "?;" to
subsequent commands after a band changing command it appears that the
undoumented "?;" rig busy response should be treated as a wait and
subsequent reads may return the expected response i.e. the command is
still in progress and should not be resent.
As this is all based on observations of failure modes rater than any
doumentation from Yaesu, there may be further enhancements necessary.
Fix bytes read count accumulation in Windows serial I/O.
read_string from communications port doesn't handle timeout on
anything but the first character read.
Honour VMIN tty parameter correctly.
When a serial control line (DTR or RTS) is used for PTT control the
rig_open() function clears the PTT control line after opening the
port. This is necessary on Linux because opening the port sets them
both as part of the normal RS-232 protocol. The lines were not being
cleared when the PTT port was the same port as the CAT control port.
While the Winradio G313 backend wasn't being compiled on a non-Linux
POSIX system, the register function in winradio.c was which caused an
error linking rigctl. Also, the host_os test in the configure script
now looks for a string containg "*linux-gnu*" which accepts such systems
as the Raspberry Pi which is defined as "linux-gnueabihf".
Thanks to Lorenzo Simoncello, IW3HER, for reporting this build error on
the Raspberry Pi.
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.
The current version of hamlib cannot cope with unsolicited responses
from rigs therefore AI mode should be turned off on any rigs that
support it in case a previous program left it on.
After some testing with an FT-450 it is apparent that Yaesu use at
least some of the busy/invalid CAT responses that Kenwood document in
their current CAT protocol. The response received from the FT-450 was
a "?;" from occasional "IF;" commands. In the Kenwood World this means
that the command cannot be processed, this could mean it is
unrecognized or it could be a transient condition while the rig
processor is busy. The Kenwood backend has the ability to retry after
this and some other error responses.
Since the Kenwood error response codes are unambigous in the Yaesu
language this change implements a similar protocol for Yaesu "newcat"
backends. Each backend may choose how many reties by defining the
'retry' parameter in the rig capabilities structure.
Also cleaned up a lot of code duplication.
Spencer Berger