Added option to not use VFO XCHG command when setting split
parameters.
Merge branch 'change_icom_sub_access' of git://git.code.sf.net/u/bsomervi/hamlib
The NET_LIBS configuration variable was not being exapanded in the
pkgpconfig template file. This caused static builds against hamlib to
fail on Windows because the WinSock library was not referenced.
The YACK() macro generates a message of variable length due the
__FILE__ string and a message returned by MS FormatMessage() being
inserted into a fixed length string buffer. I have increased the
buffer length to 1024 bytes and used snprintf to avoid overflows.
It looks like the whole YACK() macro should do nothing unless DEBUG is
defined so there is probably a small performance gain to be had by
doing that also. I have left that to the experts to decide.
With Icom rigs that use MAIN?SUB VFOs there is a trade off when
setting the mode or frequency of the "other" VFO. Untill now Hamlib
uses the XCHG VFO command to address the "other" VFO. This has some
advantages, particularly it preserves the selected VFO and it
preserves memory mode of either VFO. The disadvantage is that any
split command causes the Rx to glitch when the VFO/MEMs are exchanged.
I have added a config parameter for Icom rigs called "no_xchg" which
forces the direct addressing of VFOs to set split mode/frequency. It
is a boolean option with a default of "0" (false) which equates to
prior behaviour. Setting it to "1" (true) will make the backend use
change VFO commands to set the "other" VFO. This means that TX on
"SUB" in split is assumed, that both are in VFO mode (not MEM), and
set/get split functions will leave the MAIN VFO selected.
MinGW was issuing the following warning:
CC rig.lo
rig.c: In function 'rig_init':
rig.c:330:36: warning: assignment makes integer from pointer without a cast [enabled by default]
rs->rigport.parm.cm108.ptt_bitnum = DEFAULT_CM108_PTT_BITNUM;
^
The constant DEFAULT_CM108_PTT_BITNUM was being defined as a string on
non-linux platforms. Now defined to an integer on these platforms. The
actual value may need to be corrected at some point in the future when
CM108 support is completed for those platforms.
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 K3 supports AFSK & FSK sub-modes and for the D versions it also
has an internal RTTY and PSK31 decoder. The decoder sub-modes are
reported as FSK (RTTY) and the AFSK sub-modes are reported as PKT(USB
& LSB). LSB modes are assumed to be RTTY and USB modes are assumed to
be PKT(PSK, WS modes etc.).
For mode set the data sub-modes are set as follows:
RTTY -> FSK D normal (LSB) VFO shows MARK QRG
RTTYR -> FSK D reversed (USB) VFO shows MARK QRG
PKTUSB -> DATA A normal (USB) VFO shows suppressed carrier QRG
PKTLSB -> AFSK A normal (LSB) optimised for RTTY VFO shows MARK QRG
Not all data sub-mode combinations are possible but the above mapping
seems most likely to cover the user requirements.
Two patches:
The first adds support for the Flex 6K series of SDR radios. These
radios have a CAT application that runs on a windows machine, and
exposes a network socket that can be opened for CAT commands. This back
end connects to that network socket and provides an interface. I've
tested pretty thoroughly using a Flex 6700 but I don't have the other
models available (6500 and 6700R). CAT support on these models is
evolving with frequent updates from Flex, and this back end does not
reflect the latest features to be added. I hope to get to them soon.
The second patch makes the easycomm interface more robust by flushing
the serial port and clearing the buffer.
Steve, AI4QR
Merge branch 'for-upstream' of https://github.com/sconklin/hamlib into sconklin-for-upstream
The "1A 06" command to get the data mode returns 2 bytes rather than
the one byte documented in the user manual.
Fix indexing error, collect data mode from correct reply byte.
It turns out that either VFO can be incorrectly set in split mode when
the VFO is the TX VFO. The logic has been changed to send an IF; query
and read and set the other VFO if the VFO just set in set_freq is the
TX VFO and the rig is in split.
The Kenwood IF command, which is used to get the current VFO, returns
the TX VFO in transmit mode. The get_vfo function needs to return the
RX VFO to be consistent and useful elsewhere. The implementation now
swaps the returned VFO if the rig is in split mode and transmitting at
the time of the query.
The TS590s with firmware revision 1.07 or earlier fails to set VFO B
frequency properly when the rig is in split mode and the TX VFO is VFO
B. The symptom is, subsequent TX is on the wrong frequency (the
previous frequency) or there is no output at all. The fix is to read
VFO A and then immediately set VFO A to the read frequency. This
effectively null sequence has the side effect of setting VFO B
properly.
Defects in the TS590s f/w can be addressed selectively according to
revision.
Enable kenwood_open function for TS590s.
For some reason the TS590s did not use the kenwood_open function, as
fetching the firmware revision may be required for this rig and it is
done in that function; it has been enabled.
The TS590s has a DA command to set USB, LSB or, FM data
submodes. Support for get and set of these sub-modes has been
added. Mapped from RIG_MODE_PKTUSB, RIG_MODE_PKTLSB and,
RIG_MODE_PKTFM respectively.
The TS-870s has no width set for SSB and AM, instead the bandwidth is
set via a high and low pass fiter setting. The backend now sets these
to try and achieve the requested bandwidth. The HPF setting is assumed
to be the default.
The bandwidth query reads both the HPF and the LPF and returns the
difference.
The value of RIG_BANDWIDTH_NORMAL skips bandwidth adjustements.
The get and set_split operations have been enabled.
The TS50S has the old FN and SP commands rather than the newer FR/FT
commands, added code to support these commands allowing split
operation to be commanded on the TS50S.
The TS480 had no split VFO functions enabled, added normal modern
Kenwood split VFO and mode handing functions.
The API calls to set split frequency and split mode were missing, I
have set them to the preexisting Kenwood functions and they seem to
work as expected. I'm not sure why they were not already enabled.
Clean up various left over commented lines from dlopen to single
libhamlib transition. Remove unneeded configure variables.
Correct minor inconsistencies in Makefile.am files.
Define a new variable, READLINE_LIBS, so that only programs that offer
Readline support are linked against it.
Fix various compilation warnings and errors in test files revealed with
'make check' on MinGW.
Define rig and rotor backends to (mostly) be built in alphabetical
order.
Split G313 sources into POSIX and Windows versions and use Automake
conditionals for building on *linux-gnu or mingw*, pw32*, or cygwin
platforms.
Fixed dlopen issue on g313 backend which broke rigmatrix generation.
Signed-off-by: Nate Bargmann <n0nb@n0nb.us>
Use AC_CHECK_LIB macro to search for libusb rather than rely on
pkg-config. Preserve environment variables LIBUSB_CFLAGS and
LIBUSB_LIBS as user precious variables. Two features,
--with-xml-support and --enable-usrp still rely on pkg-config so only
invoke pkg-config when either or both of these features are selected.
Only the Winradio g313 model uses libdl so test for it only when
Winradio backend is enabled.
From Martin, CT1IQI:
"Several programs under Linux rely on Hamlib for control. I wanted to
try WSJT-X (digital modes like JT65) and found that my new IC-7100 was
not yet supported, also after having compiled the current git version of
Hamlib and having compiled WSJT-X against that.
So I added a IC-7100 by taking the ic-7200 and 7420 rig files as
example, be it without going (yet) through all of the very many commands
the ic-7100 supports.
This produced the situation where there was communication, e.g. setting
and reading frequencies, but the PTT control did not work. I debugged
that to actually the lack of a PTT mode in Hamlib that uses serial and
CAT at the same time; currently PTT per 'serial' seems equivalent to
toggling certain RS232 pins but not to any serial command level. So I
added a RIG_PTT_SERIAL_CAT mode for PTT control. Now the wsjt-x program
works nicely with the ic-7100 and controls both frequency and PTT via
the single USB cable."
Signed-off-by: Nate Bargmann <n0nb@n0nb.us>
The IC-726 doesn't accept passband width sub commands with the mode
command. Well it does for CW, but not for other modes. I have disabled
the sending passband width sub commands for this rig to at least get
the mode setting commands accepted by the rig.
Fix IC-475A/E mode set command.
As with IC-726 very limited passband width sub commands with mode set
command so disabled all for now.
The Icom IC-7x6Pro models support AFSK data modes with Tx audio
delivered via the back ACC socket. This mode is enabled and queried
via a separate "0x1A06" command and applies to USB, LSB, FM and, AM as
USB-D, LSB-D, FM-D and, AM-D respectively on the radio. I have added
all but AM because hamlib has no mode enumeration for AM Data mode.
Most of the IC-7xxx rigs have an extended version of this special
command which also involves width. This needs further work to
implement.
Signed-off-by: Nate Bargmann <n0nb@n0nb.us>
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>
Use AC_SUBST variables for generating hamlib.pc based on local
configuration of Hamlib.
Rework libusb pkg-config section and set LIBUSB as an AC_SUBST variable.
Add the rig and rotor backends to the list of dependencies for
libhamlib.la so that updating a given backend will force libhamlib.la to
be relinked as well. Thanks to Bill Sommerville, G4WJS, for reporting
this.
Removed obsolete references and variables related to LTDL.
The IC-756 only has two filters per mode unlike the later IC-756
variants that have three. The code was sending invalid commands
due to trying to select the third filter for certain bandwidths.
Also the default filter bandwidths were incorrect for this model.
Signed-off-by: Nate Bargmann <n0nb@n0nb.us>
Bill Somerville