Running CHIRP on Linux

CHIRP is a fine application for programming radio memories that can be run on Linux. Getting it going involves two steps: installing the application itself, and configuring the system to give it access to the USB port that the radio is connected to. On some systems, it might also involve installing FUSE (more on that below).

CHIRP is written in the Python programming language, so it's cross-platform – and the CHIRP Web site has a page of instructions for installing and running it on Linux (Thank You!).

You'll run CHIRP as an ordinary user (not root), so it's necessary to get access to the computer's USB ports. Access to serial devices (including USB) is governed through Linux group membership. To give a user access to the port, add the username to the controlling group. On Debian-based and Fedora systems, the dialout group generally is in control, while Arch uses the uucp group. This can be done at the command line with:

sudo usermod -a -G groupName userName

where groupName will be dialout or uucp, and userName is your Linux login name.

The CHIRP instruction page shows an alternate usermod usage that sets user permissions directly on the port, not through a group. I prefer the group approach, as it doesn't require prior knowledge of which port the radio will connect to.

This is the method documented on the CHIRP Web site. The process involves installing a Python library from the Linux distribution's repository, then using pipx to install the Python scripts that comprise that application. It works, but it can be intimidating for those who aren't familiar with the command line, and tricky to troubleshoot if something doesn't work.

I used this method to install CHIRP on a system running Linux Mint 21.3, and it worked well, but I've talked to others who ran into various problems. Happily, there are other ways to install it.

An AppImage is a file that contains a Linux application and its immediate dependencies. Using an AppImage is a simple process: download it, set its permissions to be executable, and then run it. Most of the time that's all that is necessary, though it does rely on capabilities of the underlying Linux system that occassionally are absent. The fix for that is to install the missing capability on the system.

I found an AppImage for CHIRP on GitHub, and decided to test it out. I have an ancient Acer Aspire Netbook on which I recently installed DietPi, a Debian-based distro for SBCs (Single Board Computers) such as the Raspberry Pi, and also for low-resource Intel boxes like my Acer. That seemed a reasonable platform for running CHIRP, so I gave it a try with my IC-7100. Here's how that went:

1. I added my user to the dialout group with usermod, then logged out and back in to put it into effect.
2. Downloaded the AppImage. Used the graphical File Manager utility to set its executable property.
3. Plugged the 7100 into a USB port. The USB data line showed up on /dev/ttyUSB0. (Icom rigs make two USB connections, the second one being for sound, on /dev/ttyUSB1.)
4. Double-clicked on the file in the file manager and waited for it to start up.
5. It failed, with an error message indicating that CHIRP relies on FUSE being available, and it wasn't.
6. I went to the command line and used apt to install two packages: fuse and libfuse2.
7. Tried again to run the AppImage – and it worked.
8. I successfully added six repeaters to memory.

When CHIRP started up, it notified me that there is a newer version, but I couldn't update it, since it was in the AppImage. The date on the image is January 10, so it's quite recent. Hopefully the author will update it to the newer version.

There are a couple of Docker images for CHIRP on GitHub, but they both are more than five years old, so I'm going to give them a pass – though it's possible they could still work.

For users of Snap, the Snap Store has a package for CHIRP. I don't use Snaps, so I haven't tested it.