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 get mode function was not taking account of the extra mode bit in
the IF passband status byte. Also the set mode function was not
supporting the full set of available rig modes.
Added tuning step and bandwidth data for the newly supported modes.
The newcat Yaesu backend was using a toggle command to set the TX VFO
where an explicit set command is avaiable.
This fix corrects the function for the FT-2000(D) and the FT-DX5000.
There is still an issue with the FT-450D which as far as I can see has
no definitive way of setting which VFO will be used for TX.
Signed-off-by: Nate Bargmann <n0nb@n0nb.us>
Hi All,
attached is a patch to correct the Yaesu backend to stop it sending the
SH1; command to teh FT-2000(D) radios where it is illegal.
73
Bill
G4WJS.
commit 8e60a966de140c14fe506f958de92a8e1b738d2c
Author: Bill Somerville <bill@classdesign.com>
Date: Fri Sep 20 02:10:58 2013 +0100
Fix Yaesu backend using illegal command on FT-2000
The FT-2000 doesn't support the SH1; command used by
the get_mode/set_mode function. This was causing a
"Protocol error" return when trying to get/set the mode
of VFO B.
Signed-off-by: Nate Bargmann <n0nb@n0nb.us>
Revise the preprocessor conditional test for MinGW variables. Tested on
all of my MinGW installations. The prior test was broken by MinGW 3.0
on Debian Unstable.
Moved all backend *.h files into the SOURCES primary as Automake
documentation states all source file types should be listed. This
causes Automake to include *.h files in rebuild rules for the targets.
Removed the '-DIN_HAMLIB' assignment from the CFLAGS primary in each
backend and assigned it to AM_CPPFLAGS in configure.ac. The effect is
the same and it simplifies the backend Makefile.am files.
Removed all commented lines.
MinGW does not natively support the POSIX sleep() function so we have
had an override that was a part of the GR_PWIN32 macro and included in
the generated config.h file. When compiling for Windows on POSIX using
MinGW, Autotools will detect sleep() and set HAVE_SLEEP which prevented
the substitution from being included in the source. Adding a test for
_WIN32 (set by MinGW's gcc) then caused a warning from src/network.c on
POSIX about winsock2.h needing to be included before windows.h. As
config.h needed to be included first, the solution to break out the
substitution that includes windows.h into its own file. This patch
provides that solution and allows the code to compile cleanly on POSIX,
using MinGW on both POSIX and Windows, and on Cygwin.
Android makefile fragments are distributed as extra distribution files
by the GNU build system but are otherwise ignored. The Android build
support is independent and does not rely on the GNU build system.
See android/README.android for more info.
Signed-off-by: Nate Bargmann <n0nb@n0nb.us>
From Michal:
"I have been playing a lot recently with PSK modes using fldigi. I have
noticed that the yaesu ft-857 backend doesn't distinguish between upper
and lower sideband digital mode (menu item 38). This causes lot of
trouble on bands where USB is used (when QSY button is pressed in
fldigi, or when calculating the real QSO frequency).
With some use of undocumented CAT features and some research I have
put together small patch, that reads EEPROM data. When SW asks hamlib
what mode is being used, hamlib will also consider the
value from eeprom.
When changing the mode in the menu, new value will become available in
the EEPROM _after_ pressing the "FUNC" button.
Setting mode from SW is left untouched, as writing to EEPROM is
potentially dangerous (and I don't feel like destroying my rig, yet)"
Signed-off-by: Nate Bargmann <n0nb@n0nb.us>
NewCAT was saving the VFO value in the private rig data structure which
is inaccessable to the front end library. Tested currVFO in rigctl with
W0MDN's FT-450.
From Mikhail Kshevetskiy <mikhail.kshevetskiy@gmail.com>
vx-1700 notes:
==============
* the only possible way to switch from VFO_A to VFO_MEM is a
switching to configured memory channel.
* vfo_op(UP/DOWN) in memory mode switch channel UP/DOWN
correspondingly
* set_mem() in VFO mode do not change memory channel, but only
remember passed value. Thus we may set non-configured memory
channel number for future use in vfo_op(OP_FROM_VFO).
* get_mem() in VFO mode returns last used memory channel value.
It may return non-configured memory channel number passed to
set_mem() previously.
WARNING: VX-1700 CAT Manual have bugs, see comments in code.
git-svn-id: https://hamlib.svn.sourceforge.net/svnroot/hamlib/trunk@3052 7ae35d74-ebe9-4afe-98af-79ac388436b8
for the latest Yaesu backends (ft9000 and later that use "New CAT"
commands) and set the default "write_delay" parameter to '0' as these
radios deault to assuming a command has been received after 10 mSec of
no data on the wire. The default write_delay had been 50 mSec (for no
good reason except I copied and pasted from older backends) which was
too long as these models implement a CAT TOT (Time Out Timer) of 10 mSec.
git-svn-id: https://hamlib.svn.sourceforge.net/svnroot/hamlib/trunk@3012 7ae35d74-ebe9-4afe-98af-79ac388436b8
* move pacing setup into ft747_open, once for all
* attempt workaround for possibly missing last byte in status command
* added set_split_vfo, get_split_vfo
git-svn-id: https://hamlib.svn.sourceforge.net/svnroot/hamlib/trunk@2857 7ae35d74-ebe9-4afe-98af-79ac388436b8
to act only in split vfo mode. freq and mode/passband will only be
modified if split is active. split_vfo reflects the proper state of split
and active TX VFO.
git-svn-id: https://hamlib.svn.sourceforge.net/svnroot/hamlib/trunk@2823 7ae35d74-ebe9-4afe-98af-79ac388436b8
* change P1 of FT100's Status Update. Returned data seems longer than documented.
* populate FT100's bandplan of ITU Region 1
* some error code checking
git-svn-id: https://hamlib.svn.sourceforge.net/svnroot/hamlib/trunk@2633 7ae35d74-ebe9-4afe-98af-79ac388436b8
Bill Somerville