All About ADIF

Before we start, let's go back almost three centuries before radio was invented.

Indeed no man is an island, as you'll quickly learn after getting your amateur radio license. It's a rather boring hobby if you don't engage with anyone! Inevitably, you will make contact with someone, whether it's something as simple as FM voice on the 2 meter band, chatting with someone on the Worldwide talkgroup on an Internet-linked DMR hotspot, banging out Morse code, or a microwave Earth-moon-Earth moonbounce that you've carefully-arranged over the course of several weeks. Live in the moment and enjoy it!

Afterwards, though, you should log your contact. It's common courtesy. Many awards are out there ready to be claimed, from simple ones like QRZ's World Radio Friendship all the way up to prestigious ones such as the ARRL's DX Century Club. All of these awards rely on both parties submitting accurate and identical logs, resulting in a confirmed contact. Even if you think you have zero interest in awards or logging, the person on the other end of the airwaves might have just contacted a new country, province, state, county, or grid square; and your log may be exactly what they need to progress. As someone who's made unconfirmed contacts with rare tiny islands, I can't begin to tell you how much the other party's lack of logging bothers me. (Seriously, when's the next time I'll hear someone from Saint Barthelemy?)

Accurate logging also satisfies the FCC's vague requirement that all U.S. amateur stations keep a log. The chance of them coming calling is somewhere around zero (unless you're doing something dumb), but being able to hand over a proper electronic log would make the bureaucrats happy.

The Amateur Data Interchange Format (ADIF) is the standard format for general-purpose ham radio logging, so that's what this article will cover. If you take part in contests, you'll be asked to submit logs in the abbreviated Cabrillo format, but there are online tools to strip down ADIF and convert it to Cabrillo, so let's not worry about that.

Computers have long since infiltrated ham radio, for the better (despite what some curmudgeons might say). The days of a physical logbook are dead and gone; there are many apps out there designed to do the hard work for you. N1MM Logger+ seems to be popular for Windows machines. Ham2K Portable Logger lets you log on your iOS, iPadOS, or Android device on the go. For digital modes, the ubiquitous WSJT-X keeps accurate ADIF logs right out of the box.

Or, you can skip an app entirely and just punch the details into the forms in TQSL, HAMLOG, or QRZ's Logbook. By all means, if you find something you like, use it! Congratulations, you have reached the end of this article. Fire up your app and get on the air.

However, some of us out there may feel the most comfortable with a plain text editor. Maybe you find an app but it eventually becomes unmaintained, or you get sick of planned obsolesence and switch operating systems. Maybe you're like me and you believe in being in control of your own personal data, and want a vendor-neutral, interoperable, non-fungible log that you can upload or import into any site or app of your choosing. Let's face it, if even the ARRL can get hit with ransomware, it's never wise to trust a website or cloud service with the only copy of your irreplacable data.

In short, use a logging app or service if you want, but I'm still going to teach you how to write logs in the ADIF format. You never know when knowing the format will come in handy.

The ADIF format is nothing more than a series of fields, value lengths, and values. Your values contain the data about your QSO, and the field names add structure. The fields and lengths are enclosed in less-than and greater-than signs. If you've worked with HTML or XML before, this may start to make sense quickly (just forget about closing tags).

There are two ways to represent ADIF, the more common HTML-like ADI version; and a newer, strictly-XML version called ADX. We'll be studying the former, as it's vastly more popular.

When working with the ADI representation, your values have to follow the field name, but aside from that, you can add as much whitespace as you want. You can put a space before a field. You can put no space between fields. You can put an entire QSO onto one line like I normally do, but for illustrative purposes, I'll put one or two (or three) fields on a line. ADIF can be read by human eyes, but it's meant to be machine-parsed, and computers don't care if it's pretty or compact.

For example, here's a QSO I had with one of my friends not too long ago. He was using a repeater, I was using a hotspot.

Let me review each line for you:

1. In line 1, the CALL field indicates the other party's call sign. Note the :6 that indicates how long the value will be. This is easily the worst part of writing ADIF by hand. CALL is mandatory, which is good because you can't have a proper QSO with only one person.
2. Here, I have the date of the QSO. The mandatory QSO_DATE field is the date when the QSO began (in the UTC time zone, like all dates and times in ADIF). I also have the optional QSL_DATE_OFF field to denote when the QSO ended. As you can see, each date field is exactly eight characters long.
3. Likewise, the TIME_ON field indicates (in UTC) what time the QSO began and the optional TIME_OFF field shows when it ended. I included hours, minutes, and seconds because I could pull that from my hotspot's netwatch, but you're allowed to omit the seconds.
4. The STATION_CALLSIGN field is your station's callsign and the OPERATOR field is your personal callsign. These two will almost always be the same, unless you're operating a club station.
5. Next, we have the BAND field to show which band the QSO happened on. You may instead (or in addition) supply the FREQ field, which shows the transmitting frequency (in megahertz). As this QSO was through my hotspot, I included the FREQ_RX field to show that I'm receiving this on a different frequency. You need to supply either the BAND or FREQ fields. There's nothing wrong with including both.
6. The MODE and SUBMODE fields indicate which mode was used in the QSO. You need to specify at least the MODE. You'll need to check the full list of modes and submodes, unfortunately.
7. The propagation mode field, PROP_MODE, indicates how the QSO happened. Examples include meteor scatter, satellite, sporadic-E, EchoLink, or some other Internet mode. Because it was raining, I stayed inside and used my Internet-connected DMR hotspot, so I'm putting INTERNET here. Internet-enabled QSOs can't be uploaded to Logbook of the World, but hey, ADIF is about logging what really happened.
8. The RST_SENT and RST_RCVD fields are used to report signal strength. You can put any value you want here, such as 599, sounded good to me, the S-values I saw reported by my hotspot, or the WSJT-X dB values.
9. The MY_RIG field tells what kind of radio I used. The MY_ANTENNA field describes my antenna. In this case, I'm using my trusty Anytone HT with the surprisingly-low-SWR rubber duck.
10. Finally, the EOR tag is used to end your QSO record. This is one of few fields in ADIF that does not get a length value, not even a zero length.

There, now my QSO is logged! Let's try something a little more traditional next.

Let's look at a contact I made while doing Parks on the Air at Lover's Leap State Park in New Milford, Connecticut.

However, I like to add some other fields before I upload my QSO to the various logging platforms. You never know which fields they'll show in their UI now or in the future. Plus, it makes your offline log more complete. (Quick, how many lifetime QSOs have you had with South Dakota on 20 meters? If your logs have all the fields, it's easier to search.)

That's a lot, so let's cover them:

1. The CQZ and MY_CQ_ZONE fields show the other party's CQ zone and your CQ zone, respectively. CQ zones are an arbitrary way to divide the world into contactable sections. Collect them all to win the Worked All Zones award.
2. The ITUZ and MY_ITU_ZONE fields show the other party's ITU zones and your ITU zone, respectively. ITU zones are yet another way to split up the world.
3. The MY_LAT and MY_LON fields may be used to show your station's location. You can be as exact or inexact as you want. I was doing Parks on the Air, so I gave the exact GPS coordinates of my parking spot. If you choose to include this, you need to use the silly DDDD MM.MMM format.
4. The QTH and MY_CITY fields identify their and your city/town/village, respectively. As with all of these pairs of their/my fields, the logging service won't pay much attention to how you describe the other station. I only add them to the QSO because who knows what I'll do with this file in the future? If you're pressed for time, supply the MY_CITY and other MY fields and let the logging service handle what the other guy or girl uploads.
5. The CNTY and MY_CNTY fields represent their and your county. Not all countries have counties, but ARRL and QRZ have awards if you contact enough United States counties. (Yes, Connecticut still reports counties, even if the state government abolished county government in 1960 as a small-government measure, and switched to planning regions in 2024.) I believe counties in the United Kingdom and Ireland use a different field.
6. The STATE and MY_STATE fields have the abbreviation for your and their state or province.
7. The DXCC and MY_DXCC fields indicate your and their country code, respectively, as defined by the ADIF specification.
8. MY_RIG is your radio. (Yes, there is a RIG field if you know what they're using. Usually, they tell you on the QSL card.)
9. MY_ANTENNA describes your antenna.
10. The QSO_COMPLETE field is a yes or no answer: was the QSO fully completed? In FT8 parlance, this is if you received their RR73 or you sent or received a 73. Everything in FT8 should be completed, so I suppose this is more helpful for phone contacts that might get cut off due to interference or weird atmospheric effects.
11. The QSO_RANDOM field is a yes or no answer: did this QSO happen randomly? FT8 is pretty random, but if you're my friend texting me for a radio check or if you're planning an EME microwave contact, this is a QSO that you were expecting. Like most of these fields, it's optional; a QSO is a QSO.
12. Now, here's one that's actually important for Parks on the Air and other "OTA" programs. the MY_SIG field identifies some kind of special-interest group, such as POTA for Parks on the Air. (Likewise, if you're spotting someone doing POTA, whether you're at a park or not, you should put <SIG:4>POTA into your log.
13. The SIG_INFO and MY_SIG_INFO expands on the above, adding more information to describe the specific thing you're doing. In the case of Parks on the Air, I would supply the code(s) of the park(s) that I am currently at; or, if I'm at home, I'll supply the other person's park code(s). I know spotters don't need to upload their logs to Parks on the Air, so I just do this to be polite. (Additionally, there are the POTA_REF and MY_POTA_REF fields for POTA specifically. I'm not sure which one is more "right", so I add them both.)
14. You can also use ADIF logs to keep track of QSL cards that you send or receive. The QSL_SENT field tracks whether a card was sent, not sent, or is queued. The QSL_SENT_VIA field lets you say if it was sent directly, via the bureau, or electronically. Finally, the QSLSDATE field lets you specify when you sent the card. There are both defined and non-defined separate fields to keep track of received QSLs, sent and received electronic QSLs, Logbook of the World entries, QRZ logbook entries, and so on that you can explore to your heart's content. In this case, I sent my contact a nice card after the fact. I hope he sends me one back!

There are many more fields that are defined in the ADIF specification (version 3.1.6 as of the time of this writing). In addition, ADIF lets you use the USERDEF field to create your own fields as well. Now that you have your logs not only created but chock full of wonderful entries, you're on your way to winning awards, helping others win awards, documenting your QSL's, or just plain keeping track of what you do in the hobby.

It's worth noting that there are many defined and custom fields to keep track of whether your partner has logged the QSO as well. Some examples include LOTW_QSL_SENT and LOTW_QSL_RCVD for Logbook of the World and APP_QRZLOG_STATUS for QRZ.com, to name a few.

If anyone wants to practice logging, then I'll give you some practice myself! Look for me, W1DNS. If we're close, bring your radios and we'll do some varied simplex QSO's on various bands and modes. Otherwise, seek me out on the various Connecticut Brandmeister or NEDECN talkgroups. We'll have a chat and then we'll make sure it all gets logged properly.