Hamlib/README.betatester

Hamlib - (C) Frank Singleton 2000 (vk3fcs@ix.netcom.com)
         (C) Stephane Fillod 2000-2011
         (C) The Hamlib Group 2000-2011

Why does Hamlib need beta-testers?
==================================

Hamlib is developed by a team of radio enthusiasts around the world, for
fun, much in the spirit of ham radio. (Note that it is not restricted for
ham usage only). There are a great deal of protocols and rigs around the
world developers may not own. However, protocols may be available, so
backends can be implemented, but cannot always be tested by developers.
That's where beta-testers are so precious. On top of that, I've been told
that there's no such sure thing like bug free code.

Feedback and improvement requests are also valuable.


Okay, you volunteer as beta-tester, how to proceed?
===================================================

First of all, you can start testing official releases. They are easier to
test because they come in precompiled and packaged (.rpm, .deb, etc.) but
they have the drawback of being older than the Git repository. Reports from
these versions are still very appreciated.  Please send them to the
hamlib-developer@lists.sourceforge.net mailing list.

However, the development of Hamlib is still very active, so it's better to
test from the latest Git version of the code.  And, depending on feedback
you make, developers can commit a fix, so you can try out the change soon
after, without waiting for the next official version.

To proceed, you will have first to obtain either a daily snapshot or a check
out of the latest sources from the Git repository, then rebuild the Hamlib
package and finally test it with your rig. Don't worry, it's much simpler
than it looks, despite the size of the package.

Pre-requisite:
 - some kind of internet access
 - POSIXish compiler toolchain (gcc, GNU Autotools, Perl, etc.,
   see README.developer)


So here we go:

Daily Git master branch snapshots:
==================================

Download the latest Git master branch snapshot from:

http://n0nb.users.sourceforge.net

You'll find a tarball with a name like
hamlib-1.2.14~git-01db7a3-20110402.tar.gz, i.e. a check out made 02 Apr 2011
With a Git SHA1 of 01db7a3 (The SHA1 is a signature of each commit.  Each is
unique and as our project is small, the first seven characters for the full
20 character SHA1 are likely unique.  The shorthand SHA1 is automatically
generated and may become longer in the future.), ready for building using
the familiar "three step" (see below).  Each morning by about 1130z a new
snapshot is generated and uploaded and the prior day's version is removed.

The advantage of the Git snapshot is that you won't need as many tools
installed to build Hamlib as the work of Autoconf, Automake, and Libtool
have already been done.  Most of the other packages listed below will be
needed.  If you tell the 'configure' script to build certain parts of Hamlib
like documentation or scripting language bindings the relavent optional
packages will be needed.  See 'configure --help' for more information.

Here is a list of development packages needed for a complete build of the
library (Debian package names are listed, other distributions may differ):

* Gnu C or any C99 compliant compiler       # gcc --version
* Gnu make  (or any modern one, BSD okay)   # make --version
* libtool       2.2.6b                      # libtool --version
* libltdl-dev   2.2.6b
* Git for connection to hamlib.svn.sourceforge.net

N.B. The Debian and derivatives (Ubuntu and friends) 'build-essentials'
package will install a number of tools and minimize the number of packages
that need to be installed manually.

N.B. Hamlib requires libtool >= 2.2.6b in compliance with CVE-2009-3736.

Optional, but highly recommended for a complete build:
* GNU C++                           # g++ --version
* swig (for bindings)   1.3.14      # swig -version
* perl devel                        # h2xs
* tcl devel                         # tcltk-depends
* python devel                      # python-config
* libxml2 devel                     # xml2-config --version
* libgd2 devel                      # gdlib-config --version
* libusb devel                      # libusb-config --version (not 1.0.0!)
* RPC devel (libc-dev)              # rpcgen --version

N.B  The libusb package is required for building most of the 'kit' backend.
The older version is needed, not 1.0.0 or higher.  Debian and derivatives
package libusb 0.1.12 which is what is needed.

Documentation:
* Doxygen


Git master branch daily snapshot build:
=======================================

Reading the INSTALL file in top directory will explain in more detail how
to do the following commands.

    ./configure --disable-static --prefix=/usr/local
    make
    make install

The prefix argument is optional.  Convention is that local packages be placed
in /usr/local away from distribution installed packages and this is the default
location for the snapshots.  The --disable-static option speeds up compilation
if you don't plan to use static libraries (static libraries are usually not
needed).

Other useful options are '--with-perl-binding' or '--with-python-binding' or
'--enable-tcl-binding' if you are interested in Swig binding support for those
scripting languages (This is a change as of 1.2.11svn revision 2882 where Swig
generated bindings are no longer built by default).  If unsure it is safe to
ignore these options.

If you don't want the build files cluttering the source directories, do the
following in the same parent directory of hamlib:

    mkdir build && cd build
    ../hamlib/configure  --disable-static --prefix=/usr/local
    make
    make install

This will keep the binary output files seperate from the source tree.

NOTE!  If Hamlib has not been previously installed as a locally built
package you will need to make sure that 'ldconfig' is configured correctly
and run periodically after 'make install'.  Most modern distributions have
an /etc/ld.so.conf.d/ directory where local configuration can be made.
Later versions of Debian and derivatives have a file named 'libc.conf' in
this directory.  The contents of libc.conf are:

# libc default configuration
/usr/local/lib

If your system does not have such a file, one will need to be created and
then 'ldconfig' will need to be run as the root user so that applications
using the Hamlib libraries can find them.


Git checkout:
=============

Please read the beginning of README.developer file, especially Section 1 which
details the Git checkout, the required tools and versions (very important or
make won't even work!), and how to use the autogen.sh script.


Structure:
==========

For the brave who want to peruse the contents, here are what all the
subdirectories are for (these are just a sample as more are added from time to
time):

alinco,aor,icom,
jrc,kachina,kenwood,
pcr,tentec,uniden,
winradio,
yaesu,etc:          rig backends
easycomm,rotorez,
sartek, etc:        rotator backends
dummy:              virtual dummy rig and rotator, for developer's use.
rpcrig:             special networked rig backend (through RPC)
rpcrot:             special networked rotator backend (through RPC)
lib:                library for functions missing on your system
libltdl:            wrapper for shared module loader
bindings            Perl, Python, Tcl, and Visual Basic bindings
c++,kylix:          C++ and Kylix bindings
doc:                documentation base and scripts to extract from src
include/hamlib:     exported header files go here
include:            non-distributed header files go there
src:                Hamlib frontend source directory
tests:              rigctl/rotctl and various C programs for testing


Testing Hamlib:
===============

Don't attempt to test Hamlib from the source directory unless you're a
developer and you understand the side effects of *not* installing freshly
generated objects (basically having to mess with LD_LIBRARY_PATH and
.libs).  Do an 'sudo make install' to install the libraries in the system
area.  (You did run 'sudo ldconfig' after 'sudo make install', right?)

So here we go. First of all, identify your rig model id.  Make sure
/usr/local/bin (or the path you set --prefix to above) is in your $PATH, as
your shell has to be able to locate rigctl.

Run 'rigctl -l' to get a list of rigs supported by Hamlib.

If you cannot find your radio in the list, please report to the
hamlib-developer mailing list. The protocol manual and rig specifications
will help us a lot.

You found your rig's ID?  Good!  You're almost ready to use rigctl.
Have a quick look at its manual page:

    man rigctl
or:
    man -M /usr/local/man rigctl

or simply:
    rigctl --help

Let's say you own an Icom IC-756:

    rigctl -vvvvv -r /dev/ttyS0 -m 326

The -vvvvv is very important since this will increase verbosity, and give
precious traces to developers if something goes wrong. At this level,
the protocol data exchanged will also be dumped to the screen.

Unless some problem shows up, you should be presented with a menu
like "Rig command: ". Enter "?" followed by return to have the list
of available commands. 'Q' or 'q' quits rigctl immediately.

Most wanted functions to be tested are:
'_'     get misc information on the rig
'f'     get frequency
'F'     set frequency, in Hz
'm'     get mode
'M'     set mode (AM,FM,CW,USB,etc. and passband width in Hz)
'v'     get vfo
'V'     set vfo (VFOA, VFOB, etc.)

f,F     get_freq/set_freq       try various (<1MHz, <30Mhz and >1GHz)
v,V     get_vfo/set_vfo         VFOA, VFOB
m,M     get_mode/set_mode       FM, USB, LSB, CW, WFM, etc.
                                passband is in Hz (pass 0 for default)
G       vfo_op                  UP, DOWN
_       get_info                should give remote Id and firmware vers

NB: some functions may not be implemented in the backend or simply not
available on this rig.

When reporting to the hamlib-developer mailing list, please include traces
and also comments to tell developers if the action performed correctly on
the rig.

Tip: Traces can be hard to cut and paste sometimes. In that case, there's a
handy tool for you:  script(1) (the (1) is not a part of the command, rather
it is a Unix convention telling which section of the manual it is found, in
this case section 1, user commands.  e.g. 'man 1 script'). It will make a
typescript of everything printed on your terminal and save it to the file
you give it.

    $ script my_rig_traces.txt
    Script started, file is my_rig_traces.txt
    $ rigctl -vvvvv -r /dev/ttyS0 -m 326
    rig:rig_init called
    rig: loading backend icom
    icom: _init called
    rig_register (309)
    rig_register (326)
    rig:rig_open called
    Opened rig model 326, 'IC-756'

    Rig command: q
    rig:rig_close called
    rig:rig_cleanup called
    $ exit
    exit
    Script done, file is my_rig_traces.txt
    $

And then send my_rig_traces.txt to the hamlib-developer mailing list.


Some models need S-meter calibration, because the rig only returns raw
measurement.  It's easy, it takes only 10mn. Here's how to proceed:

 1. Fire up the rigctl program released with the Hamlib package,
    and pass along options as needed (serial speed, etc.).
 2. Tune to some frequency reporting S0 to the radio S-Meter.
 3. At rigctl prompt, issue "get_level" ('l' in short) of the level
    RAWSTR.
 4. Write down the S-level read on radio front panel, and the RAWSTR
    value retrieved.
 5. Repeat from step 2 with S9 and S9+60dB. Actually the more plots,
    the better, otherwise Hamlib does interpolation.
 6. Send the table to the hamlib-developer mailing list and it will be
    added in the next release of Hamlib.

NB: It is well known the S-Meter of any given radio is far from being
accurate. For owners with a fully equipped lab, you may want to make the
above-mentioned measurements with a good signal generator and a set of
calibrated attenuators. Greg W8WWV has an insightful page about S-Meter
calibration:

http://www.seed-solutions.com/gregordy/Amateur%20Radio/Experimentation/SMeterBlues.htm


Okay folks, test as much as you can, in the weirdest situations if
possible. There is a special prize for those who find 'Segmentation fault'
and other nasty bugs.

Needless to say, patches are also very welcome (see README.developer).  :-)


Stephane - F8CFE and The Hamlib Group