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>
The C standard dictates that an enum constant is a 32 bit signed
integer. Setting a constant's bit 31 created a negative value that on
amd64 had the upper 32 bits set as well when assigned to the
misc.c:func_str structure. This caused misc.c:rig_strfunc() to fail its
comparison for RIG_FUNC_XIT on amd64 (x86_64). To use bit 31 as an
unsigned long, preprocessor macros have been used instead as a 'const
unsigned long' which cannot be used to initialize the func_str.func
members. TNX KA6MAL, AC6SL. - N0NB
Other minor formatting edits.
Hi all,
just found a minor problem in the configure.ac file for hamlib 1.2.15.3.
Back in 2007 Stephane added some checks to make the build system
respect pthreads (see commit from 11 Sep 2007). In that he added some
line to modify CFLAGS and CXXFLAGS (see lines 87.. in configure.ac)
ACX_PTHREAD
if test x"$acx_pthread_ok" = xyes; then
CFLAGS="${CFLAGS} ${PTHREAD_CFLAGS}"
CXXFLAGS="${CFLAGS} ${PTHREAD_CFLAGS}"
fi
These code let the build system ignore the CXXFLAGS setting by replacing
it by CFLAGS. I just checked that these error affects only the
building of the c++ bindings. So it shoudl be easy to fix.
Correct version should do
CXXFLAGS="${CXXFLAGS} ${PTHREAD_CFLAGS}"
instead. See the attached patch.
73, de Tom DL1JBE.
Signed-off-by: Nate Bargmann <n0nb@n0nb.us>
Note that this bug that affected the Hamlib-1.2.15 and earlier branches
also has affected the master branch. This is now corrected and CXXFLAGS
is preserved through configure.ac.
If pkg-config is not installed, a very cryptic error occurs when
autogen.sh runs the configure script. Add a check from:
http://lists.gnu.org/archive/html/automake/2011-03/msg00008.html
to check for pkg-config presence and if pkg-config is not found, a stub
macro disables any configuration of any feature relying on its presence.
The rigctl and rigctld programs support a so far undocumented feature of
being able to query supported modes in set_mode and set_split_mode,
Funcs in set_func and get_func, Levels in set_level and get_level, Parms
in set_parm and get_parm, as well as the vfo_op, scan, ans set_trn
functions. The query may be used to get a list of supported tokens for
a given function by a rig backend.
For the K3 RIT/XIT are now explicitly turned On/Off by calling
rig_get/set_func() and passing RIG_FUNC_R/XIT and the status of 1 or 0.
When setting the RIT/XIT offset by calling rig_set_r/xit, an offset of 0
will clear the RIT/XIT offset but will no longer turn the RIT/XIT
function Off. Likewise, an offset can be set but not active until the
RIT/XIT function is explicitly turned On.
In response to a long standing request from Tor, N4OGW, and others, RIT
and XIT are added as members for the rig_set/get_func() members.
"RIT"/"XIT" have been added as tokens. The dummy rig backend and
testrig.c have been updated for these new functions.
Applications should test a backend with the rig_has_set/get_func() and
test for RIG_FUNC_RIT or RIG_FUNC_XIT. A non-zero result indicates
these functions are implemented by a given rig backend. It will take
some time for all backends to migrate to this new implementation. Once
implemented, RIT or XIT should be set to '0' to 'clear' the value
without deactivating the rig's RIT/XIT function. The dummy/dummy.c file
can be used as a simple guide for backend authors implementing this
behavior.
Various fixes for building the bindings properly.
Install TCL binding to $(libdir)/tcl/Hamlib, arbitrarily chosen since
there seems to be no standard installation location. When install
location is changed, tcltest.tcl documents the needed change to a TCL
script.
In the Perl and Python test scripts, improved the QRA examples. In all
scripts used tabs to line up printed values nicely.
Updated INSTALL and NEWS for recent updates. Better documented bindings
installation and uninstallation in INSTALL.
Use ax_pkg_swig.m4 from the GNU Autoconf Macro Archive as it is actively
maintained and update configure.ac accordingly.
Moved the Swig test to the bindings section of configure.ac.
Refactored the logic of the Swig test.
Updated ax_python_devel.m4 to latest version in the Autoconf Macro
Archive (removes two email addresses, not other changes).
Removed aclocal-include.m4 and lf_warnings.m4 as they were not being
used any longer.
Update macros definitions in macros/Makefile.am to recent additions and
deletion of the local macro files.
Stephane Fillod