This manual is for the Ham Radio Control Libraries (version 3.0.1
updated 6 January 2016), which is a development effort to provide a
consistent programming interface for programmers wanting to incorporate
radio and rotor control into their programs.

   Copyright © 2013 Nate Bargmann

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

Ham Radio Control Libraries
***************************

This manual is for Ham Radio Control Libraries (Hamlib) (version 3.0.1,
6 January 2016).

Copying and Redistribution
**************************

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

1 Hamlib in a Nutshell
**********************

The "Ham Radio Control Libraries", "Hamlib" for short, is a development
effort to provide a consistent interface for programmers wanting to
incorporate radio 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 shack
hardware much easier.  Hamlib will allow authors of such software 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 VFO’s 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 rotors, 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, and TCL (more to come).

1.1 A view from the top of the tower
====================================

Hamlib is a "front end" library providing a _C_ language Application
Programming Interface API to programmers wishing to integrate radio or
rotor control in their applications.  Hamlib presents a "virtual radio"
or "virtual rotor" that is a consistent interface to an application
despite wide differences in radio and rotor 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 rotor
models.  A back end library handles conversion of the front end
variables to the format needed by the radio or rotor 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.

     Figure 1.1: Hamlib design—courtesy of Martin Ewing, AA6E.

   Hamlib also provides an interface library for each of several common
"scripting" languages such as Perl, Python, 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 rotor 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 rotor, may be controlled at a
time, however, there is generally a limit of one device per serial port
or other port.

1.2 Hamlib project information
==============================

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 1.2.15.3 in late 2012.

   Development continues with a bump of the public version number to 3.0
(essentially simply dropping the “1.” of previous releases).  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 (in progress),
improving the overall documentation (this manual, in progress), and
other updates as warranted.

   The Project is hosted by SourceForge.net (https://sourceforge.net/)
at the Hamlib project page (https://sourceforge.net/projects/hamlib/)
and the Hamlib Wiki
(http://sourceforge.net/apps/mediawiki/hamlib/index.php).

   Development discussion and most user support take place on the
hamlib-developer mailing list
(https://sourceforge.net/p/hamlib/mailman/).  While there are
SourceForge.net discussion forums
(https://sourceforge.net/p/hamlib/discussion/), they are rarely used and
not as closely read by the developers as the mailing list.

   For "source code management", the project uses Git
(http://git-scm.com/), a fast, distributed content tracker.  Among its
features is that every developer has the complete Hamlib development
history available locally.  While a canonical Git repository is hosted
as SourceForge, its availability is not essential to continued
development, although development work flows would change temporarily.
For more information on using Git, see Working with Git.

     Note: The SourceForge.net Web interface to the Hamlib Git
     repository is currently broken (a ticket is pending) as of late
     February, 2013.  A mirror exists at GitHub
     (https://github.com/N0NB/hamlib) which supports browsing via the
     Web and other Git commands.  Access of the SF.net repository by
     other means (SSH or Git protocols) is unaffected by this issue.

1.3 Applications using Hamlib
=============================

A number of application developers have taken advantage of Hamlib’s
capabilities to implement radio and/or rotor control.  While not
exhaustive, a list is maintained at the Hamlib Wiki,
Applications/Screenshots
(https://sourceforge.net/apps/mediawiki/hamlib/).  Developers are
encouraged to request their applications be added to the gallery by way
of the hamlib-developer mailing list.

1.4 Using Hamlib with your program
==================================

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 LGPL for the library portion, and the 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.

1.5 Radios with a clone capability
==================================

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 (http://chirp.danplanet.com/), aims to support
rigs with such a clone capability.  Please contact the CHIRP project for
support of such rigs.

1.6 Pronouncing Hamlib
======================

English speakers seem to have two alternate pronunciations for our
project:

   • Hamlib (Ham - lib, long "i", as in library.)  IPA style: /’ham læb/
   • Hamlib (Ham - lib, short "i", as in liberty.)  IPA style: /’ham
     lɪb/

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

2 Getting started
*****************

There are several ways to obtain a working installation of Hamlib.  In
the following sections discuss installing from a package manager,
building from source, and installing Hamlib project supplied binaries on
Microsoft Windows®.

2.1 Installing binary packages on Linux and BSD
===============================================

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.

2.2 A variety of Hamlib sources
===============================

Distribution packages are most often official Hamlib releases and in
some cases could be quite old and lacking support for newer radios or
rotors.  In some cases support is improved in existing radio or rotor
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 (http://git-scm.com/) 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.

2.2.1 Getting released source
-----------------------------

Official Hamlib source releases, commonly called "tarballs" can be found
on the SourceForge.net Hamlib files
(http://sourceforge.net/projects/hamlib/files/hamlib/) Web page.  The
most recent release is listed first.

2.2.2 Getting source snapshots
------------------------------

Testing release candidates and daily snapshots of the development
repository are available via the World Wide Web from Hamlib Git daily
snapshots (http://n0nb.users.sourceforge.net/).  These are not official
releases but are provided for testing new features and bug fixes.

   Testing release snapshots are only posted for a few weeks before a
planned release.  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
<hamlib-developer@lists.sourceforge.net>.

2.2.3 Git repository
--------------------

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

   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.

2.3 Building from source
========================

Building from source will be required for various reasons.  Perhaps only
an older release is provided by your distribution, or you’d 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.

   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
(http://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.

2.3.1 Compiling source tarballs
-------------------------------

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.0~git’ where the latter part is the release version.  In this
case the ‘3.0~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

2.3.1.1 ‘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’s 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 the ‘configure’ command will not be run as the
     "current directory" (defined as ‘.’) is not in the ‘PATH’.  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=~/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.  (TODO: describe this in an appendix).

   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.  As luck would have it, <Shift-PageDown> can be used
to scroll down toward the end of the output and the shell prompt.

   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
<hamlib-developer@lists.sourceforge.net>.

2.3.1.2 ‘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
<hamlib-developer@lists.sourceforge.net>.

   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.

2.3.1.3 ‘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 (http://www.ubuntu.com)
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.

2.3.1.4 ‘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 so long as no new backend
     libraries nor a newer major version of Hamlib were installed.

     A developer adding a new backend (see ‘README.developer’) will need
     to run ‘ldconfig’ for the new back end library to be found by the
     library loader (this refers a new back end, i.e.  a sibling to the
     existing Icom, Kenwood, Yaesu, etc. back ends, not a new model in
     an existing back end).

     Likewise, any time a new back end appears in a source tarball,
     ‘ldconfig’ will need to be run for the library loader to find it.
     There is no harm running ‘ldconfig’ after each run of ‘make
     install’.

   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.

2.3.2 Bootstrapping from a ‘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.in’s throughout
the directory structure, and the final ‘Makefile’s are generated.

   In the top-level directory is the ‘autogen.sh’ script from which the
build system is "bootsrapped"—the process of building the Hamlib build
system.  At its completion ‘autogen.sh’ will run ‘configure’ and will
pass any command line arguments it receives to ‘configure’.  Environment
variables intended for the compiler may also be set on the ‘autogen.sh’
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 ‘Makefile’s will be regenerated and the build will proceed.

2.3.3 Other ‘make’ targets
--------------------------

Besides ‘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 before ‘make’.  Simply run
     ‘make’ 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 ‘Makefile’s, run ‘make distclean’ from
the top-level directory.  After this target is run, ‘configure’ will
need to be run again to regenerate the ‘Makefile’s.  This command may
not be as useful as the ‘Makefile’s do not take up much space.

2.3.4 Parallel build trees
--------------------------

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 ‘Makefile’s are unique to each build directory
and will not interfere with each other.

2.3.5 Adding debugging symbols
------------------------------

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 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 ‘-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
(sadly, a bug in the build system source file in Hamlib 1.2.15.3 and
earlier did not preserve ‘CXXFLAGS’).

     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.

2.3.6 Compiling for MS Windows 32 bit architectures
---------------------------------------------------

Currently compiling is done on an Xubuntu 10.10 virtual machine using
MinGW32 (http://www.mingw.org/).  ‘README.build-win32’ in the ‘scripts’
directory has details on how this is accomplished.

   Work is ongoing to correct build issues in the Cygwin
(http://www.cygwin.com/) environment running on MS Windows.

2.4 Pre-compiled binaries for MS Windows 32 bit architectures
=============================================================

Pre-compiled binaries for MS Windows 32 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
(http://sourceforge.net/projects/hamlib/files/hamlib/).  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.win32-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 <hamlib-developer@lists.sourceforge.net>.

3 Utility programs reference
****************************

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 and offering a
network accessible API.

   This chapter focuses on the two test programs, ‘rigctl’ for testing
radio back ends and ‘rotctl’ for testing rotor back ends and the two
network daemons, ‘rigctld’ and ‘rotcltd’ for radio and rotor access via
network sockets.

3.1 ‘rigctl’
============

‘rigctl’ is the most frequently used Hamlib utility.  As the other
utilities share many of the same characteristics, much of the
introductory information presented in this section is applicable to the
other utility programs.

3.1.1 Introduction to ‘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
(http://cnswww.cns.cwru.edu/php/chet/readline/rltop.html) 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 MS 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       Beta

     The 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. ’‘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.

3.1.2 ‘rigctl’ invocation
-------------------------

Here are some additional examples for invoking ‘rigctl’ for various
situations.

Start ‘rigctl’ for a Yaesu FT-920 using a USB to serial adapter on Linux
in interactive mode:

     rigctl -m 114 -r /dev/ttyUSB1

Start ‘rigctl’ for a Yaesu FT-920 using ‘COM1’ on MS Windows while
generating TRACE output to ‘stderr’:

     rigctl -m 114 -r COM1 -vvvvv

Start ‘rigctl’ for a Yaesu FT-920 using a USB to serial adapter on Linux
while setting baud rate and stop bits:

     rigctl -m 114 -r /dev/ttyUSB1 -s 4800 -C stop_bits=2

Start ‘rigctl’ for an Elecraft K3 using a USB to serial adapter on Linux
while specifying a command terminator for the ‘w’ command:

     rigctl -m 229 -r /dev/ttyUSB0 -t';'

Connect to a running ‘rigctld’ with radio model 2 (‘NET rigctl’) on the
local host and specifying the TCP port, setting frequency and mode:

     rigctl -m 2 -r localhost:4532 F 7253500 M LSB 0

   *N.B.* On MS Windows ‘localhost’ may need to be replaced with the
actual loopback IP address–‘127.0.0.1’–or the address passed to
‘rigctld’ with the ‘-T’ option.

3.1.3 ‘rigctl’ command line options
-----------------------------------

The ‘rigctl’ command line options (not to be confused with ‘rigctl’
commands) control the action of various features.  Options consist of
both “short options”–a single hyphen ’‘-’’ followed by a single letter
and “long options”–two hyphens ’‘--’’ followed by several letters often
comprising one or more words separated by a hyphen.

   ‘rigctl’ accepts the following options:

‘-m’
‘--model=ID’
     Select radio model number.  See model list (use ‘rigctl -l’).

     *N.B.* ‘rigctl’ (or third party software) will use rig model 2 for
     NET rigctl (‘rigctld’).

‘-r’
‘--rig-file=DEVICE’
     Use DEVICE as the file name of the port the radio is connected.
     Often a serial port, but could be a USB to serial adapter.
     Typically ‘/dev/ttyS0’ , ‘/dev/ttyS1’ , ‘/dev/ttyUSB0’ , etc. on
     Linux or ‘COM1’ , ‘COM2’ , etc. on MS Windows.

‘-p’
‘--ptt-file=DEVICE’
     Use DEVICE as the file name of the Push-To-Talk device using a
     device file as described above.

‘-d’
‘--dcd-file=DEVICE’
     Use DEVICE as the file name of the Data Carrier Detect device using
     a device file as described above.

‘-P’
‘--ptt-type=TYPE’
     Use TYPE of Push-To-Talk device.  Supported types are ‘RIG’, ‘DTR’,
     ‘RTS’, ‘PARALLEL’, ‘NONE’, overriding PTT type defined in the rig’s
     backend.

     Some side effects of this command are that when type is set to
     ‘DTR’, read PTT state comes from Hamlib frontend, not read from the
     radio.  When set to ‘NONE’, PTT state cannot be read or set even if
     rig backend supports reading/setting PTT status from the rig.

‘-D’
‘--dcd-type=TYPE’
     Use TYPE of Data Carrier Detect device.  Supported types are ‘RIG’
     (CAT command), ‘DSR’, ‘CTS’, ‘CD’, ‘PARALLEL’, ‘NONE’.

‘-s’
‘--serial-speed=BAUD’
     Set serial speed to BAUD rate.  Uses *maximum* serial speed from
     rig backend capabilities (set by ‘-m’ above) as the default.

‘-c’
‘--civaddr=ID’
     Use ID as the CI-V address to communicate with the rig.  Only
     useful for Icom radios and those using the Icom protocol.

     *N.B.* The ID is in decimal notation, unless prefixed by ‘0x’, in
     which case it is a hexadecimal value.

‘-t’
‘--send-cmd-term=CHAR’
     Change the termination CHAR for text protocol when using the
     ‘send_cmd’ command.  The default value is ‘<CR>’ (‘0x0d’).  Non
     ASCII printable characters can be specified as an ASCII number, in
     hexadecimal format, prepended with ‘0x’.  You may pass an empty
     string for no termination char.  The string ’‘-1’’ tells ‘rigctl’
     to switch to binary protocol.  See the ‘send_cmd’ command for
     further explanation.

‘-L’
‘--show-conf’
     List all config parameters for the radio defined with ‘-m’ above.

‘-C’
‘--set-conf=PARM=VAL[,PARM=VAL,…]’
     Set config parameter.  e.g. ‘stop_bits=2’

     Use ‘-L’ option for a list.

‘-l’
‘--list’
     List all model numbers defined in Hamlib and exit.  As of 1.2.15.1
     the list is sorted by model number.

     *N.B.* In Linux the list can be scrolled back using
     ‘<SHIFT>-PageUp’/ ‘<SHIFT>-PageDown’, or using the scrollbars of a
     virtual terminal in X or the ‘cmd’ window in MS Windows.  The
     output can be piped to ’‘more’’ or ’‘less’’, e.g. ’‘rigctl -l |
     more’’.

‘-u’
‘--dump-caps’
     Dump capabilities for the radio defined with ‘-m’ above and exit.

‘-o’
‘--vfo’
     Set vfo mode, requiring an extra VFO argument in front of each
     appropriate command (except ‘set_vfo’!).  Otherwise, ‘currVFO’ is
     assumed when this option is not set and an extra VFO argument is
     not used.  See ‘chk_vfo’ below.

‘-i’
‘--read-history’
     Read previously saved command and argument history from a file
     (default ’‘~/.rigctl_history’’) for the current session.  Available
     when ‘rigctl’ is built with Readline support.

     *N.B.* To read a history file stored in another directory, set the
     ‘RIGCTL_HIST_DIR’ environment variable, e.g.
     ’‘RIGCTL_HIST_DIR=~/tmp rigctl -i’’.  When ‘RIGCTL_HIST_DIR’ is not
     set, the value of ‘HOME’ is used.

‘-I’
‘--save-history’
     Write current session (and previously saved session(s) if ‘-i’
     option is also given) command and argument history to a file
     (default ’‘~/.rigctl_history’’) at the end of the current session.
     Complete commands with arguments are saved as a single line to be
     recalled and used or edited.  Available when ‘rigctl’ is built with
     Readline support.

     To write a history file in another directory, set the
     ‘RIGCTL_HIST_DIR’ environment variable, e.g.
     ’‘RIGCTL_HIST_DIR=~/tmp rigctl -I’’.  When ‘RIGCTL_HIST_DIR’ is not
     set, the value of ‘HOME’ is used.

‘-v’
‘--verbose’
     Set verbose mode level, cumulative i.e. ‘-vvvvv’ sets maximum
     debugging output to ‘stderr’.

     Five different levels of diagnostics can be output to ‘stderr’ and
     correspond to ‘-v’ for ‘BUG’, ‘-vv’ for ‘ERR’, ‘-vvv’ for ‘WARN’,
     ‘-vvvv’ for ‘VERBOSE’, or ‘-vvvvv’ for ‘TRACE’.  Back end authors
     will use the verbose facility to print critical values useful for
     testing and will often ask for this output in response to a request
     for help.

‘-h’
‘--help’
     Show summary of these options and exit.

‘-V’
‘--version’
     Show version of ‘rigctl’ and exit.

     Note: Some options may not be implemented by a given backend and
     will return an error.  This is most likely to occur with the
     ‘--set-conf’ and ‘--show-conf’ options.

3.1.4 ‘rigctl’ commands
-----------------------

Commands can be entered either as a single char, or as a long command
name.  Basically, the commands do not take a dash in front of them on
the command line, as the options do.  They may be typed in when in
interactive mode or provided as argument(s) in command line interface
mode.  In interactive mode commands and their arguments may be entered
on a single line:

     Rig command: M LSB 2400

or singly and ‘rigctl’ will prompt for any needed values.

   Since most of the Hamlib operations have a “set” and a “get” method,
in general an upper case letter will be used for set methods whereas the
corresponding lower case letter refers to the get method.  Each
operation also has a long name; prepend a backslash ‘\’ to enter a long
command name.

     Example: Use ‘\dump_caps’ to see what this radio can do.

Be aware that the backend for the radio to be controlled, or the radio
itself may not support some commands.  In that case, the operation will
fail with a Hamlib error message.

   Here is a summary of the supported commands:

   • Command short name is followed by the long name which is followed
     by any variable names.

   • Some short commands are noted as hexadecimal digits due to the
     limitation of upper and lower case letters available.  Use the
     associated long command name instead.

   • While a comma is used to separate variable names in this document,
     they are not part of the command syntax used by ‘rigctl’.  Use a
     space to separate values.

   • In the case of “set” commands the variable NAME is replaced by the
     value in the description.

   • In the case of “get” commands the variable NAME is the key name of
     the value returned.

‘q’
     Exit ‘rigctl’ in interactive mode (‘q’ is not case sensitive).

     When ‘rigctl’ is controlling the rig directly, will close the rig
     back end and port.  When ‘rigctl’ is connected to ‘rigctld’ (rig
     model 2), the TCP/IP connection to ‘rigctld’ is closed and
     ‘rigctld’ remains running, available for another TCP/IP network
     connection.

‘F, set_freq FREQUENCY’
     Set FREQUENCY, in Hertz.

‘f, get_freq’
     Get FREQUENCY, in Hertz.

‘M, set_mode MODE, PASSBAND’
     Set MODE to one of: ‘USB’, ‘LSB’, ‘CW’, ‘CWR’, ‘RTTY’, ‘RTTYR’,
     ‘AM’, ‘FM’, ‘WFM’, ‘AMS’, ‘PKTLSB’, ‘PKTUSB’, ‘PKTFM’, ‘ECSSUSB’,
     ‘ECSSLSB’, ‘FAX’, ‘SAM’, ‘SAL’, ‘SAH’, ‘DSB’.

     Set PASSBAND frequency in Hertz, or ‘0’ for the Hamlib backend
     default.

     *N.B.* Passing a ‘?’ (query) as the first argument instead of MODE
     will return a space separated list of radio backend supported
     Modes.  Use this to determine the supported Modes of a given radio
     backend.

‘m, get_mode’
     Get MODE, PASSBAND.

     Returns Mode as a string from ‘set_mode’ above and Passband
     frequency in Hertz.

‘V, set_vfo VFO’
     Set VFO to one of: ‘VFOA’, ‘VFOB’, ‘VFOC’, ‘currVFO’, ‘VFO’, ‘MEM’,
     ‘Main’, ‘Sub’, ‘TX’, ‘RX’.

     In VFO mode only a single VFO parameter is required.

‘v, get_vfo’
     Get current VFO.

     Returns VFO as a string from ‘set_vfo’ above.

‘J, set_rit RIT’
     Set RIT, in Hertz, can be a positive or negative value.

     A value of ‘0’ resets RIT and _should_ turn RIT off.  If not, file
     a bug report against the Hamlib backend.

     *N.B.* This functionality is under transition and in the future
     will need to be activated with the ‘set_func’ command.

‘j, get_rit’
     Get RIT, in Hertz.

‘Z, set_xit XIT’
     Set XIT, in Hertz, can be a positive or negative value.

     A value of ‘0’ resets XIT and _should_ turn XIT off.  If not, file
     a bug report against the Hamlib backend.

     *N.B.* This functionality is under transition and in the future
     will need to be activated with the ‘set_func’ command.

‘z, get_xit’
     Get XIT, in Hertz.

‘T, set_ptt PTT’
     Set PTT to one of: ‘0’ (RX), ‘1’ (TX), ‘2’ (TX mic), ‘3’ (TX data).

‘t, get_ptt’
     Get PTT status.

‘0x8b, get_dcd’
     Get DCD (squelch) status, ‘0’ (Closed) or ‘1’ (Open)

‘R, set_rptr_shift RPTR SHIFT’
     Set RPTR SHIFT: ‘+’, ‘-’ or something else for none.

‘r, get_rptr_shift’
     Get RPTR SHIFT.  Returns ‘+’, ‘-’ or ‘None’.

‘O, set_rptr_offs RPTR OFFSET’
     Set RPTR OFFSET, in Hertz.

‘o, get_rptr_offs’
     Get RPTR OFFSET, in Hertz.

‘C, set_ctcss_tone CTCSS TONE’
     Set CTCSS TONE, in tenths of Hertz.

     CTCSS, "Continuous Tone Coded Squelch System"
     (http://en.wikipedia.org/wiki/Continuous_Tone-Coded_Squelch_System),
     is a method used to reduce the annoyance of listening to other
     users on a shared two-way communications radio channel by imposing
     a tone on the transmitted signal.  Also known as "subaudible tone"
     and PL, "Private Line".

‘c, get_ctcss_tone’
     Get CTCSS TONE, in tenths of Hertz.

‘D, set_dcs_code DCS CODE’
     Set DCS CODE.

     DCS, "Digital-Coded Squelch"
     (http://en.wikipedia.org/wiki/Digital-Coded_Squelch#DCS) is a
     digital version of CTCSS which imposes a digital code on the
     transmitted signal.

‘d, get_dcs_code’
     Get DCS CODE.

‘0x90, set_ctcss_sql CTCSS SQL’
     Set CTCSS SQL tone, in tenths of Hertz.

‘0x91, get_ctcss_sql’
     Get CTCSS SQL tone, in tenths of Hertz.

‘0x92, set_dcs_sql DCS SQL’
     Set DCS SQL code.

‘0x93, get_dcs_sql’
     Get DCS SQL code.

‘I, set_split_freq TX FREQUENCY’
     Set TX FREQUENCY, in Hertz for “split” frequency operation.

‘i, get_split_freq’
     Get TX FREQUENCY, in Hertz for “split” frequency operation.

‘X, set_split_mode TX MODE, TX PASSBAND’
     Set TX MODE to one of: ‘AM’, ‘FM’, ‘CW’, ‘CWR’, ‘USB’, ‘LSB’,
     ‘RTTY’, ‘RTTYR’, ‘WFM’, ‘AMS’, ‘PKTLSB’, ‘PKTUSB’, ‘PKTFM’,
     ‘ECSSUSB’, ‘ECSSLSB’, ‘FAX’, ‘SAM’, ‘SAL’, ‘SAH’, ‘DSB’.

     The TX PASSBAND is the exact passband frequency in Hertz, or ‘0’
     for the Hamlib backend default.

     *N.B.* Passing a ‘?’ (query) as the first argument instead of TX
     MODE will return a space separated list of radio backend supported
     TX Modes.  Use this to determine the supported TX Modes of a given
     radio backend.

‘x, get_split_mode’
     Get TX MODE, TX PASSBAND.

     Returns TX mode as a string from ‘set_split_mode’ above and TX
     passband in Hz.

‘S, set_split_vfo SPLIT, TX VFO’
     Set SPLIT mode, ‘0’ (off) or ‘1’ (on), and TX VFO from ‘set_vfo’
     above.

‘s, get_split_vfo’
     Get SPLIT mode, ‘0’ (off) or ‘1’ (on), and TX VFO.

‘N, set_ts TUNING STEP’
     Set TUNING STEP, in Hertz.

‘n, get_ts’
     Get TUNING STEP, in Hertz.

‘U, set_func FUNC, FUNC STATUS’
     Set FUNC, FUNC STATUS.

     FUNC is one of: ‘FAGC’, ‘NB’, ‘COMP’, ‘VOX’, ‘TONE’, ‘TSQL’,
     ‘SBKIN’, ‘FBKIN’, ‘ANF’, ‘NR’, ‘AIP’, ‘APF’, ‘MON’, ‘MN’, ‘RF’,
     ‘ARO’, ‘LOCK’, ‘MUTE’, ‘VSC’, ‘REV’, ‘SQL’, ‘ABM’, ‘BC’, ‘MBC’,
     ‘RIT’, ‘AFC’, ‘SATMODE’, ‘SCOPE’, ‘RESUME’, ‘TBURST’, ‘TUNER’,
     ‘XIT’.

     Func Status argument is ‘1’ for “activate”, ‘0’ for “de-activate”,
     much as TRUE/FALSE definitions in the C/C++ languages (true is
     non-zero and false is zero).

     *N.B.* Passing a ‘?’ (query) as the first argument instead of FUNC
     will return a space separated list of radio backend supported “set”
     functions.  Use this to determine the supported functions of a
     given radio backend.

‘u, get_func FUNC’
     Get FUNC STATUS.

     Returns FUNC STATUS as a non null value for the FUNC passed.  FUNC
     is a token from the list in ‘set_func’ above.

     *N.B.* Passing a ‘?’ (query) as the first argument instead of FUNC
     will return a space separated list of radio backend supported “get”
     functions.  Use this to determine the supported functions of a
     given radio backend.

‘L, set_level LEVEL, LEVEL VALUE’
     Set LEVEL, LEVEL VALUE.

     LEVEL is one of: ‘PREAMP’, ‘ATT’, ‘VOX’, ‘AF’, ‘RF’, ‘SQL’, ‘IF’,
     ‘APF’, ‘NR’, ‘PBT_IN’, ‘PBT_OUT’, ‘CWPITCH’, ‘RFPOWER’, ‘MICGAIN’,
     ‘KEYSPD’, ‘NOTCHF’, ‘COMP’, ‘AGC’(‘0’:OFF, ‘1’:SUPERFAST, ‘2’:FAST,
     ‘3’:SLOW, ‘4’:USER, ‘5’:MEDIUM, ‘6’:AUTO), ‘BKINDL’, ‘BAL’,
     ‘METER’, ‘VOXGAIN’, ‘ANTIVOX’, ‘SLOPE_LOW’, ‘SLOPE_HIGH’, ‘RAWSTR’,
     ‘SWR’, ‘ALC’, ‘STRENGTH’.

     The LEVEL VALUE can be a float or an integer.

     *N.B.* Passing a ‘?’ (query) as the first argument instead of LEVEL
     will return a space separated list of radio backend supported “set”
     levels.  Use this to determine the supported levels of a given
     radio backend.

‘l, get_level LEVEL’
     Get LEVEL VALUE.

     Returns LEVEL VALUE as a float or integer for the LEVEL passed.
     LEVEL is a token from the list in ‘set_level’ above.

     *N.B.* Passing a ‘?’ (query) as the first argument instead of LEVEL
     will return a space separated list of radio backend supported “get”
     levels.  Use this to determine the supported levels of a given
     radio backend.

‘P, set_parm PARM, PARM VALUE’
     Set PARM, PARM VALUE

     PARM is one of: ‘ANN’, ‘APO’, ‘BACKLIGHT’, ‘BEEP’, ‘TIME’, ‘BAT’,
     ‘KEYLIGHT’.

     *N.B.* Passing a ‘?’ (query) as the first argument instead of PARM
     will return a space separated list of radio backend supported “set”
     parameters.  Use this to determine the supported parameters of a
     given radio backend.

‘p, get_parm PARM’
     Get PARM VALUE.

     Returns PARM VALUE as a float or integer for the PARM passed.  PARM
     is a token from the list in ‘set_parm’ above.

     *N.B.* Passing a ‘?’ (query) as the first argument instead of PARM
     will return a space separated list of radio backend supported “get”
     parameters.  Use this to determine the supported parameters of a
     given radio backend.

‘B, set_bank BANK’
     Set BANK.  Sets the current memory bank number.

‘E, set_mem MEMORY#’
     Set MEMORY# channel number.

‘e, get_mem’
     Get MEMORY# channel number.

‘G, vfo_op MEM/VFO OP’
     Perform MEM/VFO OP.

     MEM/VFO OPeration is one of: ‘CPY’, ‘XCHG’, ‘FROM_VFO’, ‘TO_VFO’,
     ‘MCL’, ‘UP’, ‘DOWN’, ‘BAND_UP’, ‘BAND_DOWN’, ‘LEFT’, ‘RIGHT’,
     ‘TUNE’, ‘TOGGLE’.

     *N.B.* Passing a ‘?’ (query) as the first argument instead of
     MEM/VFO OP will return a space separated list of radio backend
     supported “set” Mem/VFO Ops.  Use this to determine the supported
     Mem/VFO Ops of a given radio backend.

‘g, scan SCAN FCT, SCAN CHANNEL’
     Perform SCAN FCT SCAN CHANNEL.

     Scan function/channel is one of: ‘STOP’, ‘MEM’, ‘SLCT’, ‘PRIO’,
     ‘PROG’, ‘DELTA’, ‘VFO’, ‘PLT’.

     *N.B.* Passing a ‘?’ (query) as the first argument instead of SCAN
     FCT will return a space separated list of radio backend supported
     Scan Functions.  Use this to determine the supported Scan Functions
     of a given radio backend.

‘H, set_channel CHANNEL’
     Set memory CHANNEL data.  Not implemented yet.

‘h, get_channel’
     Get memory CHANNEL data.  Not implemented yet.

‘A, set_trn TRANSCEIVE’
     Set TRANSCEIVE mode (reporting event): ‘OFF’, ‘RIG’, ‘POLL’.

     *N.B.* Passing a ‘?’ (query) as the first argument instead of
     TRANSCEIVE will return a space separated list of radio backend
     supported Scan Transceive modes.  Use this to determine the
     supported Transceive modes of a given radio backend.

‘a, get_trn’
     Get TRANSCEIVE mode (reporting event) as in ‘set_trn’ above.

‘Y, set_ant ANTENNA’
     Set ANTENNA number (‘0’, ‘1’, ‘2’, …).

‘y, get_ant’
     Get ANTENNA number (‘0’, ‘1’, ‘2’, …).

‘*, reset RESET’
     Perform rig RESET.

     ‘0’ = None, ‘1’ = Software reset, ‘2’ = VFO reset, ‘4’ = Memory
     Clear reset, ‘8’ = Master reset.  Since these values are defined as
     a bitmask in ‘rig.h’, it should be possible to ‘AND’ these values
     together to do multiple resets at once, if the backend supports it
     or supports a reset action via rig control at all.

‘b, send_morse MORSE’
     Send MORSE symbols.

‘0x87, set_powerstat POWER STATUS’
     Set power On/Off/Standby POWER STATUS.

     ‘0’ = Power Off, ‘1’ = Power On, ‘2’ = Power Standby.  Defined as a
     bitmask in ‘rig.h’.

‘0x88, get_powerstat’
     Get power On/Off/Standby POWER STATUS as in ‘set_powerstat’ above.

‘0x89, send_dtmf DIGITS’
     Set DTMF DIGITS.

‘0x8a, recv_dtmf’
     Get DTMF DIGITS.

‘_, get_info’
     Get misc information about the rig

     VFO parameter not used in ’VFO mode’.

‘1, dump_caps’
     Not a real rig remote command, it just dumps capabilities, i.e.
     what the backend knows about this model, and what it can do.

     TODO: Ensure this is in a consistent format so it can be read into
     a hash, dictionary, etc.  Bug reports requested.

     *N.B.* This command will produce many lines of output so be very
     careful if using a fixed length array!  For example, running this
     command against the Dummy backend results in over 5kB of text
     output.

     VFO parameter not used in ’VFO mode’.

‘2, power2mW POWER 0.0..1.0, FREQUENCY, MODE’
     Returns POWER MW

     Converts a POWER value in a range of ‘0.0..1.0’ to the real
     transmit power in milli-Watts (integer).  The FREQUENCY and MODE
     also need to be provided as output power may vary according to
     these values.

     VFO parameter not used in ’VFO mode’.

‘4, mW2power POWER MW, FREQUENCY, MODE’
     Returns POWER 0.0..1.0

     Converts the real transmit power in milli-Watts (integer) to a
     POWER value in a range of ‘[0.0..1.0]’.  The FREQUENCY and MODE
     also need to be provided as output power may vary according to
     these values.

     VFO parameter not used in ’VFO mode’.

‘w, send_cmd CMD’
     Send raw command string to rig.  This is useful for testing and
     troubleshooting rig commands and responses when developing a
     backend.

     For binary protocols enter values as ‘\0xAA\0xBB’.  Expect a REPLY
     from the rig which will likely be a binary block or an ASCII string
     depending on the rig’s protocol (see your radio’s computer control
     documentation).

     The command terminator, set by the ‘--send-cmd-term’ option above,
     will terminate each command string sent to the radio.  This
     character should not be a part of the input string.

3.1.5 ‘rigctl’ Readline support
-------------------------------

If Readline library development files are found at configure time,
‘rigctl’ will be conditonally built with Readline support for command
and argument entry.  Readline command key bindings are at their defaults
as described in the Readline manual
(http://cnswww.cns.cwru.edu/php/chet/readline/rluserman.html) although
‘rigctl’ sets the name ‘rigctl’ which can be used in ‘Conditional Init
Constructs’ in the Readline Init File (‘~/.inputrc’ by default) for
custom keybindings unique to ‘rigctl’.

   Command history is available with Readline support as described in
the Readline History manual
(http://cnswww.cns.cwru.edu/php/chet/readline/history.html#SEC1).
Command and argument strings are stored as single lines even when
arguments are prompted for input individually.  Commands and arguments
are not validated and are stored as typed with values separated by a
single space.

   Normally session history is not saved, however, use of either of the
‘-i’/‘--read-history’ or ‘-I’/‘--save-history’ options when starting
‘rigctl’ will cause any previously saved history to be read in and/or
the current and any previous session history (assuming the ‘-i’ and ‘-I’
options are given together) will be written out when ‘rigctl’ is closed.
Each option is mutually exclusive, i.e.  either may be given separately
or in combination.  This is useful to save a set of commands and then
read them later but not write the modified history for a consistent set
of test commands in interactive mode, for example.

   History is stored in ‘~/.rigctl_history’ by default although the
destination directory may be changed by setting the ‘RIGCTL_HIST_DIR’
environment variable.  When ‘RIGCTL_HIST_DIR’ is unset, the value of the
‘HOME’ environment variable is used instead.  Only the destination
directory may be changed at this time.

   If Readline support is not found at configure time the original
internal command handler is used.  Readline is not used for ‘rigctl’
commands entered on the command line regardless if Readline support is
built in or not.

     Note: Readline support is not included in the MS Windows 32 binary
     builds supplied by the Hamlib Project.  Running ‘rigctl’ on the MS
     Windows 32 platform in the ‘cmd’ shell does give session command
     line history, however, it is not saved to disk between sessions.

3.2 ‘rotctl’
============

Identical in function to ‘rigctl’, ‘rotctl’ provides a means for testing
Hamlib functions useful for rotor control and QRA locator computations.
As rotors have a much narrower scope than radios, there are fewer
command line options and commands for ‘rotctl’.

3.2.1 Introduction to ‘rotctl’
------------------------------

‘rotctl’ is a character based interactive program and a command line
program able to set or query a rotor’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’.  Recent additions to ‘rotctl’ allow command
editing and history recall through use of the Readline
(http://cnswww.cns.cwru.edu/php/chet/readline/rltop.html) 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 rotor model.
This is a feature where the Hamlib internal rotor dummy is used instead.
The dummy rotor provides a way to test Hamlib functions with out the
need for actual rotor hardware.  However, to develop back end capability
for a given rotor, having the actual radio 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
rotor back end model.  The ‘-r’ option takes the path to the port device
on POSIX and 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
           Rig #  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        Untested

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

3.2.2 ‘rotctl’ invocation
-------------------------

Here are some additional examples for invoking ‘rotctl’ for various
situations.

   Start ‘rotctl’ for RotorEZ using the first serial port on Linux:

     rotctl -m 401 -r /dev/ttyS0

Start ‘rotctl’ for RotorEZ using ‘COM2’ on MS Windows:

     rotctl -m 401 -r COM2

Connect to a running ‘rotctld’ with rotor model 2 (‘NET rotctl’) on the
local host and specifying the TCP port, and querying the position:

     rotctl -m 2 -r localhost:4533 \get_pos

3.2.3 ‘rotctl’ command line options
-----------------------------------

‘rotctl’ accepts the following options:

‘-m’
‘--model=ID’
     Select rotator model number.  See model list (use ‘rotctl -l’).

     *N.B.* ‘rotctl’ (or third party software) will use rotor model 2
     for NET rotctl (‘rotctld’).

‘-r’
‘--rig-file=DEVICE’
     Use DEVICE as the file name of the port the rotor is connected.
     Often a serial port, but could be a USB to serial adapter.
     Typically ‘/dev/ttyS0’ , ‘/dev/ttyS1’ , ‘/dev/ttyUSB0’ , etc. on
     Linux or ‘COM1’ , ‘COM2’ , etc. on MS Windows.

‘-s’
‘--serial-speed=BAUD’
     Set serial speed to BAUD rate.  Uses *maximum* serial speed from
     rotor backend capabilities as the default.

‘-t’
‘--send-cmd-term=CHAR’
     Change the termination CHAR for text protocol when using the
     ‘send_cmd’ command.  The default value is ‘<CR>’ (‘0x0d’).  Non
     ASCII printable characters can be specified as an ASCII number, in
     hexadecimal format, prepended with ‘0x’.  You may pass an empty
     string for no termination char.  The string ’‘-1’’ tells ‘rotctl’
     to switch to binary protocol.  See the ‘send_cmd’ command for
     further explanation.

‘-L’
‘--show-conf’
     List all config parameters for the rotor defined with ‘-m’ above.

‘-C’
‘--set-conf=PARM=VAL[,PARM=VAL,…]’
     Set config parameter.  e.g. ‘stop_bits=2’

     Use ‘-L’ option for a list.

‘-l’
‘--list’
     List all model numbers defined in Hamlib and exit.  As of 1.2.15.1
     the list is sorted by model number.

     *N.B.* In Linux the list can be scrolled back using
     ‘<SHIFT>-PageUp’/ ‘<SHIFT>-PageDown’, or using the scrollbars of a
     virtual terminal in X or the ‘cmd’ window in MS Windows.  The
     output can be piped to ’‘more’’ or ’‘less’’, e.g. ’‘rotctl -l |
     more’’.

‘-u’
‘--dump-caps’
     Dump capabilities for the rotor defined with ‘-m’ above and exit.

‘-i’
‘--read-history’
     Read previously saved command and argument history from a file
     (default ’‘~/.rotctl_history’’) for the current session.  Available
     when ‘rotctl’ is built with Readline support.

     *N.B.* To read a history file stored in another directory, set the
     ‘ROTCTL_HIST_DIR’ environment variable, e.g.
     ’‘ROTCTL_HIST_DIR=~/tmp rotctl -i’’.  When ‘ROTCTL_HIST_DIR’ is not
     set, the value of ‘HOME’ is used.

‘-I’
‘--save-history’
     Write current session (and previously saved session(s) if ‘-i’
     option is also given) command and argument history to a file
     (default ’‘~/.rotctl_history’’) at the end of the current session.
     Complete commands with arguments are saved as a single line to be
     recalled and used or edited.  Available when ‘rotctl’ is built with
     Readline support.

     To write a history file in another directory, set the
     ‘ROTCTL_HIST_DIR’ environment variable, e.g.
     ’‘ROTCTL_HIST_DIR=~/tmp rotctl -I’’.  When ‘ROTCTL_HIST_DIR’ is not
     set, the value of ‘HOME’ is used.

‘-v’
‘--verbose’
     Set verbose mode level, cumulative i.e. ‘-vvvvv’ sets maximum
     debugging output to ‘stderr’.

     Five different levels of diagnostics can be output to ‘stderr’ and
     correspond to ‘-v’ for ‘BUG’, ‘-vv’ for ‘ERR’, ‘-vvv’ for ‘WARN’,
     ‘-vvvv’ for ‘VERBOSE’, or ‘-vvvvv’ for ‘TRACE’.  Back end authors
     will use the verbose facility to print critical values useful for
     testing and will often ask for this output in response to a request
     for help.

‘-h’
‘--help’
     Show summary of these options and exit.

‘-V’
‘--version’
     Show version of ‘rotctl’ and exit.

     Note: Some options may not be implemented by a given backend and
     will return an error.  This is most likely to occur with the
     ‘--set-conf’ and ‘--show-conf’ options.

3.2.4 ‘rotctl’ commands
-----------------------

See rigctl commands, for command syntax.

   *Rotor commands*

   Here is a summary of the supported commands:

‘q’
     Exit ‘rotctl’ in interactive mode (‘q’ is not case sensitive).

     When ‘rotctl’ is controlling the rotor directly, will close the
     rotor back end and port.  When ‘rotctl’ is connected to ‘rotctld’
     (rotor model 2), the TCP/IP connection to ‘rotctld’ is closed and
     ‘rotctld’ remains running, available for another TCP/IP network
     connection.

‘P, set_pos AZIMUTH, ELEVATION’
     Set position: AZIMUTH and ELEVATION as double precision floating
     point values.

‘p, get_pos’
     Get position: AZIMUTH and ELEVATION as double precision floating
     point values.

‘M, move DIRECTION, SPEED’
     Move the rotator in a specific direction at the given rate.

     Values are integers where DIRECTION is defined as ‘2’ = Up, ‘4’ =
     Down, ‘8’ = Left, and ‘16’ = Right.  SPEED is an integer between
     ‘1’ and ‘100’.

     *N.B.* Not all backends that implement the move command use the
     Speed value.  At this time only the gs232a utilizes the Speed
     parameter.

‘S, stop’
     Stop the rotator.

‘K, park’
     Park the antenna.

‘C, set_conf TOKEN, VALUE’
     Set a configuration parameter.  It is safe to give TOKEN a value of
     ‘0’ (zero).  VALUE may be a string up to 20 characters.

     See ‘-L’ output.

‘R, reset RESET’
     Reset the rotator.

     Integer value of ‘1’ for Reset All.

‘_, get_info’
     Get misc information on the rotator.

     At the moment returns MODEL NAME.

‘w, send_cmd CMD’
     Send raw command string to the rotator.

     ‘<CR>’ (or ‘send-cmd-term’, see ‘-t’ option) is appended
     automatically at the end of the command for text protocols.  For
     binary protocols, enter values as ‘\0xAA\0xBB’.

   *Locator Commands*

   These commands offer conversions of Degrees Minutes Seconds to other
formats, Maidenhead square locator conversions and distance and azimuth
conversions.

‘L, lonlat2loc LONGITUDE, LATITUDE, LOC LEN 2..12’
     Returns the Maidenhead locator for the given LONGITUDE and
     LATITUDE.

     Both are floating point values.  The precision of the returned
     square is controlled by LOC LEN which should be an even numbered
     integer value between ‘2’ and ‘12’.

     For example, ‘L -170.000000 -85.000000 12’ returns ‘Locator:
     AA55AA00AA00’.

‘l, loc2lonlat LOCATOR’
     Returns LONGITUDE and LATITUDE in decimal degrees at the
     approximate center of the requested grid square (despite the use of
     double precision variables internally, some rounding error occurs).
     West longitude is expressed as a negative value.  South latitude is
     expressed as a negative value.  Locator can be from 2 to 12
     characters in length.

     For example, ‘l AA55AA00AA00’ returns ‘Longitude: -169.999983
     Latitude: -84.999991’.

‘D, dms2dec DEGREES, MINUTES, SECONDS, S/W’
     Returns DEC DEGREES, a signed floating point value.

     DEGREES and MINUTES are integer values and SECONDS is a floating
     point value.  S/W is a flag with ‘1’ indicating South latitude or
     West longitude and ‘0’ North or East (the flag is needed as
     computers don’t recognize a signed zero even though only the
     DEGREES value only is typically signed in DMS notation).

‘d, dec2dms DEC DEGREES’
     Returns DEGREES, MINUTES, SECONDS, S/W.

     Values are as in ‘dms2dec’ above.

‘E, dmmm2dec DEGREES, DEC MINUTES, S/W’
     Returns DEC DEGREES, a signed floating point value.

     DEGREES is an integer value and MINUTES is a floating point value.
     S/W is a flag with ‘1’ indicating South latitude or West longitude
     and ‘0’ North or East (the flag is needed as computers don’t
     recognize a signed zero even though only the DEGREES value only is
     typically signed in DMS notation).

‘e, dec2dmmm DEC DEG’
     Returns DEGREES, MINUTES, S/W.

     Values are as in ‘dmmm2dec’ above.

‘B, qrb LON 1, LAT 1, LON 2, LAT 2’
     Returns DISTANCE and AZIMUTH where DISTANCE is in km and AZIMUTH is
     in degrees.

     All LON/LAT values are signed floating point numbers.

‘A, a_sp2a_lp SHORT PATH DEG’
     Returns LONG PATH DEG or ‘-RIG_EINVAL’ upon input error.

     Both are floating point values within the range ‘0.00’ to 360.00.

‘a, d_sp2d_lp SHORT PATH KM’
     Returns LONG PATH KM.

     Both are floating point values.

3.2.5 ‘rotctl’ Readline support
-------------------------------

If Readline library development files are found at configure time,
‘rotctl’ will be conditonally built with Readline support for command
and argument entry.  Readline command key bindings are at their defaults
as described in the Readline manual
(http://cnswww.cns.cwru.edu/php/chet/readline/rluserman.html) although
‘rotctl’ sets the name ‘rotctl’ which can be used in ‘Conditional Init
Constructs’ in the Readline Init File (‘~/.inputrc’ by default) for
custom keybindings unique to ‘rotctl’.

   Command history is available with Readline support as described in
the Readline History manual
(http://cnswww.cns.cwru.edu/php/chet/readline/history.html#SEC1).
Command and argument strings are stored as single lines even when
arguments are prompted for input individually.  Commands and arguments
are not validated and are stored as typed with values separated by a
single space.

   Normally session history is not saved, however, use of either of the
‘-i’/‘--read-history’ or ‘-I’/‘--save-history’ options when starting
‘rotctl’ will cause any previously saved history to be read in and/or
the current and any previous session history (assuming the ‘-i’ and ‘-I’
options are given together) will be written out when ‘rotctl’ is closed.
Each option is mutually exclusive, i.e.  either may be given separately
or in combination.  This is useful to save a set of commands and then
read them later but not write the modified history for a consistent set
of test commands in interactive mode, for example.

   History is stored in ‘~/.rotctl_history’ by default although the
destination directory may be changed by setting the ‘ROTCTL_HIST_DIR’
environment variable.  When ‘ROTCTL_HIST_DIR’ is unset, the value of the
‘HOME’ environment variable is used instead.  Only the destination
directory may be changed at this time.

   If Readline support is not found at configure time the original
internal command handler is used.  Readline is not used for ‘rotctl’
commands entered on the command line regardless if Readline support is
built in or not.

     Note: Readline support is not included in the MS Windows 32 binary
     builds supplied by the Hamlib Project.  Running ‘rotctl’ on the MS
     Windows 32 platform in the ‘cmd’ shell does give session command
     line history, however, it is not saved to disk between sessions.

3.3 ‘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 ‘rigctl’ instance from nearly anywhere (caveat, no security is
currently provided by ‘rigctl’).  Applications using ‘rigctl’ do not
link to Hamlib nor use its C API.

3.3.1 Introduction to ‘rigctld’
-------------------------------

Multiple radios can be controlled on different TCP ports by use of
multiple ‘rigctld’ processes.  The syntax of the commands are the same
as ‘rigctl’.  It is hoped that ‘rigctld’ will be especially useful for
client authors using languages such as Perl (http://www.perl.org/),
Python (http://www.python.org/), PHP (http://php.net/), Ruby
(http://www.ruby-lang.org/en/), TCL (http://www.tcl.tk/), and others.

   ‘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 regative 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’ (rig model 2) backend.
See rigctld Default protocol.

   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.  See rigctld Extended Response protocol.

3.3.2 ‘rigctld’ invocation
--------------------------

The command line invocation for ‘rigctld’ is similar to ‘rigctl’ except
that in POSIX environments a trailing ‘&’ is appended to the command
string to “background” the ‘rigctld’ process so the shell can be used to
run other commands while ‘rigctld’ continues to run.

   Here are some examples for invoking ‘rigctld’.

   Start ‘rigctld’ for a Yaesu FT-920 using a USB-to-serial adapter and
backgrounding:

     rigctld -m 114 -r /dev/ttyUSB1 &

   Start ‘rigctld’ for a Yaesu FT-920 using a USB to serial adapter
while setting baud rate and stop bits, and backgrounding:

     rigctld -m 114 -r /dev/ttyUSB1 -s 4800 -C stop_bits=2 &

   Start ‘rigctld’ for an Elecraft K3 using ‘COM2’ on MS Windows:

     rigctld -m 229 -r COM2 -T 127.0.0.1 -t 4532

     Note: On MS Windows the use of the ‘-T’ and ‘-t’ options appear to
     be necessary to set the IP address and TCP port or else the network
     socket cannot be found.  On POSIX systems the ‘rigctld’ default
     values will be used.

   Connect to the already running ‘rigctld’, and set current frequency
to 14.266 MHz with a 1 second read timeout using the default protocol
from the shell prompt:

     echo "\set_freq 14266000" | nc -w 1 localhost 4532

   Connect to a running ‘rigctld’ with ‘rigctl’ on the local host:

     rigctl -m2

3.3.3 ‘rigctld’ command line options
------------------------------------

Many of the ‘rigctld’ command line options are shared with ‘rigctl’ with
a few additions.

   ‘rigctld’ accepts the following options:

‘-m’
‘--model=ID’
     Select radio model number.  See model list (use ‘rigctld -l’).

‘-r’
‘--rig-file=DEVICE’
     Use DEVICE as the file name of the port the radio is connected.
     Often a serial port, but could be a USB to serial adapter.
     Typically ‘/dev/ttyS0’ , ‘/dev/ttyS1’ , ‘/dev/ttyUSB0’ , etc. on
     Linux or ‘COM1’ , ‘COM2’ , etc. on MS Windows.

‘-p’
‘--ptt-file=DEVICE’
     Use DEVICE as the file name of the Push-To-Talk device using a
     device file as described above.

‘-d’
‘--dcd-file=DEVICE’
     Use DEVICE as the file name of the Data Carrier Detect device using
     a device file as described above.

‘-P’
‘--ptt-type=TYPE’
     Use TYPE of Push-To-Talk device.  Supported types are ‘RIG’, ‘DTR’,
     ‘RTS’, ‘PARALLEL’, ‘NONE’, overriding PTT type defined in the rig’s
     backend.

     Some side effects of this command are that when type is set to
     ‘DTR’, read PTT state comes from Hamlib frontend, not read from the
     radio.  When set to ‘NONE’, PTT state cannot be read or set even if
     rig backend supports reading/setting PTT status from the rig.

‘-D’
‘--dcd-type=TYPE’
     Use TYPE of Data Carrier Detect device.  Supported types are ‘RIG’
     (CAT command), ‘DSR’, ‘CTS’, ‘CD’, ‘PARALLEL’, ‘NONE’.

‘-s’
‘--serial-speed=BAUD’
     Set serial speed to BAUD rate.  Uses *maximum* serial speed from
     rig backend capabilities (set by ‘-m’ above) as the default.

‘-c’
‘--civaddr=ID’
     Use ID as the CI-V address to communicate with the rig.  Only
     useful for Icom radios and those using the Icom protocol.

     *N.B.* The ID is in decimal notation, unless prefixed by ‘0x’, in
     which case it is a hexadecimal value.

‘-T’
‘--listen-addr=IPADDR’
     Use IPADDR as the listening IP address.  The default is ANY.

     *N.B.* On MS Windows setting a specific IP address is likely
     necessary.

‘-t’
‘--port=NUMBER’
     Use NUMBER as the TCP listening port.  The default is ‘4532’.

     *N.B.* As ‘rotctld’’s default port is ‘4533’, it is advisable to
     use even numbered ports for ‘rigctld’, e.g.  ‘4532’, ‘4534’,
     ‘4536’, etc.

‘-L’
‘--show-conf’
     List all config parameters for the radio defined with ‘-m’ above.

‘-C’
‘--set-conf=PARM=VAL[,PARM=VAL,…]’
     Set config parameter.  e.g. ‘stop_bits=2’

     Use ‘-L’ option for a list.

‘-l’
‘--list’
     List all model numbers defined in Hamlib and exit.  As of 1.2.15.1
     the list is sorted by model number.

     *N.B.* In Linux the list can be scrolled back using
     ‘<SHIFT>-PageUp’/ ‘<SHIFT>-PageDown’, or using the scrollbars of a
     virtual terminal in X or the ‘cmd’ window in MS Windows.  The
     output can be piped to ’‘more’’ or ’‘less’’, e.g. ’‘rigctl -l |
     more’’.

‘-u’
‘--dump-caps’
     Dump capabilities for the radio defined with ‘-m’ above and exit.

‘-o’
‘--vfo’
     Set vfo mode, requiring an extra VFO argument in front of each
     appropriate command (except ‘set_vfo’!).  Otherwise, ‘currVFO’ is
     assumed when this option is not set and an extra VFO argument is
     not used.  See ‘chk_vfo’ below.

‘-v’
‘--verbose’
     Set verbose mode level, cumulative i.e. ‘-vvvvv’ sets maximum
     debugging output to ‘stderr’.

     Five different levels of diagnostics can be output to ‘stderr’ and
     correspond to ‘-v’ for ‘BUG’, ‘-vv’ for ‘ERR’, ‘-vvv’ for ‘WARN’,
     ‘-vvvv’ for ‘VERBOSE’, or ‘-vvvvv’ for ‘TRACE’.  Back end authors
     will use the verbose facility to print critical values useful for
     testing and will often ask for this output in response to a request
     for help.

‘-h’
‘--help’
     Show summary of these options and exit.

‘-V’
‘--version’
     Show version of ‘rigctl’ and exit.

     Note: Some options may not be implemented by a given backend and
     will return an error.  This is most likely to occur with the
     ‘--set-conf’ and ‘--show-conf’ options.

3.3.4 ‘rigctld’ commands
------------------------

Commands can be sent over the TCP socket either as a single char, or as
a long command name plus the value(s) space separated on one ‘\n’
terminated line.  See rigctld protocol.

   Since most of the Hamlib operations have a “set” and a “get” method,
in general an upper case letter will be used for set methods whereas the
corresponding lower case letter refers to the get method.  Each
operation also has a long name; in interactive mode, prepend a backslash
‘\’ to enter a long command name.

   Example (Perl):

     print $socket "\\dump_caps\n";

to see what the radio’s backend can do.

     N.B.: In Perl and many other languages a ‘\’ will need to be
     escaped with a preceding ‘\’ so that even though two backslash
     characters appear in the code, only one will be passed to
     ‘rigctld’.  This is a possible bug, so beware!

   Be aware that the backend for the radio to be controlled, or the
radio itself may not support some commands.  In that case, the operation
will fail with a Hamlib error message.

   Here is a summary of the supported commands:

   • Command short name is followed by the long name which is followed
     by any variable names.

   • Some short commands are noted as hexadecimal digits due to the
     limitation of upper and lower case letters available.  Use the
     associated long command name instead.

   • While a comma is used to separate variable names in this document,
     they are not part of the command syntax used by ‘rigctl’.  Use a
     space to separate values.

   • In the case of “set” commands the variable NAME is replaced by the
     value in the description.

   • In the case of “get” commands the variable NAME is the key name of
     the value returned.

‘F, set_freq FREQUENCY’
     Set FREQUENCY, in Hertz.

‘f, get_freq’
     Get FREQUENCY, in Hertz.

‘M, set_mode MODE, PASSBAND’
     Set MODE to one of: ‘USB’, ‘LSB’, ‘CW’, ‘CWR’, ‘RTTY’, ‘RTTYR’,
     ‘AM’, ‘FM’, ‘WFM’, ‘AMS’, ‘PKTLSB’, ‘PKTUSB’, ‘PKTFM’, ‘ECSSUSB’,
     ‘ECSSLSB’, ‘FAX’, ‘SAM’, ‘SAL’, ‘SAH’, ‘DSB’.

     Set PASSBAND frequency in Hertz, or ‘0’ for the Hamlib backend
     default.

     *N.B.* Passing a ‘?’ (query) as the first argument instead of MODE
     will return a space separated list of radio backend supported
     Modes.  Use this to determine the supported Modes of a given radio
     backend.

‘m, get_mode’
     Get MODE, PASSBAND.

     Returns Mode as a string from ‘set_mode’ above and Passband
     frequency in Hertz.

‘V, set_vfo VFO’
     Set VFO to one of: ‘VFOA’, ‘VFOB’, ‘VFOC’, ‘currVFO’, ‘VFO’, ‘MEM’,
     ‘Main’, ‘Sub’, ‘TX’, ‘RX’.

     In VFO mode only a single VFO parameter is required.

‘v, get_vfo’
     Get current VFO.

     Returns VFO as a string from ‘set_vfo’ above.

‘J, set_rit RIT’
     Set RIT, in Hertz, can be a positive or negative value.

     A value of ‘0’ resets RIT and _should_ turn RIT off.  If not, file
     a bug report against the Hamlib backend.

     *N.B.* This functionality is under transition and in the future
     will need to be activated with the ‘set_func’ command.

‘j, get_rit’
     Get RIT, in Hertz.

‘Z, set_xit XIT’
     Set XIT, in Hertz, can be a positive or negative value.

     A value of ‘0’ resets XIT and _should_ turn XIT off.  If not, file
     a bug report against the Hamlib backend.

     *N.B.* This functionality is under transition and in the future
     will need to be activated with the ‘set_func’ command.

‘z, get_xit’
     Get XIT, in Hertz.

‘T, set_ptt PTT’
     Set PTT to one of: ‘0’ (RX), ‘1’ (TX), ‘2’ (TX mic), ‘3’ (TX data).

‘t, get_ptt’
     Get PTT status.

‘0x8b, get_dcd’
     Get DCD (squelch) status, ‘0’ (Closed) or ‘1’ (Open)

‘R, set_rptr_shift RPTR SHIFT’
     Set RPTR SHIFT: ‘+’, ‘-’ or something else for none.

‘r, get_rptr_shift’
     Get RPTR SHIFT.  Returns ‘+’, ‘-’ or ‘None’.

‘O, set_rptr_offs RPTR OFFSET’
     Set RPTR OFFSET, in Hertz.

‘o, get_rptr_offs’
     Get RPTR OFFSET, in Hertz.

‘C, set_ctcss_tone CTCSS TONE’
     Set CTCSS TONE, in tenths of Hertz.

     CTCSS, Continuous Tone Coded Squelch System
     (http://en.wikipedia.org/wiki/Continuous_Tone-Coded_Squelch_System),
     is a method used to reduce the annoyance of listening to other
     users on a shared two-way communications radio channel by imposing
     a tone on the transmitted signal.  Also known as "subaudible tone"
     and PL, "Private Line".

‘c, get_ctcss_tone’
     Get CTCSS TONE, in tenths of Hertz.

‘D, set_dcs_code DCS CODE’
     Set DCS CODE.

     DCS, Digital-Coded Squelch
     (http://en.wikipedia.org/wiki/Digital-Coded_Squelch#DCS) is a
     digital version of CTCSS which imposes a digital code on the
     transmitted signal.

‘d, get_dcs_code’
     Get DCS CODE.

‘0x90, set_ctcss_sql CTCSS SQL’
     Set CTCSS SQL tone, in tenths of Hertz.

‘0x91, get_ctcss_sql’
     Get CTCSS SQL tone, in tenths of Hertz.

‘0x92, set_dcs_sql DCS SQL’
     Set DCS SQL code.

‘0x93, get_dcs_sql’
     Get DCS SQL code.

‘I, set_split_freq TX FREQUENCY’
     Set TX FREQUENCY, in Hertz for “split” frequency operation.

‘i, get_split_freq’
     Get TX FREQUENCY, in Hertz for “split” frequency operation.

‘X, set_split_mode TX MODE, TX PASSBAND’
     Set TX MODE to one of: ‘AM’, ‘FM’, ‘CW’, ‘CWR’, ‘USB’, ‘LSB’,
     ‘RTTY’, ‘RTTYR’, ‘WFM’, ‘AMS’, ‘PKTLSB’, ‘PKTUSB’, ‘PKTFM’,
     ‘ECSSUSB’, ‘ECSSLSB’, ‘FAX’, ‘SAM’, ‘SAL’, ‘SAH’, ‘DSB’.

     The TX PASSBAND is the exact passband frequency in Hertz, or ‘0’
     for the Hamlib backend default.

     *N.B.* Passing a ‘?’ (query) as the first argument instead of TX
     MODE will return a space separated list of radio backend supported
     TX Modes.  Use this to determine the supported TX Modes of a given
     radio backend.

‘x, get_split_mode’
     Get TX MODE, TX PASSBAND.

     Returns TX mode as a string from ‘set_split_mode’ above and TX
     passband in Hz.

‘S, set_split_vfo SPLIT, TX VFO’
     Set SPLIT mode, ‘0’ (off) or ‘1’ (on), and TX VFO from ‘set_vfo’
     above.

‘s, get_split_vfo’
     Get SPLIT mode, ‘0’ (off) or ‘1’ (on), and TX VFO.

‘N, set_ts TUNING STEP’
     Set TUNING STEP, in Hertz.

‘n, get_ts’
     Get TUNING STEP, in Hertz.

‘U, set_func FUNC, FUNC STATUS’
     Set FUNC, FUNC STATUS.

     FUNC is one of: ‘FAGC’, ‘NB’, ‘COMP’, ‘VOX’, ‘TONE’, ‘TSQL’,
     ‘SBKIN’, ‘FBKIN’, ‘ANF’, ‘NR’, ‘AIP’, ‘APF’, ‘MON’, ‘MN’, ‘RF’,
     ‘ARO’, ‘LOCK’, ‘MUTE’, ‘VSC’, ‘REV’, ‘SQL’, ‘ABM’, ‘BC’, ‘MBC’,
     ‘RIT’, ‘AFC’, ‘SATMODE’, ‘SCOPE’, ‘RESUME’, ‘TBURST’, ‘TUNER’,
     ‘XIT’.

     Func Status argument is ‘1’ for “activate”, ‘0’ for “de-activate”,
     much as TRUE/FALSE definitions in the C/C++ languages (true is
     non-zero and false is zero).

     *N.B.* Passing a ‘?’ (query) as the first argument instead of FUNC
     will return a space separated list of radio backend supported “set”
     functions.  Use this to determine the supported functions of a
     given radio backend.

‘u, get_func FUNC’
     Get FUNC STATUS.

     Returns FUNC STATUS as a non null value for the FUNC passed.  FUNC
     is a token from the list in ‘set_func’ above.

     *N.B.* Passing a ‘?’ (query) as the first argument instead of FUNC
     will return a space separated list of radio backend supported “get”
     functions.  Use this to determine the supported functions of a
     given radio backend.

‘L, set_level LEVEL, LEVEL VALUE’
     Set LEVEL, LEVEL VALUE.

     LEVEL is one of: ‘PREAMP’, ‘ATT’, ‘VOX’, ‘AF’, ‘RF’, ‘SQL’, ‘IF’,
     ‘APF’, ‘NR’, ‘PBT_IN’, ‘PBT_OUT’, ‘CWPITCH’, ‘RFPOWER’, ‘MICGAIN’,
     ‘KEYSPD’, ‘NOTCHF’, ‘COMP’, ‘AGC’(‘0’:OFF, ‘1’:SUPERFAST, ‘2’:FAST,
     ‘3’:SLOW, ‘4’:USER, ‘5’:MEDIUM, ‘6’:AUTO), ‘BKINDL’, ‘BAL’,
     ‘METER’, ‘VOXGAIN’, ‘ANTIVOX’, ‘SLOPE_LOW’, ‘SLOPE_HIGH’, ‘RAWSTR’,
     ‘SWR’, ‘ALC’, ‘STRENGTH’.

     The LEVEL VALUE can be a float or an integer.

     *N.B.* Passing a ‘?’ (query) as the first argument instead of LEVEL
     will return a space separated list of radio backend supported “set”
     levels.  Use this to determine the supported levels of a given
     radio backend.

‘l, get_level LEVEL’
     Get LEVEL VALUE.

     Returns LEVEL VALUE as a float or integer for the LEVEL passed.
     LEVEL is a token from the list in ‘set_level’ above.

     *N.B.* Passing a ‘?’ (query) as the first argument instead of LEVEL
     will return a space separated list of radio backend supported “get”
     levels.  Use this to determine the supported levels of a given
     radio backend.

‘P, set_parm PARM, PARM VALUE’
     Set PARM, PARM VALUE

     PARM is one of: ‘ANN’, ‘APO’, ‘BACKLIGHT’, ‘BEEP’, ‘TIME’, ‘BAT’,
     ‘KEYLIGHT’.

     *N.B.* Passing a ‘?’ (query) as the first argument instead of PARM
     will return a space separated list of radio backend supported “set”
     parameters.  Use this to determine the supported parameters of a
     given radio backend.

‘p, get_parm PARM’
     Get PARM VALUE.

     Returns PARM VALUE as a float or integer for the PARM passed.  PARM
     is a token from the list in ‘set_parm’ above.

     *N.B.* Passing a ‘?’ (query) as the first argument instead of PARM
     will return a space separated list of radio backend supported “get”
     parameters.  Use this to determine the supported parameters of a
     given radio backend.

‘B, set_bank BANK’
     Set BANK.  Sets the current memory bank number.

‘E, set_mem MEMORY#’
     Set MEMORY# channel number.

‘e, get_mem’
     Get MEMORY# channel number.

‘G, vfo_op MEM/VFO OP’
     Perform MEM/VFO OP.

     MEM/VFO OPeration is one of: ‘CPY’, ‘XCHG’, ‘FROM_VFO’, ‘TO_VFO’,
     ‘MCL’, ‘UP’, ‘DOWN’, ‘BAND_UP’, ‘BAND_DOWN’, ‘LEFT’, ‘RIGHT’,
     ‘TUNE’, ‘TOGGLE’.

     *N.B.* Passing a ‘?’ (query) as the first argument instead of
     MEM/VFO OP will return a space separated list of radio backend
     supported “set” Mem/VFO Ops.  Use this to determine the supported
     Mem/VFO Ops of a given radio backend.

‘g, scan SCAN FCT, SCAN CHANNEL’
     Perform SCAN FCT SCAN CHANNEL.

     Scan function/channel is one of: ‘STOP’, ‘MEM’, ‘SLCT’, ‘PRIO’,
     ‘PROG’, ‘DELTA’, ‘VFO’, ‘PLT’.

     *N.B.* Passing a ‘?’ (query) as the first argument instead of SCAN
     FCT will return a space separated list of radio backend supported
     Scan Functions.  Use this to determine the supported Scan Functions
     of a given radio backend.

‘H, set_channel CHANNEL’
     Set memory CHANNEL data.  Not implemented yet.

‘h, get_channel’
     Get memory CHANNEL data.  Not implemented yet.

‘A, set_trn TRANSCEIVE’
     Set TRANSCEIVE mode (reporting event): ‘OFF’, ‘RIG’, ‘POLL’.

     *N.B.* Passing a ‘?’ (query) as the first argument instead of
     TRANSCEIVE will return a space separated list of radio backend
     supported Scan Transceive modes.  Use this to determine the
     supported Transceive modes of a given radio backend.

‘a, get_trn’
     Get TRANSCEIVE mode (reporting event) as in ‘set_trn’ above.

‘Y, set_ant ANTENNA’
     Set ANTENNA number (‘0’, ‘1’, ‘2’, …).

‘y, get_ant’
     Get ANTENNA number (‘0’, ‘1’, ‘2’, …).

‘*, reset RESET’
     Perform rig RESET.

     ‘0’ = None, ‘1’ = Software reset, ‘2’ = VFO reset, ‘4’ = Memory
     Clear reset, ‘8’ = Master reset.  Since these values are defined as
     a bitmask in ‘rig.h’, it should be possible to ‘AND’ these values
     together to do multiple resets at once, if the backend supports it
     or supports a reset action via rig control at all.

‘b, send_morse MORSE’
     Send MORSE symbols.

‘0x87, set_powerstat POWER STATUS’
     Set power On/Off/Standby POWER STATUS.

     ‘0’ = Power Off, ‘1’ = Power On, ‘2’ = Power Standby.  Defined as a
     bitmask in ‘rig.h’.

‘0x88, get_powerstat’
     Get power On/Off/Standby POWER STATUS as in ‘set_powerstat’ above.

‘0x89, send_dtmf DIGITS’
     Set DTMF DIGITS.

‘0x8a, recv_dtmf’
     Get DTMF DIGITS.

‘_, get_info’
     Get misc information about the rig

     VFO parameter not used in ’VFO mode’.

‘1, dump_caps’
     Not a real rig remote command, it just dumps capabilities, i.e.
     what the backend knows about this model, and what it can do.

     TODO: Ensure this is in a consistent format so it can be read into
     a hash, dictionary, etc.  Bug reports requested.

     *N.B.* This command will produce many lines of output so be very
     careful if using a fixed length array!  For example, running this
     command against the Dummy backend results in over 5kB of text
     output.

     VFO parameter not used in ’VFO mode’.

‘2, power2mW POWER 0.0..1.0, FREQUENCY, MODE’
     Returns POWER MW

     Converts a POWER value in a range of ‘0.0..1.0’ to the real
     transmit power in milli-Watts (integer).  The FREQUENCY and MODE
     also need to be provided as output power may vary according to
     these values.

     VFO parameter not used in ’VFO mode’.

‘4, mW2power POWER MW, FREQUENCY, MODE’
     Returns POWER 0.0..1.0

     Converts the real transmit power in milli-Watts (integer) to a
     POWER value in a range of ‘[0.0..1.0]’.  The FREQUENCY and MODE
     also need to be provided as output power may vary according to
     these values.

     VFO parameter not used in ’VFO mode’.

‘w, send_cmd CMD’
     Send raw command string to rig.  This is useful for testing and
     troubleshooting rig commands and responses when developing a
     backend.

     For binary protocols enter values as ‘\0xAA\0xBB’.  Expect a REPLY
     from the rig which will likely be a binary block or an ASCII string
     depending on the rig’s protocol (see your radio’s computer control
     documentation).

     The command terminator, set by the ‘--send-cmd-term’ option above,
     will terminate each command string sent to the radio.  This
     character should not be a part of the input string.

‘chk_vfo’
     Returns ‘CHKVFO 1’ (single line only) if rigctld was invoked with
     the ‘-o’ or ‘--vfo’ option, ‘CHKVFO 0’ if not.

3.3.5 ‘rigctld’ protocol
------------------------

Two protocols exist for communicating with ‘rigctld’.  The “Default”
protocol is primarily used internally by Hamlib so an application that
is not written to use ‘rigctld’ directly via TCP network sockets can
still access ‘rigctld’.  The other “Extended Response Protocol” is
intended for the more general use case where a variety of response
formats may be needed.

3.3.5.1 ‘rigctld’ Default protocol
..................................

The ‘rigctld’ protocol is intentionally simple.  Commands are entered on
a single line with any needed values.  In Perl, for exampl, reliable
results are obtained by terminating each command string with a newline
character, ‘\n’.

Example ‘set’ (Perl code):

     print $socket "F 14250000\n";
     print $socket "\\set_mode LSB 2400\n";   # escape leading '\'

A one line response will be sent as a reply to ‘set’ commands, ‘RPRT
x\n’ where ‘x’ is the Hamlib error code with ‘0’ indicating success of
the command.

Responses from ‘rigctld’ get commands are text values and match the same
tokens used in the ‘set’ commands.  Each value is returned on its own
line.  On error the string ‘RPRT x\n’ is returned where ‘x’ is the
Hamlib error code.

Example ‘get’ (Perl code):

     print $socket "f\n";
     "14250000\n"

Most ‘get’ functions return one to three values.  A notable exception is
the ‘dump_caps’ command which returns many lines of ‘key:value’ pairs.

   This protocol is primarily used by the ‘NET rigctl’ (‘rigctl’ model
2) backend which allows applications already written for Hamlib’s C API
to take advantage of ‘rigctld’ without the need of rewriting application
code.  An application’s user can select rig model 2 (‘NET rigctl’) and
then set ‘rig_pathname’ to ‘localhost:4532’ or other network host:port
(set by the ‘-t’ option above).

3.3.5.2 ‘rigctld’ Extended Response Protocol
............................................

An EXPERIMENTAL Extended Response protocol has been introduced into
‘rigctld’ as of February 16, 2010.  This protocol adds several rules to
the strings returned by ‘rigctld’ and adds a rule for the command
syntax.

  1. The command received by ‘rigctld’ is echoed with its long command
     name followed by the value(s) (if any) received from the client
     terminated by the specified response separator as the record line
     of the response.

  2. The last line of each block is the string ‘RPRT x\n’ where ‘x’ is
     the numeric return value of the Hamlib backend function that was
     called by the command.

  3. Any records consisting of data values returned by the rig backend
     are prepended by a string immediately followed by a colon then a
     space and then the value terminated by the response separator.
     e.g.  ‘Frequency: 14250000\n’ when the command was prepended by
     ‘+’.

  4. All commands received will be acknowledged by ‘rigctld’ with lines
     from rules 1 and 2.  Lines from rule 3 are only returned when data
     values must be returned to the client.

   An example response to a ‘+\set_mode’ command sent from the shell
prompt (note the prepended ‘+’):

     echo "+M USB 2400" | nc -w 1 localhost 4532
     set_mode: USB 2400
     RPRT 0

   In this case the long command name and values are returned on the
first line and the second line contains the end of block marker and the
numeric rig backend return value indicating success.

   An example response to a ‘\get_mode’ query:

     echo "+\get_mode" | nc -w 1 localhost 4532
     get_mode:
     Mode: USB
     Passband: 2400
     RPRT 0

   In this case, as no value is passed to ‘rigctld’, the first line
consists only of the long command name.  The final line shows that the
command was processed successfully by the rig backend.

   Invoking the Extended Response protocol requires prepending a command
with a punctuation character.  As shown in the examples above,
prepending a ’‘+’ character to the command results in the responses
being separated by a newline character (‘\n’).  Any other punctuation
character recognized by the C ‘ispunct()’ function except ‘\’, ‘?’, or
‘_’ will cause that character to become the response separator and the
entire response will be on one line.

   Separator character summary:

‘+’
     Each record of the response is appended with a newline (‘\n’).

‘;, |, or ,’
     Each record of the response is appended by the given character
     resulting in entire response on one line.

     Common record separators for text representations of spreadsheet
     data, etc.

‘?’
     Reserved for ’help’ in ‘rigctl’ short command.

‘_’
     Reserved for ‘\get_info’ in ‘rigctl’ short command.

‘#’
     Reserved for comments when reading a command file script.

   Other punctuation characters have not been tested!  Use at your own
risk.

   For example, invoking a ‘;\get_mode’ query with a leading ‘;’
returns:

     get_mode:;Mode: USB;Passband: 2400;RPRT 0

   Or, using the vertical bar (pipe) character ‘|’ returns:

     get_mode:|Mode: USB|Passband: 2400|RPRT 0

   And a ‘\set_mode’ command prepended with a ‘|’ returns:

     set_mode: USB 2400|RPRT 0

   Such a format will allow reading a response as a single event using a
preferred response separator.  Other punctuation characters have not
been tested!

3.4 ‘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 ‘rotctl’ instance from nearly anywhere (caveat, no security is
currently provided by ‘rotctl’).  Applications using ‘rotctl’ do not
link to Hamlib nor use its C API.

3.4.1 Introduction to ‘rotctld’
-------------------------------

‘rotctld’ communicates to a client through a TCP 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 error code.  Commands that do not return values respond
with the line ‘RPRT x’, where ‘x’ is zero when successful, otherwise is
a regative number indicating the 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.  See rotctld Default protocol.

   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.  See rotctld Extended Response protocol.

3.4.2 ‘rotctld’ invocation
--------------------------

The command line invocation for ‘rotctld’ is similar to ‘rotctl’ except
that in POSIX environments a trailing ‘&’ is appended to the command
string to “background” the ‘rotctld’ process so the shell can be used to
run other commands while ‘rotctld’ continues to run.

   Here are some examples for invoking ‘rotctld’.

   Start ‘rotctld’ for a Ham IV rotor with the RotorEZ installed using a
USB-to-serial adapter and backgrounding:

     rotctld -m 401 -r /dev/ttyUSB1 &

   Start ‘rotctld’ for RotorEZ using ‘COM2’ on MS Windows:

     rotctl -m 401 -r COM2 -T 127.0.0.1 -t 4533

     Note: On MS Windows the use of the ‘-T’ and ‘-t’ options appear to
     be necessary to set the IP address and TCP port or else the network
     socket cannot be found.  On POSIX systems the ‘rotctld’ default
     values will be used.

   Connect to the already running rotctld, and set position to 135.0
degrees azimuth and 30.0 degrees elevation with a 1 second read timeout
from the shell prompt:

     echo "\set_pos 135.0 30.0" | nc -w 1 localhost 4533

   Connect to a running ‘rotctld’ with ‘rotctl’ on the local host:

     rotctl -m2

3.4.3 ‘rotctld’ command line options
------------------------------------

Many of the ‘rotctld’ command line options are shared with ‘rotctl’ with
a few additions.

   ‘rotctld’ accepts the following options:

‘-m’
‘--model=ID’
     Select rotator model number.  See model list (use ‘rotctl -l’).

     *N.B.* ‘rotctl’ (or third party software) will use rotor model 2
     for NET rotctl (‘rotctld’).

‘-r’
‘--rig-file=DEVICE’
     Use DEVICE as the file name of the port the rotor is connected.
     Often a serial port, but could be a USB to serial adapter.
     Typically ‘/dev/ttyS0’ , ‘/dev/ttyS1’ , ‘/dev/ttyUSB0’ , etc. on
     Linux or ‘COM1’ , ‘COM2’ , etc. on MS Windows.

‘-s’
‘--serial-speed=BAUD’
     Set serial speed to BAUD rate.  Uses *maximum* serial speed from
     rotor backend capabilities as the default.

‘-T’
‘--listen-addr=IPADDR’
     Use IPADDR as the listening IP address.  The default is ANY.

     *N.B.* On MS Windows setting a specific IP address is likely
     necessary.

‘-t’
‘--port=NUMBER’
     Use NUMBER as the TCP listening port.  The default is ‘4533’.

     *N.B.* As ‘rigctld’’s default port is ‘4532’, it is advisable to
     use odd numbered ports for ‘rotctld’, e.g.  ‘4533’, ‘4535’, ‘4537’,
     etc.

‘-L’
‘--show-conf’
     List all config parameters for the rotor defined with ‘-m’ above.

‘-C’
‘--set-conf=PARM=VAL[,PARM=VAL,…]’
     Set config parameter.  e.g. ‘stop_bits=2’

     Use ‘-L’ option for a list.

‘-l’
‘--list’
     List all model numbers defined in Hamlib and exit.  As of 1.2.15.1
     the list is sorted by model number.

     *N.B.* In Linux the list can be scrolled back using
     ‘<SHIFT>-PageUp’/ ‘<SHIFT>-PageDown’, or using the scrollbars of a
     virtual terminal in X or the ‘cmd’ window in MS Windows.  The
     output can be piped to ’‘more’’ or ’‘less’’, e.g. ’‘rotctl -l |
     more’’.

‘-u’
‘--dump-caps’
     Dump capabilities for the rotor defined with ‘-m’ above and exit.

‘-v’
‘--verbose’
     Set verbose mode level, cumulative i.e. ‘-vvvvv’ sets maximum
     debugging output to ‘stderr’.

     Five different levels of diagnostics can be output to ‘stderr’ and
     correspond to ‘-v’ for ‘BUG’, ‘-vv’ for ‘ERR’, ‘-vvv’ for ‘WARN’,
     ‘-vvvv’ for ‘VERBOSE’, or ‘-vvvvv’ for ‘TRACE’.  Back end authors
     will use the verbose facility to print critical values useful for
     testing and will often ask for this output in response to a request
     for help.

‘-h’
‘--help’
     Show summary of these options and exit.

‘-V’
‘--version’
     Show version of ‘rotctl’ and exit.

     Note: Some options may not be implemented by a given backend and
     will return an error.  This is most likely to occur with the
     ‘--set-conf’ and ‘--show-conf’ options.

3.4.4 ‘rotctld’ commands
------------------------

Commands can be sent over the TCP socket either as a single char, or as
a long command name plus the value(s) space separated on one ‘\n’
terminated line.  See rotctld protocol.

   Since most of the Hamlib operations have a “set” and a “get” method,
in general an upper case letter will be used for set methods whereas the
corresponding lower case letter refers to the get method.  Each
operation also has a long name; in interactive mode, prepend a backslash
‘\’ to enter a long command name.

   Example (Perl):

     print $socket "\\dump_caps\n";

to see what the rotor’s backend can do.

     N.B.: In Perl and many other languages a ‘\’ will need to be
     escaped with a preceding ‘\’ so that even though two backslash
     characters appear in the code, only one will be passed to
     ‘rotctld’.  This is a possible bug, so beware!

   Be aware that the backend for the rotor to be controlled, or the
rotor itself may not support some commands.  In that case, the operation
will fail with a Hamlib error message.

   *Rotor commands*

   Here is a summary of the supported commands:

        • Command short name is followed by the long name which is
          followed by any variable names.

        • While a comma is used to separate variable names in this
          document, they are not part of the command syntax used by
          ‘rotctl’.  Use a space to separate values.

        • In the case of “set” commands the variable NAME is replaced by
          the value in the description.

        • In the case of “get” commands the variable NAME is the key
          name of the value returned.

‘P, set_pos AZIMUTH, ELEVATION’
     Set position: AZIMUTH and ELEVATION as double precision floating
     point values.

‘p, get_pos’
     Get position: AZIMUTH and ELEVATION as double precision floating
     point values.

‘M, move DIRECTION, SPEED’
     Move the rotator in a specific direction at the given rate.

     Values are integers where DIRECTION is defined as ‘2’ = Up, ‘4’ =
     Down, ‘8’ = Left, and ‘16’ = Right.  SPEED is an integer between
     ‘1’ and ‘100’.

     *N.B.* Not all backends that implement the move command use the
     Speed value.  At this time only the gs232a utilizes the Speed
     parameter.

‘S, stop’
     Stop the rotator.

‘K, park’
     Park the antenna.

‘C, set_conf TOKEN, VALUE’
     Set a configuration parameter.  It is safe to give TOKEN a value of
     ‘0’ (zero).  VALUE may be a string up to 20 characters.

     See ‘-L’ output.

‘R, reset RESET’
     Reset the rotator.

     Integer value of ‘1’ for Reset All.

‘_, get_info’
     Get misc information on the rotator.

     At the moment returns MODEL NAME.

‘w, send_cmd CMD’
     Send raw command string to the rotator.

     ‘<CR>’ (or ‘send-cmd-term’, see ‘-t’ option) is appended
     automatically at the end of the command for text protocols.  For
     binary protocols, enter values as ‘\0xAA\0xBB’.

   *Locator Commands*

   These commands offer conversions of Degrees Minutes Seconds to other
formats, Maidenhead square locator conversions and distance and azimuth
conversions.

‘L, lonlat2loc LONGITUDE, LATITUDE, LOC LEN 2..12’
     Returns the Maidenhead locator for the given LONGITUDE and
     LATITUDE.

     Both are floating point values.  The precision of the returned
     square is controlled by LOC LEN which should be an even numbered
     integer value between ‘2’ and ‘12’.

     For example, ‘+L -170.000000 -85.000000 12\n’ returns ‘Locator:
     AA55AA00AA00\n’.

‘l, loc2lonlat LOCATOR’
     Returns LONGITUDE and LATITUDE in decimal degrees at the
     approximate center of the requested grid square (despite the use of
     double precision variables internally, some rounding error occurs).
     West longitude is expressed as a negative value.  South latitude is
     expressed as a negative value.  Locator can be from 2 to 12
     characters in length.

     For example, ‘+l AA55AA00AA00’ returns ‘Longitude:
     -169.999983\nLatitude: -84.999991\n’.

‘D, dms2dec DEGREES, MINUTES, SECONDS, S/W’
     Returns DEC DEGREES, a signed floating point value.

     DEGREES and MINUTES are integer values and SECONDS is a floating
     point value.  S/W is a flag with ‘1’ indicating South latitude or
     West longitude and ‘0’ North or East (the flag is needed as
     computers don’t recognize a signed zero even though only the
     DEGREES value only is typically signed in DMS notation).

‘d, dec2dms DEC DEGREES’
     Returns DEGREES, MINUTES, SECONDS, S/W.

     Values are as in ‘dms2dec’ above.

‘E, dmmm2dec DEGREES, DEC MINUTES, S/W’
     Returns DEC DEGREES, a signed floating point value.

     DEGREES is an integer value and MINUTES is a floating point value.
     S/W is a flag with ‘1’ indicating South latitude or West longitude
     and ‘0’ North or East (the flag is needed as computers don’t
     recognize a signed zero even though only the DEGREES value only is
     typically signed in DMS notation).

‘e, dec2dmmm DEC DEG’
     Returns DEGREES, MINUTES, S/W.

     Values are as in ‘dmmm2dec’ above.

‘B, qrb LON 1, LAT 1, LON 2, LAT 2’
     Returns DISTANCE and AZIMUTH where DISTANCE is in km and AZIMUTH is
     in degrees.

     All LON/LAT values are signed floating point numbers.

‘A, a_sp2a_lp SHORT PATH DEG’
     Returns LONG PATH DEG or ‘-RIG_EINVAL’ upon input error.

     Both are floating point values within the range ‘0.00’ to 360.00.

‘a, d_sp2d_lp SHORT PATH KM’
     Returns LONG PATH KM.

     Both are floating point values.

3.4.5 ‘rotctld’ protocol
------------------------

Two protocols exist for communicating with ‘rotctld’.  The “Default”
protocol is primarily used internally by Hamlib so an application that
is not written to use ‘rotctld’ directly via TCP network sockets can
still access ‘rotctld’.  The other “Extended Response Protocol” is
intended for the more general use case where a variety of response
formats may be needed.

3.4.5.1 ‘rotctld’ Default protocol
..................................

The ‘rotctld’ protocol is intentionally simple.  Commands are entered on
a single line with any needed values.  In Perl, for exampl, reliable
results are obtained by terminating each command string with a newline
character, ‘\n’.

Example ‘set’ (Perl code):

     print $socket "P 135 10\n";
     print $socket "\\set_pos 135 10\n";   # escape leading '\'

A one line response will be sent as a reply to ‘set’ commands, ‘RPRT
x\n’ where ‘x’ is the Hamlib error code with ‘0’ indicating success of
the command.

Responses from ‘rotctld’ get commands are text values and match the same
tokens used in the ‘set’ commands.  Each value is returned on its own
line.  On error the string ‘RPRT x\n’ is returned where ‘x’ is the
Hamlib error code.

Example ‘get’ (Perl code):

     print $socket "p\n";
     "135"
     "10"

Most ‘get’ functions return one to four values.  A notable exception is
the ‘dump_caps’ command which returns many lines of ‘key:value’ pairs.

   This protocol is primarily used by the ‘NET rotctl’ (‘rotctl’ model
2) backend which allows applications already written for Hamlib’s C API
to take advantage of ‘rotctld’ without the need of rewriting application
code.  An application’s user can select rotor model 2 (‘NET rotctl’) and
then set ‘rig_pathname’ to ‘localhost:4533’ or other network host:port
(set by the ‘-t’ option above).

3.4.5.2 ‘rotctld’ Extended Response Protocol
............................................

An EXPERIMENTAL Extended Response protocol has been introduced into
‘rotctld’ as of February 10, 2010.  This protocol adds several rules to
the strings returned by ‘rotctld’ and adds a rule for the command
syntax.

  1. The command received by ‘rotctld’ is echoed with its long command
     name followed by the value(s) (if any) received from the client
     terminated by the specified response separator as the record line
     of the response.

  2. The last line of each block is the string ‘RPRT x\n’ where ‘x’ is
     the numeric return value of the Hamlib backend function that was
     called by the command.

  3. Any records consisting of data values returned by the rotor backend
     are prepended by a string immediately followed by a colon then a
     space and then the value terminated by the response separator.
     e.g.  ‘Azimuth: 90.000000\n’ when the command was prepended by ‘+’.

  4. All commands received will be acknowledged by ‘rotctld’ with lines
     from rules 1 and 2.  Lines from rule 3 are only returned when data
     values must be returned to the client.

   An example response to a ‘+P’ command sent from the shell prompt
(note the prepended ‘+’):

     echo "+P 90 45" | nc -w 1 localhost 4533
     set_pos: 90 45
     RPRT 0

   In this case the long command name and values are returned on the
first line and the second line contains the end of block marker and the
numeric rotor backend return value indicating success.

   An example response to a ‘+\get_pos’ query:

     echo "+\get_pos" | nc -w 1 localhost 4533
     get_pos:
     Azimuth: 90.000000
     Elevation: 45.000000
     RPRT 0

   In this case, as no value is passed to ‘rotctld’, the first line
consists only of the long command name.  The final line shows that the
command was processed successfully by the rig backend.

   Invoking the Extended Response protocol requires prepending a command
with a punctuation character.  As shown in the examples above,
prepending a ’‘+’ character to the command results in the responses
being separated by a newline character (‘\n’).  Any other punctuation
character recognized by the C ‘ispunct()’ function except ‘\’, ‘?’, or
‘_’ will cause that character to become the response separator and the
entire response will be on one line.

   Separator character summary:

‘+’
     Each record of the response is appended with a newline (‘\n’).

‘;, |, or ,’
     Each record of the response is appended by the given character
     resulting in entire response on one line.

     Common record separators for text representations of spreadsheet
     data, etc.

‘?’
     Reserved for ’help’ in ‘rotctl’ short command.

‘_’
     Reserved for ‘\get_info’ in ‘rotctl’ short command.

‘#’
     Reserved for comments when reading a command file script.

   Other punctuation characters have not been tested!  Use at your own
risk.

   For example, invoking a ‘;\get_pos’ query with a leading ‘;’ returns:

     get_pos:;Azimuth: 90.000000;Elevation: 45.000000;RPRT 0

   Or, using the vertical bar (pipe) character ‘|’ returns:

     get_pos:|Azimuth: 90.000000|Elevation: 45.000000|RPRT 0

   And a ‘\set_pos’ command prepended with a ‘|’ returns:

     set_pos: 135 22.5|RPRT 0

   Such a format will allow reading a response as a single event using a
preferred response separator.  Other punctuation characters have not
been tested!

   All commands with the exception of ‘\set_conf’ have been tested with
the Extended Response protocol and the included ‘testrotctld.pl’ script.

Appendix A GNU Free Documentation License
*****************************************

                     Version 1.3, 3 November 2008

     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.

  0. PREAMBLE

     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.

  1. APPLICABILITY AND DEFINITIONS

     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.

  2. VERBATIM COPYING

     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.

  3. COPYING IN QUANTITY

     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.

  4. MODIFICATIONS

     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:

       A. Use in the Title Page (and on the covers, if any) a title
          distinct from that of the Document, and from those of previous
          versions (which should, if there were any, be listed in the
          History section of the Document).  You may use the same title
          as a previous version if the original publisher of that
          version gives permission.

       B. List on the Title Page, as authors, one or more persons or
          entities responsible for authorship of the modifications in
          the Modified Version, together with at least five of the
          principal authors of the Document (all of its principal
          authors, if it has fewer than five), unless they release you
          from this requirement.

       C. State on the Title page the name of the publisher of the
          Modified Version, as the publisher.

       D. Preserve all the copyright notices of the Document.

       E. Add an appropriate copyright notice for your modifications
          adjacent to the other copyright notices.

       F. Include, immediately after the copyright notices, a license
          notice giving the public permission to use the Modified
          Version under the terms of this License, in the form shown in
          the Addendum below.

       G. Preserve in that license notice the full lists of Invariant
          Sections and required Cover Texts given in the Document’s
          license notice.

       H. Include an unaltered copy of this License.

       I. Preserve the section Entitled “History”, Preserve its Title,
          and add to it an item stating at least the title, year, new
          authors, and publisher of the Modified Version as given on the
          Title Page.  If there is no section Entitled “History” in the
          Document, create one stating the title, year, authors, and
          publisher of the Document as given on its Title Page, then add
          an item describing the Modified Version as stated in the
          previous sentence.

       J. Preserve the network location, if any, given in the Document
          for public access to a Transparent copy of the Document, and
          likewise the network locations given in the Document for
          previous versions it was based on.  These may be placed in the
          “History” section.  You may omit a network location for a work
          that was published at least four years before the Document
          itself, or if the original publisher of the version it refers
          to gives permission.

       K. For any section Entitled “Acknowledgements” or “Dedications”,
          Preserve the Title of the section, and preserve in the section
          all the substance and tone of each of the contributor
          acknowledgements and/or dedications given therein.

       L. Preserve all the Invariant Sections of the Document, unaltered
          in their text and in their titles.  Section numbers or the
          equivalent are not considered part of the section titles.

       M. Delete any section Entitled “Endorsements”.  Such a section
          may not be included in the Modified Version.

       N. Do not retitle any existing section to be Entitled
          “Endorsements” or to conflict in title with any Invariant
          Section.

       O. Preserve any Warranty Disclaimers.

     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.

  5. COMBINING DOCUMENTS

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

  6. COLLECTIONS OF DOCUMENTS

     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.

  7. AGGREGATION WITH INDEPENDENT WORKS

     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.

  8. TRANSLATION

     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.

  9. TERMINATION

     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.

  10. FUTURE REVISIONS OF THIS LICENSE

     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.

  11. RELICENSING

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

ADDENDUM: How to use this License for your documents
====================================================

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.

Appendix B Working with Git
***************************

Git offers a myriad of commands and options.  Fortunately, only a few
are needed for Hamlib development.

List of Figures
***************