This patch fixes a frequency overflow problem on kenwood and yaesu that
can occur with frequencies that over a 32-bit signed int. This has been
shown to fix the problem on kenwood.
73
Mike W9MDB
As Hamlib now restores the rig auto information state (AI) on exit
there is now a need to disable that functionality so that rigctl can
be used to set/reset AI mode on the rig explicitly.
A new public API function 'rig_no_restore_ai()' is also added that
allows any client to disable this auto AI restore functionality if
required. Most clients should do nothing as restoring AI state is a
good thing.
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.
As with Kenwood, the new style Yaesu rigs do not ACK set commands.
Rather than wait for an error, it is quicker to send a follow up
simple query (e.g. ID;) and read the reply, if it is a valid response
then the original set command worked; if it is a NACK response e.g. ?;
then the original command failed. Use this mechanism to initiate
retries of the original command.
Attached fixes some problems with the Yaesu FT-991 exposed by recent
WSJT-x releases.
Made Yaesu newcat_get_cmd globally available.
Fixes a small bug in a debug print for frequency.
Adds a couple of TRACE debugs.
FT-991 now does split mode.
Tested and working on WSJT-X r5675 JT65/JT9 and WSPR mode.
73
Mike W9MDB
All,
attached is a git patch for adding the Yaesu FT-DX1200 radio to the yaesu
backend as model 134. I am humbly asking for this to be included in
hamlib.
I've tested this using a 1200 radio, using both rigctl and cqrlog. The
ft-dx1200 cat commands are a mix of ft-950 and ft-2000 radio commands, so
neither of those models will work correctly with the 1200. It was tested
and build against the master branch from github on 4/3/2015, on an Ubuntu
14.04 server.
Let me know if you have any questions.
thanks
Dave
kk6df at arrl.net
From cc0351fddc245b6223ae6c21dc6e29c5422fc822 Mon Sep 17 00:00:00 2001
From: David Fannin <dfannin@sushisoft.com>
Date: Sat, 4 Apr 2015 09:23:49 -0700
Subject: [PATCH 1/2] adding yaesu ft-dx1200 model to yaesu backend
On the FT450 one must select the target VFO using the VSn; command
before attempting to change the frequency. Ths change does that and
reverts the current VFO if necessary.
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.
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 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>
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.
Added null pointer ctcss_list test
Changed newcat_set_mode width sets to after mode set
Changed newcat_power2mW, newcat_mW2power to allow all nc rigs
git-svn-id: https://hamlib.svn.sourceforge.net/svnroot/hamlib/trunk@2528 7ae35d74-ebe9-4afe-98af-79ac388436b8
Michael Black