# Hamlib: one API for radios, rotators and amplifiers

> Hamlib is the shared C library that amateur radio applications use to control transceivers, rotators and amplifiers without each one reimplementing a manufacturer's serial protocol. It publishes a generic API in front of per-brand backends, ships language bindings for Perl, Python and TCL, and is currently split across two major versions, with the incompatible 5.x on master and the 4.7 line that applications still use.

**Hamlib/Hamlib** — Ham radio control library for rigs (radios), rotators, and amplifiers.  For daily snapshots see:

- Repository: https://github.com/Hamlib/Hamlib
- Website: https://hamlib.sourceforge.net/snapshots/
- Stars: 857 · Forks: 311
- Language: C
- License: NOASSERTION
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/hamlib-hamlib

## A shared library so that every application does not speak every protocol

Hamlib's stated purpose is to provide stable, flexible, shared libraries that enable quicker development of amateur radio equipment control applications. The copyright header shows where it came from, Frank Singleton in 2000, Stephane Fillod from 2000 to 2011, and The Hamlib Group from 2000 to 2025, so this is a project with a quarter of a century behind it.

The problem it solves is straightforward. Amateur radio transceivers come with serial, RS-232, USB, or Ethernet, WiFi and Bluetooth interfaces that allow software to control the radio, and each manufacturer speaks a different set of commands with a different set of quirks. Every application that wants to show a frequency, read a signal strength or change a power level would otherwise have to implement that protocol itself.

So the project provides shared libraries that greatly simplify the application programmer's interaction with radio equipment and other controllable devices such as rotators and amplifiers. The README also says Hamlib will enable developers to develop professional looking GUIs towards a unified control library API, and they will not have to worry about the underlying connection towards physical hardware, which is the argument for a library rather than a set of copy-pasted routines.

The repository arrangement is worth noting because it is unusual for a modern project. The master repository is on GitHub and the backup repository is on SourceForge, with daily snapshots of the master branch published on the SourceForge snapshots site, and daily snapshots of the Hamlib-4.7 branch available as a GitHub tree. Development happens on the GitHub master, often by merging feature branches, and each release has its own release branch.

The primary language is C, the default branch is master, and the last push was on 2026-10-19.

## Hamlib 5 is on master, and 4.7 is what applications use today

There is a note at the top of the README that anyone integrating with this library has to read, and it is unusually direct about a trap.

Major changes are planned for Hamlib 5, which is the current master branch, and they will introduce incompatibilities with existing software that uses Hamlib. Until a given software application announces support for Hamlib 5, use the snapshots and releases from the Hamlib-4.7 branch.

So the master branch is not the version you want. It is the development line, with a major API change in progress, and the 4.7 branch is the line that the existing applications, including the ones you are likely to interoperate with, actually use. The recent releases are 4.7.0 on 2026-02-16, 4.7.1 on 2026-04-16 and 4.7.2 on 2026-06-21, and the tree carries a ReleaseNotes_4.7.md and a ReleaseNotes_5.0.md side by side, which is a clear sign of the two lines being maintained at once.

The version numbering scheme is explained in the README and it is worth learning, because it tells you what a release will break.

Major is currently at 4, and it can be advanced when changes to the API require client programs to be rewritten to take advantage of new features. Advancing the major number signals frontend API changes that require modification of client source, and Application Binary Interface changes that require relinking to the library. There is a carve-out: the ABI part does not apply to applications using the ctld daemons, although the command API may change.

Minor advances when new backends or new rig models to existing backends are added, and it also carries bug fixes since the last point release.

Point is the bug fix and small addition counter, and it explicitly does not include new rig models or backends. When major or minor advances, point resets to zero, and the README notes that all future releases beginning with 4.7.0 will include all values to lessen confusion.

The release schedule is a philosophy rather than a calendar: a ready when it's ready approach with no set schedule, though the project would like at least one minor release in a given year.

## One library in front, one backend per manufacturer

The design section explains the layering, and it is the part you need in order to write any code against the library.

The library provides functions for radio, rotator and amplifier control, and data retrieval for supported devices. A number of functions useful for calculating distance and bearing and for grid square conversion are included, which is a small convenience that tells you the project expects to be used by logging and contesting software as well as by radio control programs.

The public surface is libhamlib.so, the library that provides a generic API for all RIG types, and this is what application programs will see. It has different names on other platforms, for example libhamlib-4.dll on Windows, and it also contains all the radio, rotator and amplifier backends provided by Hamlib.

The backends are the per-manufacturer implementations, and the README gives two examples. The yaesu backend provides connectivity to the Yaesu FT 747GX Transceiver, the FT 847 Earth Station and similar, through the unified API. The second example is a joke, a backend called xxxx that provides connectivity to the Wiz-bang moon-melter 101A, with the author's own parenthesis, yikes.

So the shape of the library is one API and many backends, and the backend is chosen at run time by naming the model. That is what makes it possible for one application to control a rig from one manufacturer and a rotator from another without knowing either protocol.

The list of what is actually supported lives in the wiki, on the Supported Radios page, which contains a snapshot of the supported radios as of the last release. That page is the thing to consult before you start, because the answer to can I control this rig with Hamlib is on it, and the answer is frequently yes and occasionally you are writing the backend yourself.

## Connectivity is still mostly a serial port

The connectivity story in the README is worth reading for its tense, because it tells you what the library was designed around and what arrived later.

It says that initially serial, RS-232, connectivity will be handled, but it expects that IP and other connectivity will follow afterwards. Connection via a USB port is accomplished via the Linux kernel support, and USB to serial converters are well supported. Other such devices may be supported as long as they present a serial, RS-232, interface to Hamlib.

That last sentence is the practical constraint for anyone adding a device. If a new rig exposes a control interface over TCP or over a vendor cloud API, it is not automatically reachable through a serial backend, and that is a real limit on what a contribution can cover.

There is also a daemon story behind the API. The version numbering notes mention the ctld daemons, and those exist because the network daemon utility is available for any programming language that supports network sockets, even netcat. The library speaks to a daemon over a socket, and the daemon speaks to the hardware, which means an application that cannot link C can still drive a radio by talking to the daemon. C++ programming is supported, and language bindings are available for Perl, Python and TCL.

The API documentation is at the wiki's Documentation page, and the tests/README file has simple programming examples and test programs, which is the fastest way to see a working program rather than reading a reference.

## Build it the way a GNU project in 2000 was built

The compiling section is short, and it describes a source tarball build with the familiar three steps:

```sh
        ./configure
        make
        sudo make install
```

Hamlib is entirely developed using GNU tools, on various operating systems, and for debugging the README gives a configure invocation that skips the actual configuration step so you can set flags and keep the existing setup:

```sh
        ./configure CFLAGS=-g -O0 -fPIC --no-create --no-recursion
```

There is one warning that saves a lot of confusion for newcomers, and it is the kind of thing that only gets written after many people hit it. To recompile Hamlib, run make clean to remove all object files and binaries, otherwise make won't do anything. An incremental build over stale objects in an autotools project is a confusing thing to debug, and the fix is one command:

```sh
        make clean
```

The tree shows the rest of the machinery. There is configure.ac with an M4 file, hamlib.m4 and a bootstrap script, the usual automake Makefile.am, and a pkg-config template, hamlib.pc.in, so a consuming project can find the library with pkg-config. There are style and analysis scripts, astyle.sh for formatting and cppcheck.sh for static analysis, a docker-build/ directory, and doc/.

The platform-specific READMEs are the other thing worth knowing about. There are README.android, README.macos, README.windows, README.freqranges, README.multicast, and others, which is a project that expects to be built on a Raspberry Pi next to the radio as well as on a desktop.

## Contributing a rig, and the non-disclosure clause that decides what can be contributed

The contributing section contains one paragraph that is worth repeating because it governs what can be written into the library at all.

Contributions of rig specifications and protocol documentation are highly encouraged, with the caveat that in some cases the manufacturer may not provide complete control information or it is only available under a Non-Disclosure Agreement. Any documentation must be publicly available so we can legally write and distribute Free Software supporting a given device.

That is a legal constraint on the project rather than a technical one, and it has a direct effect on what you can expect to find. A rig whose protocol is under an NDA cannot be supported by a library that is freely distributed, and no amount of reverse engineering effort changes that. If your rig falls in that category, the answer is that you will be maintaining the protocol yourself.

Everything else about contributing is conventional and well documented. The README points at README.betatester and README.developer in the repository for those who want to test or help with development, and there is a CODE_OF_CONDUCT.md and a CONTRIBUTING.md for the process side. Patches go to the hamlib-developer mailing list at hamlib-developer@lists.sourceforge.net, in Git email format or as a unified diff.

The project is also unusually open about how it wants to hear from users. The README says the team is very interested to hear how Hamlib builds and works on your system, especially on non-Linux systems or non-PC systems, because they try to make Hamlib as portable as possible. The tree backs that up with a security/ directory and a SECURITY.md, a Segfault-award file, THANKS, AUTHORS and a VFOs.txt, and the whole set of per-platform readme files.

The overall shape is a project that has been running for a very long time on a very wide range of hardware, and that treats documentation of the hardware as the scarce resource worth contributing.

## Conclusion

Adopt Hamlib if you are writing software that talks to a transceiver, a rotator or an amplifier, because the per-manufacturer serial protocols are exactly the work you do not want to own, and the project maintains them so that a firmware change in a rig does not become your bug. Do not build against master, because the README states that Hamlib 5 introduces incompatibilities and that applications should stay on the 4.7 snapshots and releases until they announce support. Before you start, pick your radio model and check the Supported Radios page in the wiki, because a rig that is not listed is a rig you will have to write a backend for, and check whether the manufacturer publishes its control protocol at all, because a protocol that only exists under a non-disclosure agreement cannot be implemented here.

## FAQ

### What is Hamlib used for?

It is a C library that provides functions for radio, rotator and amplifier control and data retrieval for supported devices, behind a generic API. The README also includes functions for calculating distance and bearing and for grid square conversion, and bindings for Perl, Python and TCL alongside C++ support.

### Should I build against the master branch of Hamlib?

Not yet. The README states that major changes are planned for Hamlib 5 on the current master branch, that these will introduce incompatibilities with existing software, and that until an application announces support for Hamlib 5 you should use the snapshots and releases from the Hamlib-4.7 branch.

### How do I build Hamlib from source?

Run ./configure, then make, then sudo make install. For debugging the README suggests ./configure CFLAGS=-g -O0 -fPIC --no-create --no-recursion, and to recompile you must run make clean first, otherwise make will not do anything.

### How do I know if my radio is supported by Hamlib?

The Hamlib wiki has a Supported Radios page that contains a snapshot of the supported radios as of the last release. If your model is not listed, a backend would have to be written, and the project only accepts rig specifications and protocol documentation that are publicly available rather than covered by a non-disclosure agreement.

## Sources

- [Hamlib/Hamlib on GitHub](https://github.com/Hamlib/Hamlib)
- [Issues](https://github.com/Hamlib/Hamlib/issues)
- [Project website](https://hamlib.sourceforge.net/snapshots/)
- [README](https://github.com/Hamlib/Hamlib/blob/master/README.md)
- [Releases](https://github.com/Hamlib/Hamlib/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/hamlib-hamlib