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.
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>
Torsten Eberhardt