Hamlib - (C) Frank Singleton 2000 (vk3fcs@ix.netcom.com) (C) Stephane Fillod 2000-2011 (C) The Hamlib Group 2000-2013 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 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, make, C library development headers, etc., see README.developer for a complete list and building from a Git checkout) 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-3.0~git-30e58df-20121009.tar.gz, i.e. a check out made 09 Oct 2012 With a Git SHA1 of 30e58df (The SHA1 is a signature of each commit. Each is unique and as our project is small, the first seven characters for the full 40 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 the GNU Build System has 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 relevant 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 (gcc) or any C99 compliant compiler # gcc --version * Gnu make (or any modern one, BSD okay) # make --version 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. Optional, but highly recommended for a complete build: * GNU C++ (g++) # g++ --version * swig (for bindings) 1.3.14+ # swig -version * perl devel # h2xs * tcl devel # tcltk-depends * python devel # python-config * zlib devel # Needed by configure's test for Python * libxml2 devel # xml2-config --version * libgd2 devel # gdlib-config --version * libusb-1.0 devel # ver 1.0 or newer (not 0.1!) * libreadline devel # ver 5.2 or newer N.B The libusb package is required for building most of the 'kit' backend. The newer version is needed, not 0.1. Debian and derivatives package libusb-1.0 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 [--prefix=$HOME/local] make make check make install The prefix argument is optional. Convention is that local packages be placed in /usr/local away from distribution installed packages This is the default location for the snapshots so it may be disregarded unless you wish to install Hamlib elsewhere. The example above would install Hamlib to the user's home directory under the 'local' subdirectory. Other useful options are '--with-perl-binding' or '--with-python-binding' or '--with-tcl-binding' if you are interested in Swig binding support for those scripting languages If you are unsure it is safe to ignore these options. 'make' will run the C and, optionally, the C++ compiler building all of the binary object files and finally linking all of them together to form the Hamlib "frontend" and "backend" libraries. The 'make check' target will run a few predetermined tests using the 'dummy' (rig model 1) backend and some other Hamlib functions in the build tree. This is a basic sanity check and cannot test all backends. The 'make install' target will require super user (root/administrator) privileges when installing to the system directories as a normal user. Some Linux distributions offer the 'sudo' command to grant temporary root privileges or the 'su' command to login as "root". Consult your distribution's documentation. 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 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. To delete the binary files from the source directory after compiling: make clean To also remove the Makefiles and other build files generated by 'configure', along with the binary files as with 'make clean' above: make distclean The 'configure' script will need to be run again as above. The above commands will clean things up so Hamlib can be compiled with other configure script options. To remove Hamlib from your system: sudo make uninstall Note that due to a limitation in a Perl support script that if the Perl binding is built and installed that not all of the files under /usr/local/lib/perl/PERL_VERSION will not be removed. 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 bootstrap 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): rigs: rig backends rotors: rotator backends rigs/dummy: virtual dummy rig and rotator and other non-rig devices, for testing use. lib: library for functions missing on your system bindings Perl, Python, Tcl, and Visual Basic bindings c++: C++ 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. Some backends produce a useful amount of data regarding function calls and critical variables with the -vvvv option without all the protocol data. 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