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

* Why does Hamlib need beta-testers?

Hamlib is developed by a team of enthusiasts around the world, for fun,
much in the spirit of hamradio. (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) but they
have the drawback of being older than the SVN repository. Reports from these
versions are still very appreciated, on 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 SVN 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.

So to proceed, you will have first to obtain either a snapshot or a check out
of the latest sources from SVN, then rebuild the Hamlib package and finally
test it with your rig. Don't worry, it's much simpler than how 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 SVN trunk snapshots:

Download the latest SVN trunk snapshot from http://n0nb.users.sourceforge.net
You'll find a tar ball with a name like hamlib-1.2.10svn-20090306.tar.gz,
i.e. a check out made 06 Mar 2009, 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 SVN 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 in README.developer 
will be needed unless you tell the `configure' script to not build certain 
parts of Hamlib like documentation or scripting language bindings.  
See `configure --help' for more information.


* SVN checkout:

Please read the beginning of README.developer file, especially about how to
obtain a SVN checkout, what are the required tools and versions (very 
important or make won't even work!), and how to use autogen.sh.


* 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.

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.


* 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):

alinco,aor,icom,
jrc,kachina,kenwood,
pcr,tentec,uniden,
winradio,yaesu:		rig backends
rpcrig:			special networked rig backend (through RPC)
rpcrot:        		special networked rotator backend (through RPC)
easycomm:		rotator backends
dummy:			virtual dummy rig and rotator, for developer's use.
c++,tcl,kylix:		C++, tcl, and Kylix bindings
lib:			library for functions missing on your system
libltdl:		wrapper for shared module loader
debian:			debian package scripts
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 source directory unless you're a developer
and you understand what are the side effects of *not* installing freshly
generated objects (basically having to mess with LD_LIBRARY_PATH and .libs).

So here we go. First of all, identify your rig model id.  Make sure 
/some/where/bin is in your $PATH, as rigctl has to be reachable. Run 
`rigctl -l' to get a list of rigs supported by Hamlib.

If you cannot find yours in the list, please report to the hamlib-developer
mailing list. The protocol manual and rig specifications will help 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 /some/where/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 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). It will make
    a typescript of everything printed on your terminal.

    $ 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 needs 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: you have to know the S-Meter of radio's is far from being accurate.
For owners with a fully equipped lab, you may want to make the up-mentioned
measurements with a good Signal Generator and a set of calibrated attenuators.
Greg W8WWV has an insightful page about S-Meter:
    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 :-)


Stephane - F8CFE and The Hamlib Group