Where’s The Code?
Right here: https://codeberg.org/jcw2112/KC8JCLogger/
Everything you need to know to run the software should be there. Good luck and shout if it works!
How Did I Get Here?
Every project, no matter how silly, has a starting point. This one started in the dreary December of 2024. The weather was even worse than normal for Northeast Ohio with low temperatures, rain, and wind. Honestly, it’s the wind that gets me now. Sitting outside in the cold with my radio and tapping away on my paddles when the gusts are going is not a whole lot of fun. And sitting in a vehicle might work for some, but I really don’t enjoy it at all. My Jeep is not really a great place to sit and unwind with my hobby. And so I found myself hanging out in my shack at home more. I started sitting on the other side of the POTA QSO as a Hunter.
Side Note…
Someone pointed out that some of the jargon we use in radio doesn’t sound fun or isn’t very inviting to the uninitiated and I think there’s something to that. Being a “Hunter” and “Working” an “Activator” sounds kinda strange and doesn’t really get across the simple message that I’m going to the park and talking to other people for the sake of being outside and maybe seeing how well the radiowaves are moving in a given moment. That said, I still fall into the common terminology of the activity.
For the sake of clarity, here are a few terms of art. An Activator is a ham radio operator who is taking their radio to the park and trying to make contacts. The people on the other end sitting at home (usually) are called Hunters. When an Activator is at a park on the air it is called Activating The Park. It becomes an Activation when 10 contacts are completed. Simple rules for a simple on the air activity.
With that out of the way, we’ll get back to my project.
Hunting
One of the ways that a Hunter can take some of the guesswork out of this activity is to monitor the POTA.app site which has listings of activations that are currently ongoing. These listings are called Spots. Spotting and self-spotting are quite common. It’s an easy way for an Activator to say “I’m on the air! Come talk to me! Please hurry it’s January and I’m really cold!” In fact, a Hunter can look at the listing, decide what mode they want to chase and on what bands and dial in to where the action is. The POTA.app site is quite full-featured and is a great application.
But…
When I was starting off on my CW journey, I hacked together a little Python script that would pull spots from a publicly available API and play the callsigns and states of the activators at a given speed. The toolkit for generating Morse from text was really easy to use and I got to learn how to call APIs and wrangle data in Python. It was pretty cool and took all of about 20 minutes to have something that worked. I kept that script around and I still use it for practice. It occured to me that I could use the script to dump the current Activators and their parks to a terminal and even filter it by mode or band if I just tweaked the script a little.
After a little poking around, I was able to get a listing of all activations by mode and/or band and put them into formatted output. I would grab a listing, spin the dial on my radio and try to make a contact. Of course, once I had that running in one terminal window, I opened rigctl in another and started copying and pasting the frequency of the activation into the other window to kick my rig to the right spot. That was fun! But I could surely do better than that, right? Why not pipe the output straight to rigctl? It’s a simple problem and it had to have a simple solution. At the time I was willing to bet it would take 10 minutes tops.
How many projects have started because someone wanted to do Just This One Thing?
Scope Creep
I’ve done product management for a while and I know how this goes. Someone gets an idea for a feature and it all falls apart from there. For this project it started when I wanted to format the output to the terminal and I discovered the Rich module. I could turn my data into neat little tables and with a few more turns of the screw, I could make it interactive complete with formatting input and catching some errors and…
Then I found Textual. That’s a module that is Rich’s big brother (or evolved from it…I’m not quite sure). The elements in Textual let me put together some modal dialog boxes and even a DataTable that could hold all of the activations. Buttons were rendered. Key bindings written. Errors were trapped. A UI came into being that was reminiscent of the old DOS days so I painted it blue and white and used buttons with rounded corners. Every time I turned around, I added a new feature. The only thing left was to take it to its logical conclusion…
Another Logging Program? No One Asked For That.
Look. I was already listing the activations and, upon selecting one with the keyboard or mouse from the DataTable, updating the settings on my rig (frequency and mode!). It was 15 minutes of effort to craft a modal dialog box to capture RST and a comment. If I made a config file and filled it with my Callsign and other details, I’d have all of the data I needed for a proper QSO log. And Python dictionaries are easy to write to JSON objects and…
I can feel the judgement of 90% of those reading this. I was weak. I couldn’t help myself. I structured configration files and built a UI to either create one if it didn’t exist or update one if it did. And yes, I started using tinyDB because it was super simple and I’m talking about logging a couple dozen QSOs, right? Once it’s gone that far, you have to admit that just generating an ADIF file would cap it off and that couldn’t take too much effort.
What Is This Thing?
Right now, this is a terminal based POTA logging application that has interactive data collection for the QSO and rigctl functionality for aligning the radio’s settings to the selected activation. It saves these QSOs to a tinyDB database (JSON file) and can dump that out into an ADIF file on demand so that you can put it into a REAL LOGGER or push it to QRZ or LotW or updload it to POTA (if you’re an Activator).
It’s written in Python and the only real nightmare I’ve had with it is getting a version of Hamlib compliled with Python bindings. I compiled from source on my Mac to get it to work. Once I got that working reliably, everything else more or less fell into place.
So it is a VERY simple logging program aimed at POTA Hunters. But more than that, it’s an exploration of what I can do with a terminal-based UI. It’s also a nice throwback to a time when I really enjoyed playing with computers. It’s been a blast to put together.
What Is It NOT?
This probably isn’t a replacement for any existing logging software. It’s clumsy. The code is messy. It’s pretty efficient in spite of itself and it’s probably not going to win any awards for usability.
But if the white on blue screenshot with the ASCII LED style freqency and time reading grabs you, it might be fun to play with.
Support
Look, this was meant to scratch a very specific itch and I’m probably only going to update this thing when I want to build in a new feature. I’m putting it on Codeberg to share it with a couple of people who thought the screenshots I had looked cool. This isn’t a product. It’s a proper Hobby Project. There’s an issue tracker on Codeberg and I will check in on it if/when I get a system email but my support availability is certainly limited – even for myself!
