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>
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.
Use the system gettaddrinfo function when possible as before. Tested on
GNU, Cygwin, MinGW on Linux, and MinGW on Windows. Under MinGW the
replacement getaddrinfo is used. Perhaps this is an area for
investigation to be certain MinGW really doesn't supply getaddrinfo.
This reverts some of the patches from Remi Chateauneu in commit
60019c9. This fixes build issues encountered building the Windows
binary daily snapshots.
Enabled static library build by default at configure time.
Fixed pthread library linking for the ars backend on MinGW.
Quell the following error on MinGW:
CC orion.lo
In file included from ../../hamlib-3.0~git/tentec/orion.c:86:0:
../../hamlib-3.0~git/tentec/orion.h:34:0: warning: "TRUE" redefined [enabled by default]
c:\mingw\bin\../lib/gcc/mingw32/4.6.2/../../../../include/windef.h:55:0: note: this is the location of the previous definition
../../hamlib-3.0~git/tentec/orion.h:35:0: warning: "FALSE" redefined [enabled by default]
c:\mingw\bin\../lib/gcc/mingw32/4.6.2/../../../../include/windef.h:52:0: note: this is the location of the previous definition
which seemed to be caused by the values to TRUE and FALSE being enclosed
in parentheses.
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.
GCC 4.8.x revealed an error in the way the destination buffer size was
calculated for storing the K3 firmware revision. Now, instead of
declaring the array in the kenwood_priv_data structure, it is declared
as static in elecraft.c and a pointer is now assigned in the
kenwood_priv_data structure. This allows for proper calculation of the
array size for strncpy().
73
Bill.
>From 5209463ba169516543e2666b8b3a98b605c362e6 Mon Sep 17 00:00:00 2001
From: Bill Somerville <g4wjs@classdesign.com>
Date: Sat, 20 Jul 2013 01:45:01 +0100
Subject: [PATCH] All IC-756 varieties have MAIN/SUB VFOs rather than A/B VFOs
In the past IC-756ProIII capabiities have been updated to use MAIN/SUB VFO
commands but as far as I can tell from the user manuals for the IC-756,
IC-756Pro, IC-756Pro2 all varieties have the MAIN/SUB VFOs and need to use
the correct VFO access sub command.
I have an IC-756 and discovered this defect via WSJT-X which as of v1.1
requires split operation setup.
Signed-off-by: Nate Bargmann <n0nb@n0nb.us>
I have now written a new rotor control based on an Atmel ethernet board
and used with me. It works well so far.
Signed-off-by: Nate Bargmann <n0nb@n0nb.us>
The Automake manual makes it clear that certain user variables such as
CC, CFLAGS, CXXFLAGS, CPPFLAGS, and so on are to be preserved for the
user running configure. This patch cleans up such assignments and
assures that PTHREAD_CFLAGS and so forth are applied to those targets
that require it.
Trying to run the pthread enabled binaries on W2k resulted in an error
dialog with the text, "The procedure entry point freeaddrinfo could not be
located in ws2_32.dll". A Microsoft support page
(http://support.microsoft.com/kb/955045) hints that when 'ws2tcpip.h' is
included that 'wspiapi.h' should be included as well. Since MinGw
includes both files, this patch corrects the runtime error on W2k
The AX_PTHREAD macro sets the PTHREAD_LIBS variable, however we were not
providing this variable to the needed *_LDFLAGS variable. With the
addition of PTHREAD_LIBS, rigctld and rotctld are now multi-threaded on
MS Windows. Tested on Windows 2000, Windows XP, and Windows 7.
Setting LD_LIBRARY_PATH for testcpp and testrig in the generated test
shell scripts corrects a long-standing bug that broke 'make check'.
Add Hamlib_design.eps to allow 'make dvi' to succeed when running
'make distcheck'.
Summary from Lada:
On Win7, good testing command is:
C:\hamlib> rigctl -vvvvv -m 214 -r COM1 -s 4800 -C data_bits=8 -C
stop_bits=2 -C serial_handshake=Hardware -C timeout=1000
Behavior of this command differs on COM port. On hardware ports
(onboard, PCI NetMos, all probably 16550-compatible) rigctl freeze in
data write. It is correct, no hardware handshake is estabilished. On
FT232 USB port initialization failed by timeout. I think it is not
correct but this is not subject of this e-mail.
Looked into hamlib source and found, that timeout argument is no
longer handled. SetCommTimeouts takes timeout from c_cc[VTIME] which
is not filled.
Signed-off-by: Ladislav Vaiz <spam@nagano.cz>
Nate Bargmann