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.
As commands from a previous session may not be desired, make reading the
history file at rotctl start and writing to it at rotctl close optional
by use of the -i/--read_history or -I/--save-history options.
Compilation is conditional on having Readline and Readline History
support detected at build system configuration time.
History is stored in '$HOME/.rotctl_history' by default. An alternate
path may be specified by setting the ROTCTL_HIST_DIR environment
variable:
$ ROTCTL_HIST_DIR=~/.rotctl rotctl -iI
will temporarily set the history directory to /home/USER/.rotctl and
create .rotctl_history if it does not exist. If the file cannot be read
or written a warning message will be given on stderr.
Implement first cut at storing and recalling history. At this point
history is retained for the current session only.
History is stored as complete command lines even if values are entered
at separate prompts. Readline allows editing and even deleting recalled
history lines.
Initial implementation of Readline input handling. Only if 'configure'
finds Readline will it be enabled and when enabled it will only be used
by rotctl in interactive mode. Passing rotator commands from the rotctl
command line and rotctld use the original input handling which has not
been modified.
Document Readline and history additions to rigctl along with new
-i/--read-history and -I/--save-history options.
Document use of RIGCTL_HIST_DIR environment variable to set an alternate
path for the .rigctl_history file.
Other minor edits.
As commands from a previous session may not be desired, make reading the
history file at rigctl start and writing to it at rigctl close optional
by use of the -i/--read_history or -I/--save-history options.
Compilation is conditional on having Readline and Readline History
support detected at build system configuration time.
History is stored in '$HOME/.rigctl_history' by default. An alternate
path may be specified by setting the RIGCTL_HIST_DIR environment
variable:
$ RIGCTL_HIST_DIR=~/.rigctl rigctl -iI
will temporarily set the history directory to /home/USER/.rigctl and
create .rigctl_history if it does not exist. If the file cannot be read
or written a warning message will be given on stderr.
Implement first cut at storing and recalling history. At this point
history is retained for the current session only.
History is stored as complete command lines even if values are entered
at separate prompts. Readline allows editing and even deleting recalled
history lines.
Initial implementation of Readline input handling. Only if 'configure'
finds Readline will it be enabled and when enabled it will only be used
by rigctl in interactive mode. Passing rig commands from the rigctl
command line and rigctld use the original input handling which has not
been modified.
Due to the changes of the patch contributed by Ervin Hegedüs, correct
the bindings test scripts to work with the corrected ordering of VFO and
frequency arguments.
Also add a call to send_morse() in each script.
I made a patch, you can see in that there is the solution, which
describe the error: if a function in hamlib looks 3 argument
(rig, vfo, any 3rd arg), the order of the 2nd and 3rd argument
were reversed, because the macro METHOD1 reversed them.
I've collected these functions, compared its arguments with
hamlib docs (http://hamlib.sourceforge.net/manuals/1.2.15/), and
where 1st arg is rig, 2nd arg is vfo, and 3rd is any kind of
type, changed to METHOD3, which is a new macro, and keeps the
correct order of original function - see the patch. (I didn't
find any info about the expected diff format, so I just created
the `diff -uprN ORIG NEW'.)
To check my theory, I've tested with another function, which uses
vfo type at 2nd argument, eg. rig_set_freq; here is the Python
code:
my_rig.set_freq(Hamlib.RIG_VFO_A, 7013200.0)
and the original code drop the exception:
my_rig.set_freq(Hamlib.RIG_VFO_A, 7012500.0)
File "/usr/local/lib/python2.7/dist-packages/Hamlib.py", line 2513, in
set_freq
def set_freq(self, *args): return _Hamlib.Rig_set_freq(self, *args)
TypeError: in method 'Rig_set_freq', argument 3 of type 'vfo_t'
As you can see, it's same as my original error above.
So, after I patched the source and recompiled it again, these two
function works correctly - I will test it at soon, but I think
_this_ is good and stable.
Signed-off-by: Nate Bargmann <n0nb@n0nb.us>