This manual is for Ham Radio Control Libraries (Hamlib) (version 3.3, 20 August 2018).
This manual documents Hamlib, a programming library and various supplied programs, which is Free Software. Besides often being distributed at no cost to you, Free in this context means that the copyright holders to Hamlib have agreed to offer their collective work under terms that give you certain rights that allow you to modify and/or redistribute Hamlib under the same terms that you received it from them.
Such licensing is often termed copyleft as a play against the common “all rights reserved” terms of normal copyright. In general, copyleft provides everyone with a license to modify and distribute the modified work or to simply distribute a copyrighted work under certain terms. Hamlib source code is copyrighted by its authors and is licensed by them under two common licenses—the GNU Lesser General Public License LGPL for the “front end” and “back end” library source code files, and the GNU General Public License GPL for the supplied programs source code files. The full text of the LGPL and the GPL can be found in the files COPYING.LIB and COPYING in the root directory of the Hamlib source archive.
This manual is covered by the GNU Free Documentation License GFDL with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. Source code examples in this manual are parallel licensed under the GPL unless otherwise noted.
As part of the Copyleft nature of the licenses, the authors of Hamlib must forbid you from distributing Hamlib under terms that forbid others from exercising the same rights you received. You must give anyone you distribute Hamlib to the same rights to obtain, modify, and distribute the Hamlib source code that you received nor may you license Hamlib under other terms than those you received. Any recipients of Hamlib must be informed of the rights to the source code that they have received.
Finally, the authors of Hamlib require that it be understood that NO WARRANTY of any kind is offered to anyone receiving the Hamlib source code distribution. Anyone distributing modified versions of Hamlib has the responsibility to inform any recipients that what they have is not the official release of Hamlib by its authors and should be prepared to support the modified version(s). This is to preserve the reputations of the Hamlib authors and the Hamlib Project. While it is not a requirement of the licenses, it is courteous to offer modifications back to the Hamlib authors for possible incorporation into their official release(s).
The Ham Radio Control Libraries, Hamlib for short, is a development effort to provide a consistent interface for programmers wanting to incorporate radio and rotator control in their programs.
Hamlib is not a complete user application, rather, it is a software layer intended to make controlling various radios and other amateur radio station (shack) hardware much easier. Hamlib will allow authors of software such as logging programs, digital communications programs, or those wanting to develop the ultimate radio control software to concentrate on the user interface and the basic function of the program rather than radio control. Hamlib consists of several parts, the programming library, utility programs, and library interfaces to other programming languages.
Most recent amateur radio transceivers allow external control of their functions through a serial interface. Unfortunately, control commands are not always consistent across a manufacturer’s product line and each manufacturer’s product line differs greatly from its competitors.
Hamlib attempts to solve this problem by presenting a "virtual radio" to the programmer by providing an interface to actions such as setting a given Variable Frequency Oscillator’s (VFO) frequency, setting the operating mode, querying the radio of its current status and settings, and giving the application a list of a given radio’s capabilities. Unfortunately, what can be accomplished by Hamlib is limited by the radios themselves and some offer very limited capability.
Other devices, such as antenna rotators, can be placed into the Hamlib control scheme. Other recent developments include network interface servers and a USB interface capability. Language bindings are provided for C, C++, Perl, Python, Lua and TCL (more to come).
Hamlib is a front end library providing a C language Application Programming Interface API to programmers wishing to integrate radio or rotator control in their applications. Hamlib presents a virtual radio or virtual rotator that is a consistent interface to an application despite wide differences in radio and rotator interfaces and capabilities.
The front end library uses a number of back end libraries to translate from the front end to the various individual radio and rotator models. A back end library handles conversion of the front end variables to the format needed by the radio or rotator device it controls. The back end libraries are generally grouped by manufacturer and in some cases by a common control protocol.
Since a picture is worth quite a few words, here is a visual representation of Hamlib’s design.
Hamlib also provides an interface library for each of several common scripting languages such as Perl, Python, Lua and TCL. These language bindings are generated through the use of SWIG a parser/generator for multiple language interfaces to a C library. A native generated C++ language interface is also provided.
Besides the C and supplemental APIs, Hamlib also provides a pair of network daemons that provide a text command based API for controlling an attached radio or rotator through a TCP/IP network connection. The daemons then handle the interface to the Hamlib C API.
More than one type of device, radio or rotator, may be controlled at a time, however, there is generally a limit of one device per serial port or other port.
The Hamlib Project was founded by Frank Singleton,VK3FCS/KM5WS in July 2000. Shortly after Stephane Fillod, F8CFE, joined Frank on the Hamlib project and the API and implementation development led to a reasonable level of maturity in a few years. A major milestone was reached when Hamlib 1.2.0 was released in March 2004. The API and Application Binary Interface (ABI) interfaces have remained stable since that time up to the latest release of 3.2 in early 2018.
Development continues through the major version number 3.x and beyond. While some API tweaks are planned, ABI compatibility with the prior 1.2.x releases remains a priority. Other goals include streamlining the build system (done), improving the SWIG generated language bindings (done), improving the overall documentation (this manual, in progress), and other updates as warranted.
The Project is hosted by SourceForge.net at the Hamlib project page. As GitHub has become a very popular project hosting site, Hamlib also has a dedicated GitHub project page. GitHub also hosts the hamlib.org Web site and the Hamlib Wiki.
Development discussion and most user support take place on the hamlib-developer mailing list. While there are SourceForge.net discussion forums, they are rarely used and not as closely read by the developers as the mailing list.
For source code management, the project uses Git, a fast, distributed content tracker. Among its features is that every developer has the complete Hamlib development history available locally. For more information on using Git, see Working with Git.
Note: While a canonical Git repository is hosted as SourceForge, its availability is not essential to continued development, although development work flows would change temporarily. Several developers find the GitHub Web interface easier to use and lately development has centered around GitHub rather than SourceForge.
A number of application developers have taken advantage of Hamlib’s capabilities to implement radio and/or rotator control. While not exhaustive, a list is maintained at the Hamlib Wiki, Applications/Screenshots. Developers are encouraged to request their applications be added to the gallery by way of the hamlib-developer mailing list.
As with other Free Software projects, Hamlib relies heavily on copyleft licensing to encourage development contributions and provide an open atmosphere for development. Hamlib’s source code is released under two licenses, the Lesser General Public License (LGPL) for the library portion, and the General Public License (GPL) for the utility programs.
The LGPL allows the library to be used (linked) by programs regardless of their individual license. However, any contributions to the library source remain under copyleft which means that the library source code may not be used in violation of the terms of the LGPL.
The utility program source files are released under the GPL. Any direct use of these sources must be in a form that complies with the terms of the GPL. Concepts learned by studying these sources for the purpose of understanding the Hamlib API is not covered nor prohibited by the GPL, however, directly copying GPL sources into any work that is incompatible with the terms of the GPL is prohibited.
See Copying and Redistribution.
Hamlib’s focus is on controlling rigs that employ a port and command protocol for setting frequency, mode, VFO, PTT, etc. Most VHF/UHF transceivers do not employ such control capability but do provide for cloning the memory contents from radio to another of the same model. A related project, CHIRP, aims to support radios with such a clone capability. Please contact the CHIRP project for support of such radios.
English speakers seem to have two alternate pronunciations for our project:
Then again, we have people who say Linux "L-eye-nux" and those who say "L-in-nux"...
If you’re French, the above does not apply! :-)
There are several ways to obtain a working installation of Hamlib. The following sections discuss installing from a package manager, building from source, and installing Hamlib project supplied binaries on Microsoft Windows®.
The easiest way to install a released version of Hamlib on a Linux based distribution or a BSD variant is through the provided package manager. While package managers vary according to the distribution (it’s easy to lump BSD variants in this group too) their end goal is to provide ready to use software packages. Since such a wide variety of package managers exist, it is best to recommend that the documentation for your chosen distribution be your guide.
Distribution packages are most often official Hamlib releases and in some cases could be quite old and lacking support for newer radios or rotators. In some cases support is improved in existing radio or rotator back ends and bugs are fixed in newer releases. Often times to get the improved support/bug fixes, building from source will be required. Relax, it’s not hard. :-)
Source code is available as official releases, testing snapshots, daily development snapshots, and the bleeding edge of development directly from the Git repository. As a rule, even the bleeding edge tarballs should configure and compile without error even though certain implementation work may be in progress and may be incomplete or have errors.
Official Hamlib source releases, commonly called tarballs can be found on the SourceForge.net Hamlib files Web page. As a convenience, release archives are also mirrored at the GitHub Hamlib releases page. The most recent release is listed first.
Testing release candidates (RCs) are posted during the period (often a few weeks) before a planned release. Beginning with the 3.2 release, RCs are hosted by the GitHub release archive. RCs are identifed by having a ~rc suffix.
Daily snapshots of the development repository are available via the World Wide Web from Hamlib Git daily snapshots. These are not official releases but are provided for testing new features and bug fixes.
The daily development snapshot is made and posted each day by around 1030 UTC. Daily snapshots should compile but sometimes a bug creeps in that prevents compilation. If that should happen, please report it to the hamlib-developer mailing list.
The source repository can be cloned which copies the repository
to your computer including its entire history, branches, and release
tag information. In other words, once the git
clone command is finished a complete copy of the Hamlib
development will be on your computer. You can do quite a lot with
this as nothing is hidden from view since the entire
history of Hamlib is right there all the way from the very first
commit to the present. None of the meta-data is hidden away on
some central server.
To clone the repository use the following command:
git clone git://git.code.sf.net/p/hamlib/code hamlib
or:
git clone https://github.com/Hamlib/Hamlib.git
Odds are that you will want to run the above command in a sub directory of your home directory. The hamlib directory will be created by Git and the master branch will be checked out for you as the working copy. The master branch is one of several branches used in Hamlib development. It is the main branch of new features and bug fixes. The working copy will be the latest revision of every file at the time of the clone. Later updates from the developers will require using another Git command to update your local repository.
See Working with Git.
Building from source will be required for various reasons. Perhaps only an older release is provided by your distribution, or you would like to test recent changes to Hamlib—either a specific back end or API changes—and offer a report to the developers, or you’d like to take part in development and offer your contribution to the project, or you’d just like to learn how to build a relatively comprehensive package from source. Any is a good reason to build from the source code archive.
Before going further, this manual assumes familiarity with working
from the command prompt in a Linux/BSD/Unix like system’s shell
environment, either in a virtual console (a text only screen
with no graphics) or in a terminal in a desktop environment
(xterm
, rxvt
, konsole
,
gnome-terminal
, xfce4-terminal
,
terminal
, etc.). If this is new to you, take some time and
read up on using the shell. A good tutorial can be found at
LinuxCommand.org which also offers an
in-depth book that can be purchased or downloaded for no cost (the
Hamlib project is not associated with nor has any interest in the sale
of this book, it just looks like a very good effort on the part of its
author).
Let’s get started.
Before proceeding, it is essential to read the information in the files, README, INSTALL, and README.betatester supplied in the Hamlib top-level directory which will be named something like hamlib-3.3~git where the latter part is the release version. In this case the ‘3.3~git’ indicates this is a development snapshot of the Git master branch. These files provide detailed information for compiling Hamlib and will vary some from release to release.
Compiling from a source tarball whether it is an official release or a testing or daily development snapshot follows the same set of commands, known as the three step which are each run from the top-level directory:
./configure make sudo make install
configure
The ./configure
command examines your system and checks it
for any packages that are required or good to have options for
compiling Hamlib. The leading ./ tells the shell to only run
the configure
command found in the current directory. It is
always possible that a configure
command could be lurking
elsewhere and we don’t want to run that!
Run:
./configure
from the top-level directory.
Note: Some distributions are configured so commands can only be run from directories listed in the
PATH
environment variable. The ./ is necessary or theconfigure
command will not be run as the current directory (defined as .) is not in thePATH
. This is considered a default security feature so that only programs provided by the distribution are run.PATH
can be modified for your own session, but that is a topic for the LinuxCommand.org reference above.
Of course, things are usually complicated a bit by options and Hamlib is no exception. The good news is that the defaults, i.e., no options, work well in most situations. Options are needed to enable the compilation of certain portions of Hamlib such as the language bindings. Optional features usually require that more development tools are installed. The INSTALL, and README.betatester files in the Hamlib top-level directory will have details on the options available for that release.
A useful option is ‘--prefix’ which tells configure
where in the file system hierarchy Hamlib should be installed. If it
is not given, Hamlib will be installed in the /usr/local file
system hierarchy. Perhaps you want to install to your home directory
instead:
./configure --prefix=$HOME/local
Note: For practice you may wish to start out using the ‘--prefix=$HOME/local’ option to install the Hamlib files into your home directory and avoid overwriting any version of Hamlib installed into the system directories. The code examples in the remainder of this manual will assume Hamlib has been installed to ‘$HOME/local’.
All of the files will be installed in the local directory of
your home directory. local will be created if it does not
exist during installation as will several other directories in it.
Installing in your home directory means that root, or superuser
(administrator) privileges are not required when running make
install
. On the other hand, some extra work will need to be done so
other programs can use the library.
Another useful option is ‘--help’ which will give a few screens
full of options for configure
. If in a desktop environment
the scroll bar can be used to scroll back up through the output. In
either a terminal or a virtual console Linux supports the
Shift-PageUp key combination to scroll back up. Converesely
Shift-PageDown can be used to scroll down toward the end of the
output and the shell prompt (Shift-UpArrow/Shift-DownArrow may also
work to scroll one line at a time).
After a fair amount of time, depending on your computer, and a lot of
screen output, configure
will finish its job. So long as
the few lines previous to the shell prompt don’t say “error” or some
such failure message Hamlib is ready to be compiled. If there is an
error and all of the required packages listed in
README.betatester have been installed, please ask for help on
the hamlib-developer
mailing list.
make
The make
command is responsible for running the
compiler which reads the source files and from the instructions
it finds in them writes object files which are the binary
instructions the CPU of a computer can execute.
make
then calls the linker which puts the object files
together in the correct order to create the Hamlib library files and
its executable programs.
Run:
make
from the top-level directory.
Any error that causes make
to stop early is cause for a
question to the hamlib-developer mailing list.
In general make
will take longer than configure
to
complete its run. As it is a system command and therefore found in
the PATH
, prefixing make
with ./ will cause a
‘command not found’ error from the shell.
make install
Assuming that you have not set the installation prefix to your home
directory, root (administrator) privileges will be required to install
Hamlib to the system directories. Two popular methods exist for
gaining root privileges, su
and sudo
.
sudo
is probably the most popular these days, particularly
when using the Ubuntu family of
distributions.
Run:
sudo make install
as root from the top-level directory.
Running make install
will call the installer to put all of
the newly compiled files and other files (such as this document) in
predetermined places set by the ‘--prefix’ option to
configure
in the directory hierarchy (yes, this is by design
and make
is not just flinging files any old place!).
A lot of screen output will be generated. Any errors will probably be rather early in the process and will likely be related to your username not having write permissions in the system directory structure.
ldconfig
Once the installation is complete one more step is required if Hamlib
has never been installed from a local build before. The
ldconfig
command tells the system library loader where to
find the newly installed Hamlib libraries. It too will need to be run
with root privileges:
Run:
sudo ldconfig
as root from any directory.
Note: Subsequent installations of Hamlib will not need to have
ldconfig
run after each installation if a newer major version of Hamlib was not installed, i.e. when recompiling the same version during development.
On some distributions a bit of configuration will be needed before
ldconfig
will add locally compiled software to its database.
Please consult your distribution’s documentation.
git clone
Choosing to build from from a git clone
requires a few more
development tools (notice a theme here?) as detailed in
README.developer. The most critical will be the GNU Autotools
(autoconf
, automake
, libtool
, and more)
from which the build system consisting of configure, the
various Makefile.ins throughout the directory structure, and
the final Makefiles are generated.
In the top-level directory is the bootstrap
script from
which the build system is bootsrapped—the process of
generating the Hamlib build system from configure.ac and the
various Makefile.ams. At its completion the
configure
script will be present to configure the build
system.
Next configure
is run with any needed build options
(configure --help
is useful) to enable certain features or
provide paths for locating needed build dependencies, etc.
Environment variables intended for the preprocessor and/or compiler
may also be set on the configure
command line.
After the configuration is complete, the build may proceed with the
make
step as for the source tarballs above. Or
configure --help
may be run, and configure
run
again with specific options in which case the Makefiles will be
regenerated and the build can proceed with the new configuration.
See configure.
make
targetsBesides make install
, other targets exist when running
make
. Running make clean
from the top-level
directory removes all of the generated object and executable files
generated by running make
freeing up considerable disk
space.
Note: During development of individual source files, it is not necessary to run
make clean
each time beforemake
. Simply runmake
and only the modified file(s) and any objects that depend on them will be recompiled. This speeds up development time considerably.
To remove even the generated Makefiles, run make
distclean
from the top-level directory. After this target is run,
configure
will need to be run again to regenerate the
Makefiles. This command may not be as useful as the
Makefiles do not take up much space, however it can be useful
for rebuilding the Makefiles when modifying a
Makefile.am or confgure.ac during build system
development.
One feature of the GNU build system used by Hamlib is that the object
files can be kept in a directory structure separate from the source
files. While this has no effect on the make
targets
described above, it does help the developer find files in the source
tree! One such way of using parallel builds is described in
README.developer.
Parallel builds can be very useful as one build directory can be
configured for a release and another build directory can be configured
for debugging with different options passed to configure
from each directory. The generated Makefiles are unique to
each build directory and will not interfere with each other.
When additional debugging symbols are needed with, for example, the
GNU Debugger, gdb
, the needed compiler and linker options
are passed as environment variables.
Run:
../hamlib/configure CFLAGS="-ggdb3 -O0" CXXFLAGS="-ggdb3 -O0"
from a sibling build directory intended for a debugging build.
The ‘-ggdb3’ option tells the C compiler, this case the GNU C
Compiler, gcc
, to add special symbols useful for GDB, the
GNU debugger. The ‘-O0’ option tells gcc
to turn off
all optimizations which will make it easier to follow some variables
that might otherwise be optimized away. ‘CFLAGS’ and
‘CXXFLAGS’ may be set independently for each compiler.
Note: There are a number compiler options available for controlling debugging symbols and setting optimization levels. Please consult the compiler’s manual for all the details.
Currently compiling is done on a Debian 8 (Jessie) virtual machine using MinGW. README.build-win32 in the scripts directory has details on how this is accomplished.
Work is ongoing to correct build issues in the Cygwin environment running on MS Windows.
Pre-compiled binaries for Microsoft Windows 32 and 64 bit architectures (Windows NT and newer) are available for both official releases and daily development snapshots. Official releases are available through the SourceForge.net file download service. As an alternative, official releases are also available though the Hamlib archive at GitHub. Daily development snapshots are available from http://n0nb.users.sourceforge.net/.
Beginning with the Hamlib 1.2.15.3 release a self-extracting installer
is available. Among its features are selecting which portions of
Hamlib are installed. The PATH
environment variable will need
to be set manually per the included README.w32-bin or
README.w64-bin file.
Daily development snapshots feature both a .ZIP archive and the self extracting installer.
Bug reports and questions about these archives should be sent to the hamlib-developer mailing list.
Included with the Hamlib distribution are several utility programs. Besides providing a way for developers to test new code and bug fixes, the programs also offer a reference implementation for interfacing to the Hamlib library functions both through the C API (Application Programming Interface) and offering a network accessible API.
This chapter focuses on the two test programs, rigctl
for
testing radio back ends and rotctl
for testing rotator back
ends and the two network daemons, rigctld
and
rotcltd
for radio and rotator access via network sockets.
Also included are three demonstation utilities, rigmem
,
rigsmtr
, and rigswr
which provide functional
examples of how Hamlib may be used to accomplish various tasks.
rigctl
rigctl
is the most frequently used Hamlib utility. As the
other ctl utilities share many of the same characteristics, much of
the introductory information presented in this section is applicable
to the other utility programs.
rigctl
Most likely the first of the Hamlib utility programs that is used is
rigctl
. rigctl
is a character based interactive
program and a command line program able to set or query a radio’s
value with a single command. rigctl
is invoked from a shell
command prompt with various options and additional commands.
In its most simple use as a command line program,
rigctl
is used to set frequency and mode by typing commands
after any rigctl
options:
rigctl F 14205000 rigctl M USB 2400
and then query those values:
rigctl f rigctl m
Entering interactive mode is a simple matter of not placing any
commands after any rigctl
options:
rigctl
Entering interactive mode allows successive commands to be
entered without exiting rigctl
. Recent additions to
rigctl
allow command editing and history recall through use
of the Readline library.
Interactive mode is indicated by the spartan prompt:
Rig command:
Commands are given at the prompt and follow the general rule that upper case letters set a value and lower case letters query a value:
Rig command: M Mode: USB Passband: 2500 Rig command: m Mode: USB Passband: 2500 Rig command:
An additional prompt is printed when more information is required by
the command. For M above, rigctl
prompted for the
“Mode” and “Passband” values. For m above, rigctl
returned the “Mode” and “Passband” values without further prompts.
The command prompt is returned after each command invocation.
The above examples invoked rigctl
without specifying a radio
model. This is a feature where the Hamlib internal radio dummy is
used instead. The dummy radio provides a way to test Hamlib functions
with out the need for actual radio hardware. However, to develop back
end capability for a given radio, having the actual radio connected to
the computer is necessary for debugging.
For example, to quickly set frequency on an Elecraft K3:
rigctl -m 229 -r /dev/rig F 3900000
and to query the frequency and then mode:
rigctl -m 229 -r /dev/rig f 3900000 rigctl -m 229 -r /dev/rig m LSB 2000
The returned values do not have the prompt strings associated with interactive mode as shown above.
The -m option takes a numeric value that corresponds to a given radio back end model. The -r option takes the path to the port device on POSIX and the device name on Microsoft Windows.
Note: A complete list of supported radio models may be seen by use of the -l option:
rigctl -l Rig # Mfg Model Version Status 1 Hamlib Dummy 0.5 Beta 2 Hamlib NET rigctl 0.3 Beta 101 Yaesu FT-847 0.5 Beta 103 Yaesu FT-1000D 0.0.6 Alpha . . . 2702 Rohde&Schwarz EB200 0.1 Untested 2801 Philips/Simoco PRM8060 0.1 Alpha 2901 ADAT www.adat.ch ADT-200A 1.36 BetaThe list is long so use SHIFT-PageUp/ SHIFT-PageDown on Linux, ScrollLock then PageUp/PageDown on Free BSD, or use the scrollbar to the virtual terminal window (
cmd
window on Microsoft Windows) or the output can be piped to ’more
’ or ’less
’, e.g. ’rigctl -l | more’ to scroll back up the list. The list is sorted numerically by model number since Hamlib 1.2.15.1. Model numbers of a manufacturer/protocol family are grouped together.
rigctl
referenceThe complete reference for rigctl
can be found in the
rigctl(1) Unix manual page.
rotctl
Identical in function to rigctl
, rotctl
provides a
means for testing Hamlib functions useful for rotator control and
QTH (Maidenhead gridsquare system, see
Maidenhead Locator System) locator computations. As rotators have a
much narrower scope than radios, there are fewer command line options
and commands for rotctl
.
rotctl
rotctl
is a character based interactive program and a
command line program able to set or query a rotator’s value with a
single command. rotctl
is invoked from a shell command
prompt with various options and additional commands.
In its most simple use as a command line program, rotctl
is
used to set frequency and mode by typing commands after any
rotctl
options:
rotctl P 145.0 23.0 rotctl M 8 25
and then query those values:
rotctl p
Entering interactive mode is a simple matter of not placing any
commands after any rotctl
options:
rotctl
Entering interactive mode allows successive commands to be entered
without exiting rotctl
. Interactive mode allows for command
editing and history recall through the use of the Readline
library.
Interactive mode is indicated by the spartan prompt:
Rotator command:
Commands are given at the prompt:
Rotator command: M Direction: 16 Speed: 60 Rotator command: p Azimuth: 11.352000 Elevation: 0.000000 Rotator command: p Azimuth: 27.594000 Elevation: 0.000000 Rotator command:
An additional prompt is printed when more information is required by
the command. For M above, rotctl
prompted for the
“Direction” and “Speed” values. For p above,
rotctl
returned the “Azimuth” and “Elevation” values
without further prompts. The command prompt is returned after each
command invocation.
The above examples invoked rotctl
without specifying a
rotator model. This is a feature where the Hamlib internal rotator
dummy is used instead. The dummy rotator provides a way to test
Hamlib functions with out the need for actual rotator hardware.
However, to develop back end capability for a given rotator, having
the actual controller connected to the computer is necessary for
debugging.
For example, to quickly set position for RotorEZ:
rotctl -m 401 -r /dev/rotor P 100.0 0.0
and to query the position:
rotctl -m 401 -r /dev/rotor p 100.000000 0.000000
The returned values do not have the prompt strings associated with interactive mode as shown above.
The -m option takes a numeric value that corresponds to a given rotator back end model. The -r option takes the path to the port device on POSIX or the device name on MS Windows.
Note: A complete list of supported radio models may be seen by use of the -l option:
rotctl -l Rot # Mfg Model Version Status 1 Hamlib Dummy 0.5 Beta 2 Hamlib NET rotctl 0.3 Beta 201 Hamlib EasycommI 0.3 Beta 202 Hamlib EasycommII 0.3 Beta . . . 1201 AMSAT IF-100 0.1 Untested 1301 LA7LKA ts7400 0.1 Beta 1401 Celestron NexStar 0.1 UntestedThe list is long so use SHIFT-PageUp/ SHIFT-PageDown on Linux, ScrollLock then PageUp/PageDown on Free BSD, or use the scrollbar to the virtual terminal window (
cmd
window on MS Windows) or the output can be piped to ’more
’ or ’less
’, e.g. ’rotctl -l | more’ to scroll back up the list. The list is sorted numerically by model number since Hamlib 1.2.15.1. Model numbers of a manufacturer/protocol family are grouped together.
rotctl
referenceThe complete reference for rotctl
can be found in the
rotctl(1) Unix manual page.
rigctld
The rigctld
program is a network server that accepts the
familiar commands of rigctl
and provides the response data
over a TCP/IP network socket to an application. In this
manner an application can access a rigctld
instance from
nearly anywhere (caveat, no security is currently provided by
rigctld
). Applications using rigctld
do not link
directly to Hamlib nor use its C API.
rigctld
rigctld
communicates to a client through a TCP
network socket using text commands shared with rigctl
. The
protocol is simple; commands are sent to rigctld
on one line
and rigctld
responds to “get” commands with the requested
values, one per line, when successful, otherwise, it responds with one
line ‘RPRT x’, where ‘x’ is a negative number indicating the
Hamlib error code. Commands that do not return values respond with
the line ‘RPRT x’, where ‘x’ is zero when successful,
otherwise a negative number indicating the Hamlib error code. Each
line is terminated with a newline \n
character. This protocol
is primarily for use by the NET rigctl
(radio model 2) backend.
A separate Extended Response protocol extends the above behavior by
echoing the received command string as a header, any returned values
as a key: value pair, and the ‘RPRT x’ string as the end of
response marker which includes the Hamlib success or failure value.
Consider using this protocol for clients that will interact with
rigctld
directly through a TCP network socket.
Multiple radios can be controlled on different TCP ports by
use of multiple rigctld
processes each listening on a unique
TCP port. It is hoped that rigctld
will be
especially useful for client authors using languages such as
Perl, Python, PHP,
Ruby, TCL, and others.
rigctld
referenceThe complete reference for rigctld
can be found in the
rigctld(1) Unix manual page.
rotctld
The rotctld
program is a network server that accepts the
familiar commands of rotctl
and provides the response data
over a TCP/IP network socket to an application. In this
manner an application can access a rotctld
instance from
nearly anywhere (caveat, no security is currently provided by
rotctld
). Applications using rotctld
do not link
directly to Hamlib nor use its C API.
rotctld
rotctld
communicates to a client through a TCP
network socket using text commands shared with rotctl
. The
protocol is simple, commands are sent to rotctld
on one line
and rotctld
responds to “get” commands with the requested
values, one per line, when successful, otherwise, it responds with one
line ‘RPRT x’, where ‘x’ is a negative number indicating the
Hamlib error code. Commands that do not return values respond with
the line ‘RPRT x’, where ‘x’ is zero when successful,
otherwise a negative number indicating the Hamlib error code. Each
line is terminated with a newline \n
character. This protocol
is primarily for use by the NET rotctl
(rot model 2) backend.
A separate Extended Response protocol extends the above behavior by
echoing the received command string as a header, any returned values
as a key: value pair, and the ‘RPRT x’ string as the end of
response marker which includes the Hamlib success or failure value.
Consider using this protocol for clients that will interact with
rotctld
directly through a TCP network socket.
Multiple rotators can be controlled on different TCP ports by
use of multiple rotctld
processes each listening on a unique
TCP port. It is hoped that rotctld
will be
especially useful for client authors using languages such as
Perl, Python, PHP,
Ruby, TCL, and others.
rotctld
referenceThe complete reference for rotctld
can be found in the
rotctld(1) Unix manual page.
rigmem
rigmem
may be used to backup and restore memory of radio
transceivers and receivers.
rigmem
Backup and restore memory of radio transceivers and receivers.
rigmem
accepts ‘command’s from the command line only.
rigmem
referenceThe complete reference for rigmem
can be found in the
rigmem(1) Unix manual page.
rigsmtr
rigsmtr
uses Hamlib to control a radio to measure S-Meter
value versus antenna azimuth.
rigsmtr
rigsmtr
rotates the antenna from minimum azimuth to maximum
azimuth. Every second, or time_step if specified in seconds, it
retrieves the signal strength. Azimuth in degrees and the
corresponding S-Meter level in dB relative to S9 are then printed on
stdout.
To work correctly, rigsmtr
needs a radio that could measure
S-Meter and a Hamlib backend that is able to retrieve it, connected to
a Hamlib supported rotator.
rigsmtr
referenceThe complete reference for rigsmtr
can be found in the
rigsmtr(1) Unix manual page.
rigswr
rigswr
may be used to measure VSWR vs frequency.
rigswr
rigswr
uses Hamlib to control a radio to measure
VSWR (Voltage Standing Wave Ratio) over a frequency range.
It scans frequencies from start_freq to stop_freq with an
optional increment of freq_step (default step is 100 kHz). All
values must be entered as an integer in Hertz (cycles per second).
Note:
rigswr
assumes that start_freq is less than or equal to stop_freq. If it is greater,rigswr
will exit without doing anything.
For each frequency, rigswr
transmits at 25% of total POWER
during 0.5 second in CW mode and reads VSWR.
Frequency and the corresponding VSWR are then printed on stdout.
To work correctly, rigswr
needs a radio that can measure
VSWR and a Hamlib backend that supports reading
VSWR from the radio.
rigswr
referenceThe complete reference for rigswr
can be found in the
rigswr(1) Unix manual page.
Copyright © 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc. http://fsf.org/ Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.
The purpose of this License is to make a manual, textbook, or other functional and useful document free in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others.
This License is a kind of “copyleft”, which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software.
We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference.
This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that work under the conditions stated herein. The “Document”, below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as “you”. You accept the license if you copy, modify or distribute the work in a way requiring permission under copyright law.
A “Modified Version” of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language.
A “Secondary Section” is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document’s overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.
The “Invariant Sections” are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License. If a section does not fit the above definition of Secondary then it is not allowed to be designated as Invariant. The Document may contain zero Invariant Sections. If the Document does not identify any Invariant Sections then there are none.
The “Cover Texts” are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at most 25 words.
A “Transparent” copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup, or absence of markup, has been arranged to thwart or discourage subsequent modification by readers is not Transparent. An image format is not Transparent if used for any substantial amount of text. A copy that is not “Transparent” is called “Opaque”.
Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modification. Examples of transparent image formats include PNG, XCF and JPG. Opaque formats include proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML, PostScript or PDF produced by some word processors for output purposes only.
The “Title Page” means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, “Title Page” means the text near the most prominent appearance of the work’s title, preceding the beginning of the body of the text.
The “publisher” means any person or entity that distributes copies of the Document to the public.
A section “Entitled XYZ” means a named subunit of the Document whose title either is precisely XYZ or contains XYZ in parentheses following text that translates XYZ in another language. (Here XYZ stands for a specific section name mentioned below, such as “Acknowledgements”, “Dedications”, “Endorsements”, or “History”.) To “Preserve the Title” of such a section when you modify the Document means that it remains a section “Entitled XYZ” according to this definition.
The Document may include Warranty Disclaimers next to the notice which states that this License applies to the Document. These Warranty Disclaimers are considered to be included by reference in this License, but only as regards disclaiming warranties: any other implication that these Warranty Disclaimers may have is void and has no effect on the meaning of this License.
You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3.
You may also lend copies, under the same conditions stated above, and you may publicly display copies.
If you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering more than 100, and the Document’s license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects.
If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages.
If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a computer-network location from which the general network-using public has access to download using public-standard network protocols a complete Transparent copy of the Document, free of added material. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public.
It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document.
You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version:
If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version’s license notice. These titles must be distinct from any other section titles.
You may add a section Entitled “Endorsements”, provided it contains nothing but endorsements of your Modified Version by various parties—for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard.
You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one.
The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version.
You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice, and that you preserve all their Warranty Disclaimers.
The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work.
In the combination, you must combine any sections Entitled “History” in the various original documents, forming one section Entitled “History”; likewise combine any sections Entitled “Acknowledgements”, and any sections Entitled “Dedications”. You must delete all sections Entitled “Endorsements.”
You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects.
You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.
A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, is called an “aggregate” if the copyright resulting from the compilation is not used to limit the legal rights of the compilation’s users beyond what the individual works permit. When the Document is included in an aggregate, this License does not apply to the other works in the aggregate which are not themselves derivative works of the Document.
If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one half of the entire aggregate, the Document’s Cover Texts may be placed on covers that bracket the Document within the aggregate, or the electronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole aggregate.
Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License, and all the license notices in the Document, and any Warranty Disclaimers, provided that you also include the original English version of this License and the original versions of those notices and disclaimers. In case of a disagreement between the translation and the original version of this License or a notice or disclaimer, the original version will prevail.
If a section in the Document is Entitled “Acknowledgements”, “Dedications”, or “History”, the requirement (section 4) to Preserve its Title (section 1) will typically require changing the actual title.
You may not copy, modify, sublicense, or distribute the Document except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense, or distribute it is void, and will automatically terminate your rights under this License.
However, if you cease all violation of this License, then your license from a particular copyright holder is reinstated (a) provisionally, unless and until the copyright holder explicitly and finally terminates your license, and (b) permanently, if the copyright holder fails to notify you of the violation by some reasonable means prior to 60 days after the cessation.
Moreover, your license from a particular copyright holder is reinstated permanently if the copyright holder notifies you of the violation by some reasonable means, this is the first time you have received notice of violation of this License (for any work) from that copyright holder, and you cure the violation prior to 30 days after your receipt of the notice.
Termination of your rights under this section does not terminate the licenses of parties who have received copies or rights from you under this License. If your rights have been terminated and not permanently reinstated, receipt of a copy of some or all of the same material does not give you any rights to use it.
The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft/.
Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License “or any later version” applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation. If the Document specifies that a proxy can decide which future versions of this License can be used, that proxy’s public statement of acceptance of a version permanently authorizes you to choose that version for the Document.
“Massive Multiauthor Collaboration Site” (or “MMC Site”) means any World Wide Web server that publishes copyrightable works and also provides prominent facilities for anybody to edit those works. A public wiki that anybody can edit is an example of such a server. A “Massive Multiauthor Collaboration” (or “MMC”) contained in the site means any set of copyrightable works thus published on the MMC site.
“CC-BY-SA” means the Creative Commons Attribution-Share Alike 3.0 license published by Creative Commons Corporation, a not-for-profit corporation with a principal place of business in San Francisco, California, as well as future copyleft versions of that license published by that same organization.
“Incorporate” means to publish or republish a Document, in whole or in part, as part of another Document.
An MMC is “eligible for relicensing” if it is licensed under this License, and if all works that were first published under this License somewhere other than this MMC, and subsequently incorporated in whole or in part into the MMC, (1) had no cover texts or invariant sections, and (2) were thus incorporated prior to November 1, 2008.
The operator of an MMC Site may republish an MMC contained in the site under CC-BY-SA on the same site at any time before August 1, 2009, provided the MMC is eligible for relicensing.
To use this License in a document you have written, include a copy of the License in the document and put the following copyright and license notices just after the title page:
Copyright (C) year your name. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled ``GNU Free Documentation License''.
If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, replace the “with…Texts.” line with this:
with the Invariant Sections being list their titles, with the Front-Cover Texts being list, and with the Back-Cover Texts being list.
If you have Invariant Sections without Cover Texts, or some other combination of the three, merge those two alternatives to suit the situation.
If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU General Public License, to permit their use in free software.
Git offers a myriad of commands and options. Fortunately, only a few are needed for Hamlib development.
Hamlib design
Jump to: | A B C D F G H I L M N O P R S V |
---|
Jump to: | A B C D F G H I L M N O P R S V |
---|