Shortcomings of the Cabrillo Ham Radio Contest Log Format

I’ve been dabbling with some of the log formats commonly used in the amateur radio world. One of those formats is the Cabrillo format. I built a parser in Go for reading Cabrillo formated contest logs, but I’m unhappy with one aspect and I think it’s a deficit in the Cabrillo specification.

If the exchange field of a QSO is supposed to contain a space between multiple pieces of information, you have to know that ahead of time otherwise you can’t properly parse the log. An example of this being problematic can be found in the logs for the North American SSB Sprint Contest where the exchange consisted of your first name and state. I generated an example log using a tool. The result is:

START-OF-LOG: 2.0
CALLSIGN: ABC123
CATEGORY: SINGLE-OP ALL LOW
CLAIMED-SCORE: 1234
CONTEST: NA-SPRINT-SSB
CREATED-BY: WA7BNM Web2Cabrillo 1.14
NAME: Jack Smith
ADDRESS: 1234 Someplace street
ADDRESS: Everytown, CA 91773
EMAIL: foo@example.com
OPERATORS: ABC123 @ABC123
SOAPBOX: blah blah blah blah blah
QSO: 14000 PH 2020-04-05 0001 AG6K        1 JACK       LOS ANGELES W1AW          1 JILL       CA
END-OF-LOG:

Where “JACK LOS ANGELES” is one set of exchange data and “JILL CA” is the other. Using the parser I wrote, you have to initialize it with the number of expected fields in the exchange data. This isn’t a problem if you’re only parsing a set of logs from one specific contest, but if you’re parsing logs from various contests each with their own exchange data, it becomes problematic.

One way to solve this would be to use a structured data format for the QSO line. Formats like JSON don’t lend themselves well to being human writeable, so we need something that’s easy to write and read for both humans and machines. I think logfmt is a good fit for this use case.

Examinging what our QSO line would look like if it were in logfmt:

QSO: freq=14000 mode=PH date=2020-04-05 time=0001 tx_call=AG6K tx_rst=59 tx_exch="JACK    LOS_ANGELES" rx_call=W1AW rx_rst=59 rx_exch="JILL       CA"

This is still very readable, easy enough to write by hand (as compared to something like JSON), and is easy to parse mechanically.

The Cabrillo specification website says to email cabrillo@wwrof.org with questions or enhancement requests, so I did. I got a response back from Randy Thompson (K5ZD):

For a contest log the sponsor does know how many columns to expect.  From a parsing perspective, you split on tab or whitespace.  Then you know what each column should have.


This method was chosen many years ago because it makes the logs human readable.  Which is still important given the variety of users that are dealing with log submissions.

Which can basically be paraphrased as won’t fix because it’s always been done this way.

It is unfortunate that it seems they’re not even open to a discussion about it. I realize this would be a backwards incompatible change forcing a new major version of the spec and there would be some pain adopting it, but I think the community would be better off for it and it might even ease the pain of other changes to the spec as it makes the QSO message format more extensible.