KC8JCRigctl

What Is This Thing?

KC8JCRigctl is a terminal front end for rigctld, the Hamlib daemon that stands between your computer and your radio. It does the fiddly part: pick your rig from the list of every model your Hamlib build knows about, pick the USB serial device it is plugged into, set a port and a baud rate if the defaults are not right, and press Connect. You don't have to remember anything and that's really why I made it. That and device handles suck.

It is written in Python with Textual, the same as the KC8JCLogger, so it is the same white-on-blue terminal UI that reminds me of the better days of an internet limited to the BBS that I'd get to in PROCOMM.

Where's The Code?

Right here: kc8jcrigctl-0.1.1-py3-none-any.whl
With a hash here: SHA256SUMS
and install instructions here: INSTALL.txt

Keeping it as simple as I can, if you have pipx:

pipx install https://www.kc8jc.com/kc8jcrigctl/kc8jcrigctl-0.1.1-py3-none-any.whl

One file and that's it. It pulls its two Python dependencies from PyPI and puts a kc8jcrigctl command on your PATH.

You Need Hamlib First

This is the one thing that might trip you up, so it is worth saying out loud: Hamlib is not installed by the above and cannot be. rigctl and rigctld are native programs that come from your operating system, not from Python. On a Mac that is brew install hamlib. On Debian or Ubuntu it is apt install libhamlib-utils. Otherwise see hamlib.github.io. The program looks for those two binaries on your PATH when it starts and will tell you if they are not there. If they're not there, you're probably not interested in this software anyway.

Tricky Linux Nonsense Alert! On Linux that I know about, serial devices belong to the dialout group, and if your user is not in it, rigctld cannot open the radio. The failure looks exactly like a wrong baud rate, which is a miserable thing to debug. Fix it with:

sudo usermod -aG dialout $USER

...and then log out and back in, because a group change does not apply to the session you typed it in. Ask me how I know.

What It Actually Does

Type in the filter box to find the rig list by manufacturer, model, or numeric ID - Hamlib knows about a most radios and scrolling the whole list sucks. Arrow through the rig table and the device table to pick each one. The device path also lands in a free-text field, so you can type something by hand: a host:port for Hamlib's NET rigctl backend, or a device that did not get detected.

Press Connect, or c. Press it again to stop. r refreshes the rig list, u refreshes the USB devices, q quits and shuts rigctld down on the way out.

Honestly? It's the listing of USB devices that made me put this together in the first place. It's worth the price of admission not to have to update my scripts when stuff changes (and it always changes and different OS versions make different things difficult for new and exciting reasons).

While it is connected the tables are replaced with a read-only summary of what is in use, and rigctld's own output is tailed live in a pane underneath, so when something goes wrong you are looking at what the daemon actually said rather than hoping it was logged somewhere (it wasn't).

Your last rig, device, port and baud rate are saved to ~/.config/kc8jcrigctl/config.json and come back the next time you start it. Most people use one radio.

The Part That's Kinda Cool

Connecting is not reported as successful until rigctld has actually answered a get_freq on its TCP port.

This isn't me just being weird. A rigctld that cannot reach the indicated radio still starts and still listens. It accepts a client, spends ten or more seconds failing to open the rig, and then hangs up without replying. Every client in the world reports that as an i/o timeout, which tells you nothing about what went wrong. So rather than lighting up a cheerful CONNECTED and letting you find out later, the app opens the port itself, asks the radio what frequency it's on, waits for a real answer, and reports what Hamlib actually said if one does not arrive. Then it shuts the daemon back down so you are not left with a half-alive process. Which also sucks.

It is a small thing. It is also the difference between "it says connected but nothing works" and "your baud rate is wrong." And I'm going to guess that I'm not the only person who has had to debug rigctld and forgot something trivial.

When It Says The Rig Didn't Answer

Much like DNS, nine times in ten it is the baud rate. The auto default does not negotiate on most backends, so it has to match whatever is set in the radio's own menu. An IC-7300's CI-V USB Baud Rate, for one personal example, is often 115200. Put that number in the Baud field and try again.

If you have several USB serial adapters plugged in, the other thing to check is that you picked the right device row. The description or the serial number usually names the radio. I ran into this when I had my 7300 and a Meshtastic node hooked up to the same Mac. Sigh.

How Did I Get Here?

KC8JCLogger talks to the radio through rigctld, which means rigctld has to be running before the logger is any use for rig control. Starting it by hand means knowing your rig's Hamlib model number and your device path and getting a longish command line right, every time, usually outdoors, generally in the cold. So: a tiny program whose entire job is to get that daemon running, and to tell you the truth about whether it worked was worth spending a couple of hours on.

The two programs are independent. You can run this one on its own with any software that speaks to rigctld, and the logger does not require this to be what started the daemon. I'm just making stuff that makes things easier for me. Maybe it makes things easier for you too!

Support

Same as everything else here: this is a Hobby Project, not a product. I wrote it because I wanted it. I will probably only touch it when I want it to do something new. Send me an email if it works, or if it doesn't, but I'll be honest and say up front that my support availability is limited - even for myself.