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.
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.
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.
A Perl file was being compile whether Perl binding was enabled or not.
Fixed that and configured an AM_CONDITIONAL for Perl so its components
will not be built when it is not enabled.
"[This patch] allows PCR radios to use DSP units correctly for the first
time under Hamlib.
We're all familiar with a typical DSP presentation on a radio -- you can
turn it on and off, you can adjust the degree of noise processing, and
you can sometimes even enable a notch filter. In the PCR radios
that have a DSP installed, none of this worked until now.
I corrected the code in pcr.c, changes that apply to all the PCR radios,
and in pcr1500.c, the radio I have, but someone else will have to
edit the files for the radios I don't own so the user interface works
right. I decided it would be unwise to try to edit files for radios
I couldn't test.
I just re-read the above, and I need to add that the changes to prc.c
shouldn't adversely affect the PCR models other than the one I own."
Signed-off-by: Nate Bargmann <n0nb@n0nb.us>
* The 746 has an APF, wasn't in its configuration, added, tested, works.
* The 756Pro has an ANF function, wasn't in its configuration, added,
tested, works.
* The 756Pro's signal strength conversion table was way wrong.
I noticed this while making scope plots in my program JRX --
the strong signals using the STRENGTH output would all flatten
out at a rather low level, but the RAWSTR output showed the
full range. Changed the conversion table, tested, fixed.
R8500 notes:
The R8500 on/off functions work differently than the other Icoms,
in fact it's not too strong to say that this radio is a breed apart.
Most Icom radios have a group command code for on/off functions (16),
then a code for the function, then a flag for on or off. The R8500
combines the second and third into one, and this required a bit of
recoding in "icom.c". Interestingly, someone had created some special
designators in "icom_defs.h" for the R8500, but then never coded them
to the degree that they worked. Now they work. :)
So the AGC, NB and APF functions all work now.
The R8500 doesn't have a preamp control, so I took that out.
The R8500 does have IF shift and a 3-step attenuater, so I put those in.
Signed-off-by: Nate Bargmann <n0nb@n0nb.us>
As AC_CHECK_HEADERS and AC_CHECK_FUNCS take multiple file names,
consolidate the multiple macro calls into a single call for each.
Remove the last obsolescent macro calls.
"I've re-written the hamlib backend to stream the audio, if and spectrum
pcm samples to simple file system objects.
If no path is given, streaming is not requested. If the path can't be
openned, no streaming is requested.
The file is openned non-blocking and overruns are just silently
discarded.
I've tested it using named fifos and if there is no active reader it
fails to open and if there is an active reader it streams fine.
Thats as simple as it can get.
In terms of the project files, I've put the wrg313api.c and wrg313api.h
files in the existing linradio subfolder of winradio.
The .h file is the g313 equivalent of the wrapi.h file already there.
The .c file actually just contains the dlopen and the assignments to the
function variables.
The actual API shared library is binary only (and 32-bit only), and not
included in my patch."
Signed-off-by: Nate Bargmann <n0nb@n0nb.us>
From the SourceForge tracker:
I am using version hamlib-1.2.15.2~rc3. Start rigctl and specify rig 2
(rigctld). The command "s" (get_split_vfo) will return two parameters,
the spilt state (0 or 1) and the TX VFO name. The command "S"
(set_split_vfo) will send one parameter, the TX VFO name, but will not
send the split state (0 or 1). This is incorrect. In the file
dummy/netrigctl.c change netrigctl_set_split_vfo() line 782:
len = sprintf(cmd, "S %s\n", rig_strvfo(tx_vfo));
to include the "split" paramater; perhaps:
len = sprintf(cmd, "S %d %s\n", split, rig_strvfo(tx_vfo));
Thanks to Jim, N2ADR for reporting this.
If libgd-dev is not installed, an Automake conditional will disable the
rigmatrix.html target in tests/Makefile. Optionally, this target may
also be disabled by use of the '--disable-html-matrix' option passed to
the configure script. By default the configure script will enable the
target if the libgd development files are found and disable it when they
are not.
Previously, invoking autogen.sh would create symbolic links to needed
Autotools files in the tree only when working from a Git checkout
(source distributions have the files included). Consideration of this
included the possibility of bugs if the Autotools packages were upgraded
on the developer's system that strange bugs could result. Copying the
files means the tree is self contained until the next time autoreconf or
autogen.sh is run.
The top level Makefile.am included the variable $(subdirs) in both
SUBDIRS and DIST_SUBDIRS assignments. While this variable may contain a
useful value, it is undocumented in the manuals. Relying on it may
result in some directory being ommitted or other changes in the future,
so removing it from the assignments.
Static libs are generally not wanted so disable their builds by default.
Remove references to '--disable-static' from documentation and example
scripts.
I found that building on Cygwin that when libxml2 is installed, MSYS
fails the compile as libxml2 is installed outside the MSYS idea of
'root'. As this feature depends on an external library, give user the
option of compiling with this support. Default is to not build rigmem
with XML support.
Nate Bargmann