This flag can be used by back ends that need to take special action
while the rig is transmitting e.g. the FT-747GX and similar that do
not process CAT commands while transmitting.
The flag is also used as a default answer to rig_get_ptt if nothing
better is available.
Deal with inaccurate CAT query for Rx/Tx on the Yaesu FT-847
This rig doesn't set the Rx/Tx status flag when PTT is asserted via
the PTT pin on the rear PACKET socket so we need to override which we
can do if we known we have asserted PTT via rig_set_ptt().
Adjust style and fix set PTT defects
Fix a warning from a declaration of a deleted function definition
Separate FT-891 features
Fix rigctl and rigctld to not abort on function not available
Change Yaesu detection of FA length to automatic method instead of rig specific
The FT817-ND only has RTTY, PSK31-L, PSK31-U, USER-L, USER-U as
possible DIG MODEs. Before this fix, the modes read by Hamlib were
completely wrong.
The RTTY mode in the FT817-ND is USB. I think that the corresponding
Hamlib mode is RIG_MODE_RTTYR but I'm not certain if this is supposed to
be USB or LSB.
This has been tested on an FT817-ND. The FT817 might be different.
The FT991 only receives on VFO A, VFO B is only used for split Tx or
for exchanging with VFO A. There are no commands to set or query VFO B
mode. Added a set split mode function that saves VFO A mode and VFO b
frequency then sets the required VFO B mode into VFO A and then copies
VFO A to VFO B and restores the VFO B frequency and VFO A
mode. Bandwidth and narrow settings are not touched.
Several functins that had been implemented specifically for the FT991
have been removed because existing newcat.c functions were suitable or
there should not have been a function as the rig doesn't support it.
this rig is prone to giving transitory busy responses to CAT commands,
the retry mechanism for set commands was looping rather than accepting
the results of a successful command verification read. This is fixed
and the notification trace message is reduced to a warning.
This change allows the set_mode functions to leave the rig passband
unchanged if required. For the few rigs that do not have explcit
passband width control either current state is read and rewritten or a
"normal" width is chosen e.g. select a normal width when there is a
choice like CW and CW-NARROW.
It seems like || was used where && was intended here. Currently, the
conditions are always true, and there's no reason for them to be written
this way.
Found with Coccinelle.
This optimized implementation takes advantage of the CAT protocol
command to set both frequency and mode at the same time. It also only
needs to switch VFOs once either side of the command.
Adds a new config param "-C fakefreq=1"
The ft757gx only has one-way comm so this simply returns the last freq
set.
WSJT-X can operate in fake it split mode with this too.
RRR
Mike W9MDB
Fix typo in ft990.c
Remove unused var in newcat.c
Make rit and xit use labs() to match data type
Fix frequency print in newcat.c to use PRIll
RRR
Mike W9MDB
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
Correctly read SPLIT status TX STATUS is documented incorrectly.
Implement get_split_vfo () on all rigs.
Allow either RTTY or PKTUSB to be set, both go to DIG mode and rig
must be set appropriately. get_mode() returns what is actually set for
the rig DIG mode.
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.
A small patch. Allows the FT-991 to work with Fake Split in WSJT-X.
FT-991 Rig Split does not work due to audio routing (at least not with
the USB port).
The 991 needs a delay after transmit is turned off and 50ms works.
73
Mike W9MDB
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.
Bill Somerville