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.
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.
I have a problem with the CM119A GPIO. The PTT line of the DMK
Engineering URI was not activated by the hamlib when using fldigi or
rigctl.
I fiddled with the source code and managed to edit the code in cm108.c
to get the PTT-line activate on my URI-box.
A successful rigctl command is:
rigctl -p /dev/hidraw0 -C ptt_pathname=/dev/hidraw0,ptt_type=CM108,ptt_bitnum=2
Attached is the modified source code file and a patch in 'git diff'
format.
The version of origin is 1.2.15.3.
73 de Veijo OH3NFC
Signed-off-by: Nate Bargmann <n0nb@n0nb.us>
The Icom IC-7100 back end added this enum instead of using the extant
RIG_PTT_RIG enum. Also the rig_get_ptt() implementation didn't handle
it and errored out.
Note: RIG_PTT_SERIAL_CAT was added in commit
e9ee671149 - N0NB
The RT-21 will accept the command 'AP1XXX.Y<CR>;' which allows settings
to 1/10 of a degree. XXX must be zero padded. '<CR>' causes the RT-21
to rotate to the position immediately with out the need for a following
'AM1;' command.
Tested by Will, WC2L.
The RT-21 returns a variable length string that is terminated by a
semicolon (';') and shorter strings have a leading space character as a
pad. As a result the read_string() function is used to read the string
from the port and strtof() is used to obtain the numeric value returned
by the RT-21. Tested by Will, WC2L.
Even though the Green Heron RT-21 rotor controller is billed as being
RotorEZ compatible, it returns its value as 'XXX;' instead of ';XXX'.
As a new backend model is being written anyway, the backend query's the
controller to return the real value which is 'XXX.Y;'.
I have a small patch to correct the install location of the python
bindings.
Since it's not a pure python extension is belongs in pyexecdir instead
of pythondir, which for multilib systems like Fedora will get installed
into /usr/lib64/python{ver}/site-packages on 64bit systems.
This is consistent with the automake documentation:
http://www.gnu.org/software/automake/manual/html_node/Python.html
(Patch adjusted by n0nb for Hamlib 3.0 bindings/Makefile.am)
Signed-off-by: Nate Bargmann <n0nb@n0nb.us>
I am making a Haskell binding to hamlib and this anonymous struct was
creating some issues for me. I am not a C-coder by day, but I think this
is harmless to add here.
Signed-off-by: Ricky Elrod <ricky@elrod.me>
This allows repeatable regression testing where a command has a finite
"settling" time. This will probably be of most use in the related
rotctl command set.
In order to write regression tests before making disruptive changes to
back ends I have added a new command to the rigctl parser which is '-'
that causes it to read commands from stdin until they are exhausted.
The commands must be white space separated and can include comments
from a '#' character until the end of the current line.
I wrote first support for new version of FUNcube Dongle. Differences
against original FCD are changed USB PID and wider frequency range.
73 Lada, OK1ZIA
Signed-off-by: Nate Bargmann <n0nb@n0nb.us>
Bill Somerville