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>
Under Windows, the Icom transceive messages do not get flushed
properly. Returned data is cached in windows serial buffer and
are received by hamlib as response to initial request.
Lada suggested to add PURGE_RXCLEAR flag to tcflush (lib/termios.c),
actually clearing and making the buffer empty.
Look at http://msdn.microsoft.com/en-us/library/windows/desktop/aa363428%28v=vs.85%29.aspx
PURGE_RXABORT only terminates overlapped reads but not input buffer.
Nate suggested to add the PURGE_TXCLEAR flag to the output queue as well.
Signed-off-by: Ladislav Vaiz <spam@nagano.cz>
Signed-off-by: Nate Bargmann <n0nb@n0nb.us>
Distribute the Texinfo generated HTML manual which includes
documentation on rigctl, rotctl, rigctld, rotctld and no longer
distribute their respective PDF files in the MS Windows binary releases.
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>
Building libltdl recursively with MinGW failed with an error of "sleep"
being redefined. Commenting out the sleep() definition in config.h.in
resulted in libtdl compiling but a linker failure in libyaesu as
"_sleep" was not defined.
A bit of searching reveals that the MS Windows API does not include
"sleep" and MinGW does not include it either, hence the definition in
gr_pwin32.m4 from the GNU Radio project. Uopn finding a MinGW User
thread from 2007 that discussed this very issue, the following message
hinted that using a CPP #define to wrap Windows Sleep() may work:
http://mingw.5.n7.nabble.com/Help-where-is-the-C-language-sleep-function-tp8921p8925.html
And indeed it seems to. Compilation is now clean with recursive libltdl
and the rest of Hamlib, but does it work?
Building libltdl recursively now eliminates the second 'configure' run
inside the libltdl directory and requires the distribution of fewer
files and quiets compilation.
Also, if the 'configure' option '--with-included-ltdl' is not passed and
a system libltdl is found, the included libltdl directory will not even
be built. Only when the included libltdl is needed will it be built.
Building PDF may be problematic with older texinfo tools so don't build
or distribute the PDF version of the manual. On systems with a newer
texinfo installation, 'make pdf' will generate a print version of the
manual.
Merge in initial draft of Hamlib manual written in texinfo.
Output in info, HTML, and PDF formats is supported and included
in distribution tarballs from now on.
Make working with the texinfo files more manageable by splitting the
large chapters into their own files.
Actually include the texinfo files into the source distribution.
I've found a problem with my setup. I'm using a Yaesu G-5500 with an
arduino running:
http://blog.radioartisan.com/yaesu-rotator-computer-serial-interface/
to emulate a GS232b.
The problem is that the Elevation in rotctl was incorrectly reported,
with the least significant digit show. The problem I've found is some
incompatibility between the format of the answer and the parser. Here
I'm pasting a new version of gs232b_rot_get_position() which both solves
my issue and should be a bit more reliable to protocol differences,
while simpler than the previous.
(a white space in sscanf() matches none or any number of whitespaces, my
emulated GS232B was reporting AZ=123EL=033 with no spaces. This got
broken recently, and I haven't touched the code running in the arduino).
Signed-off-by: Nate Bargmann <n0nb@n0nb.us>
After much consideration, texinfo was chosen for the Hamlib manual.
Initially Docbook had been considered and then abandoned. Doxygen
generated output from the source files has filled that role since but
experience has shown that more explanation would be useful. ASCIIdoc
had been considered and while HTML and PDF outputs are possible, GNU
info style documentation seems not to be. Texinfo provides for all
three and is easily integrated into Automake and enables version and
update variables generated by Autotools to be easily integrated into the
documentation.
The manual is released under the GNU Free Document License with no
invariant sections and no cover texts. This meets the current Debian
Free Software Guidelines.
Document Readline and history additions to rotctl along with new
-i/--read-history and -I/--save-history options.
Document use of ROTCTL_HIST_DIR environment variable to set an alternate
path for the .rotctl_history file.
Other minor edits.
Ladislav Vaiz