Ham Radio Control Libraries 3.0

Copying and Redistribution
1 Hamlib in a Nutshell
2 Getting started
3 Utility programs reference
Appendix A GNU Free Documentation License
Appendix B Working with Git
List of Figures
Concept Index

Ham Radio Control Libraries

This manual is for Ham Radio Control Libraries (Hamlib) (version 3.0, 19 September 2015).

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 at the Hamlib project page and the Hamlib Wiki.

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

For source code management, the project uses Git, a fast, distributed content tracker. Among its features is that every developer has the complete Hamlib development history available locally. 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 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. 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, 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 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 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. 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.

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

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.

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 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.ins throughout the directory structure, and the final Makefiles 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 Makefiles 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 Makefiles, run make distclean from the top-level directory. After this target is run, configure will need to be run again to regenerate the Makefiles. This command may not be as useful as the Makefiles do not take up much space.

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 Makefiles 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. README.build-win32 in the scripts directory has details on how this is accomplished.

Work is ongoing to correct build issues in the Cygwin environment running on MS Windows.

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

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

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

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

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, Python, PHP, Ruby, TCL, 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

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

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

-u

--dump-caps

Dump capabilities for the radio defined with -m above and exit.

-o

--vfo

-v

--verbose

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

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

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

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

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.

L, set_level Level, Level Value

Set Level, Level Value.

The Level Value can be a float or an integer.

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.

P, set_parm Parm, Parm Value

Set Parm, Parm Value

Parm is one of: ANN, APO, BACKLIGHT, BEEP, TIME, BAT, KEYLIGHT.

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.

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.

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.

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.

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.

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.

VFO parameter not used in ’VFO mode’.

2, power2mW Power 0.0..1.0, Frequency, Mode

Returns Power mW

VFO parameter not used in ’VFO mode’.

4, mW2power Power mW, Frequency, Mode

Returns Power 0.0..1.0

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.

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.

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

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

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

-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

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.

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.

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.

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

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.

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.
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.
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.
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.
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:
1. 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.
2. 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.
3. State on the Title page the name of the publisher of the Modified Version, as the publisher.
4. Preserve all the copyright notices of the Document.
5. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices.
6. 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.
7. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document’s license notice.
8. Include an unaltered copy of this License.
9. 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.
10. 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.
11. 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.
12. 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.
13. Delete any section Entitled “Endorsements”. Such a section may not be included in the Modified Version.
14. Do not retitle any existing section to be Entitled “Endorsements” or to conflict in title with any Invariant Section.
15. 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.
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.”
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.
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.
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.
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.
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.
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

Figure 1.1: Hamlib design

Concept Index

Jump to:	A B C D E F G H I L M N O P R S V

	Index Entry	Section

A
	Adding debugging symbols:	Adding debugging symbols
	Applications, using Hamlib:	Applications using Hamlib

B
	Back end library:	Overview
	Binary packages, Linux, BSD:	Unix binary packages
	Bootstrapping from a Git clone:	Bootstrapping from a Git clone
	BSD binary packages:	Unix binary packages
	Build, parallel trees:	Parallel build trees
	Building from source:	Building from source

C
	Cloning, radio:	Radio cloning
	Command line options, `rigctl`:	rigctl command line options
	Command line options, `rigctld`:	rigctld command line options
	Command line options, `rotctl`:	rotctl command line options
	Command line options, `rotctld`:	rotctld command line options
	commands, `rigctl`:	rigctl commands
	commands, `rigctld`:	rigctld commands
	commands, `rotctl`:	rotctl commands
	commands, `rotctld`:	rotctld commands
	Compiling for MS Windows 32:	Compiling MS Windows 32
	Compiling source tarballs:	Compiling source tarballs
	configure:	configure
	Copying, redistribution:	Copying and Redistribution
	Copyleft:	Copying and Redistribution

D
	Daemon, network:	Overview
	Default protocol, `rigctld`:	rigctld Default protocol
	Default protocol, `rotctld`:	rotctld Default protocol

E
	Extended Response Protocol, `rigctld`:	rigctld Extended Response protocol
	Extended Response Protocol, `rotctld`:	rotctld Extended Response protocol

F
	Front end library:	Overview

G
	Getting released source:	Source releases
	Getting source snapshots:	Source snapshots
	Git clone:	Git clone
	Git clone, bootsrapping:	Bootstrapping from a Git clone
	Git repository:	Git clone

H
	Hamlib applications:	Applications using Hamlib
	Hamlib licensing:	Licensing implications
	Hamlib project:	The Hamlib project
	Hamlib, pronouncing:	Pronunciation

I
	Interface, languages:	Overview
	Introduction to `rigctl`:	Introduction to rigctl
	Introduction to `rigctld`:	Introduction to rigctld
	Introduction to `rotctl`:	Introduction to rotctl
	Introduction to `rotctld`:	Introduction to rotctld
	invocation, `rigctl`:	rigctl invocation
	invocation, `rigctld`:	rigctld invocation
	invocation, `rotctl`:	rotctl invocation
	invocation, `rotctld`:	rotctld invocation

L
	Languages, scripting:	Overview
	ldconfig:	ldconfig
	Licensing, Hamlib:	Licensing implications
	Linux binary packages:	Unix binary packages

M
	make:	make
	make install:	make install
	`make`, other targets:	Other make targets
	MS Windows 32, compiled binaries:	MS Windows 32 binaries
	MS Windows 32, compiling:	Compiling MS Windows 32
	MS Windows 32, pre-compiled binaries:	MS Windows 32 binaries

N
	Network, daemon:	Overview
	NO WARRANTY:	Copying and Redistribution
	Nutshell:	Hamlib in a Nutshell

O
	Other `make` targets:	Other make targets
	Overview:	Overview

P
	Parallel build trees:	Parallel build trees
	Pre-compiled binaries for MS Windows 32:	MS Windows 32 binaries
	Project, Hamlib:	The Hamlib project
	Pronouncing Hamlib:	Pronunciation
	protocol, `rigctld`:	rigctld protocol
	protocol, `rotctld`:	rotctld protocol

R
	Radio cloning:	Radio cloning
	Readline support, `rigctl`:	rigctl readline support
	Readline support, `rotctl`:	rotctl readline support
	Redistribution, copying:	Copying and Redistribution
	rigctl:	rigctl
	`rigctl` command line options:	rigctl command line options
	`rigctl` commands:	rigctl commands
	`rigctl` invocation:	rigctl invocation
	`rigctl` Readline support:	rigctl readline support
	`rigctl`, introduction to:	Introduction to rigctl
	rigctld:	rigctld
	`rigctld` command line options:	rigctld command line options
	`rigctld` commands:	rigctld commands
	`rigctld` Default protocol:	rigctld Default protocol
	`rigctld` Extended Response Protocol:	rigctld Extended Response protocol
	`rigctld` invocation:	rigctld invocation
	`rigctld` protocol:	rigctld protocol
	`rigctld`, introduction to:	Introduction to rigctld
	rotctl:	rotctl
	`rotctl` command line options:	rotctl command line options
	`rotctl` commands:	rotctl commands
	`rotctl` invocation:	rotctl invocation
	`rotctl` Readline support:	rotctl readline support
	`rotctl`, introduction to:	Introduction to rotctl
	rotctld:	rotctld
	`rotctld` command line options:	rotctld command line options
	`rotctld` commands:	rotctld commands
	`rotctld` Default protocol:	rotctld Default protocol
	`rotctld` Extended Response Protocol:	rotctld Extended Response protocol
	`rotctld` invocation:	rotctld invocation
	`rotctld` protocol:	rotctld protocol
	`rotctld`, introduction to:	Introduction to rotctld

S
	Scripting languages:	Overview
	Source options:	Source options
	Source tarballs, compiling:	Compiling source tarballs
	Source, building from:	Building from source
	Source, daily snapshots:	Source snapshots
	Source, getting released:	Source releases
	Source, getting snapshots:	Source snapshots
	Source, obtaining releases:	Source releases
	Source, obtaining snapshots:	Source snapshots

V
	Virtual radio:	Overview
	Virtual rotor:	Overview

Jump to:	A B C D E F G H I L M N O P R S V

Ham Radio Control Libraries 3.0

Table of Contents

Ham Radio Control Libraries

Copying and Redistribution

1 Hamlib in a Nutshell

1.1 A view from the top of the tower

1.2 Hamlib project information

1.3 Applications using Hamlib

1.4 Using Hamlib with your program

1.5 Radios with a clone capability

1.6 Pronouncing Hamlib

2 Getting started

2.1 Installing binary packages on Linux and BSD

2.2 A variety of Hamlib sources

2.2.1 Getting released source

2.2.2 Getting source snapshots

2.2.3 Git repository

2.3 Building from source

2.3.1 Compiling source tarballs

2.3.1.1 configure

2.3.1.2 make

2.3.1.3 make install

2.3.1.4 ldconfig

2.3.2 Bootstrapping from a git clone

2.3.3 Other make targets

2.3.4 Parallel build trees

2.3.5 Adding debugging symbols

2.3.6 Compiling for MS Windows 32 bit architectures

2.4 Pre-compiled binaries for MS Windows 32 bit architectures

3 Utility programs reference

3.1 rigctl

3.1.1 Introduction to rigctl

3.1.2 rigctl invocation

3.1.3 rigctl command line options

3.1.4 rigctl commands

3.1.5 rigctl Readline support

3.2 rotctl

3.2.1 Introduction to rotctl

3.2.2 rotctl invocation

3.2.3 rotctl command line options

3.2.4 rotctl commands

3.2.5 rotctl Readline support

3.3 rigctld

3.3.1 Introduction to rigctld

3.3.2 rigctld invocation

3.3.3 rigctld command line options

3.3.4 rigctld commands

3.3.5 rigctld protocol

3.3.5.1 rigctld Default protocol

3.3.5.2 rigctld Extended Response Protocol

3.4 rotctld

3.4.1 Introduction to rotctld

3.4.2 rotctld invocation

3.4.3 rotctld command line options

3.4.4 rotctld commands

3.4.5 rotctld protocol

3.4.5.1 rotctld Default protocol

3.4.5.2 rotctld Extended Response Protocol

Appendix A GNU Free Documentation License

ADDENDUM: How to use this License for your documents

Appendix B Working with Git

List of Figures

Concept Index

2.3.1.1 `configure`

2.3.1.2 `make`

2.3.1.3 `make install`

2.3.1.4 `ldconfig`

2.3.2 Bootstrapping from a `git clone`

2.3.3 Other `make` targets

3.1 `rigctl`

3.1.1 Introduction to `rigctl`

3.1.2 `rigctl` invocation

3.1.3 `rigctl` command line options

3.1.4 `rigctl` commands

3.1.5 `rigctl` Readline support

3.2 `rotctl`

3.2.1 Introduction to `rotctl`

3.2.2 `rotctl` invocation

3.2.3 `rotctl` command line options

3.2.4 `rotctl` commands

3.2.5 `rotctl` Readline support

3.3 `rigctld`

3.3.1 Introduction to `rigctld`

3.3.2 `rigctld` invocation

3.3.3 `rigctld` command line options

3.3.4 `rigctld` commands

3.3.5 `rigctld` protocol

3.3.5.1 `rigctld` Default protocol

3.3.5.2 `rigctld` Extended Response Protocol

3.4 `rotctld`

3.4.1 Introduction to `rotctld`

3.4.2 `rotctld` invocation

3.4.3 `rotctld` command line options

3.4.4 `rotctld` commands

3.4.5 `rotctld` protocol

3.4.5.1 `rotctld` Default protocol

3.4.5.2 `rotctld` Extended Response Protocol