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.
Using the priv->info buffer causes security checks on Mac OS X >= 10.9
because the source and destination of an internal strncpy can end up
being the same. It is bad practice anyway as it's undefined behaviour.
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.
Bill Somerville