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>
A careful reading of the pkg-config user guide and manual page showed
some errors in the format of the generated hamlib.pc file. This patch,
hopefully, corrects those errors.
LIBUSB_LIBS was not passed to the LDADD variable for the Hamlib test
utilities. This fix permits the user invoking 'configure' to specify a
static libusb to include the libusb symbols in libhamlib:
./configure LIBUSB_LIBS="/usr/lib/i386-linux-gnu/libusb.a"
Note that the actual path will vary from system to system.
With the new registration code set the HAVE_WINRADIO preprocessor
conditional if the winradio backend is to be built and test this
conditional in src/register.c whether to build winradio support.
rig_open was giving RIG_DEBUG_ERR messsages if PTT or DCD
port was unavailable but the function was not returning an
error status.
Signed-off-by: Nate Bargmann <n0nb@n0nb.us>
On the Peaberry forum, we have a thread with some hamlib patches for the
Peaberry SDR (a softrock-like transceiver). Both version 1 and version 2
have been implemented and tested.
There are two patches: the first one, made by me (ON8VQ) adds support
for the two radio's, and the second one, made by R2AEE, fixes the tuning
(using PICUSB commands instead of AVRUSB).
The patches are available here:
http://ae9rb.com/forum/viewtopic.php?f=4&t=166
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.
No longer depend on libltdl from the libtool package. The
winradio/linradio/wg313api backend still depends on libdl, but since it
is only compiled on POSIX, it will use the POSIX supplied libdl.
Update documentation to remove references to libltdl.
Hi,
patch attached to enable the above which was partially coded but not
quite working.
73
Bill
G4WJS.
>From 9dab3a250dfad7203772df91aadf79d38c108f04 Mon Sep 17 00:00:00 2001
From: Bill Somerville <bill@classdesign.com>
Date: Fri, 6 Sep 2013 01:13:34 +0100
Subject: [PATCH] Fix using same serail port for PTT and CAT
src/rig.c was coded to allow the same serial port for PTT and
CAT but them tried to open the port twice. I have added code
to share the file descriptor in this situation.
Signed-off-by: Nate Bargmann <n0nb@n0nb.us>
The attached patch restores what I think is the original easycomm
rotator interface functionality. It eliminates the conditional code
for USE_CUSTOM_CODE and USE_TEST_CODE.
Apparently for a very long time, the easycomm back end has been build
with USE_CUSTOM_CODE hardcoded in the source file. This generated code
that issued commands not even remotely similar to what's specified in
the easycommII protocol, which is documented in the easycomm directory
for hamlib.
It appears that at some point someone used the easycomm back end to
implement some custom tests for something, and it was committed and
has been carried this way ever since.
This restored what I think is proper functionality according to the
easycomm spec.
If you are a user of the easycomm back end, or you know of any
easycomm compatible rotor controllers that can be used for testing,
let me know and I can be more thorough about this.
Notes and disclaimers:
0. The original easycomm spec author seems to be unavailable.
1. I don't think that there was valid code to parse the position data
returned from the rotor controller. What was actually getting compiled
simply set some hard-coded values. I replaced it with what I think is
called for by the spec.
2. The easycomm spec is vague about what is supposed to be returned
for any command, so I may still not be parsing position information
correctly as it comes from other easycomm controllers.
3. I wrote my own rotator controller code based upon an interpretation
of the easycomm II spec. This back end for rotctl works with my
implementation. I don't have access to any other easycomm controllers
or even know whether any exist, so I am unable to test this against
any other implementation of easycomm.
4. Even when you select EASYCOMM II as the back end, it sends commands
which are only supposed to be valid for easycomm I according to the
spec (i.e. the position set command includes uplink and downlink
frequency and mode information fields). My rotor controller handles
these, so I didn't change the position set portion of the code.
I understand if there's concern for breaking rotator control for
existing users of the easycomm back end (if any actually exist). If
this patch is too risky, I'll either rewrite my controller to use
another protocol, or add another back end for my own newly invented
protocol "ai4qrcomm" (and document it better than easycomm).
Thanks,
Steve, AI4QR
Signed-off-by: Nate Bargmann <n0nb@n0nb.us>