POTA Logging Apps: Offline Logging, ADIF Export and Uploads

An activation can be a perfect day in a park and a headache in the evening, if the log is wrong. The best POTA logging apps make the evening part trivial: they work with no cell signal, record contacts in UTC, write the park reference into every record and export a clean ADIF file that the Parks on the Air uploader accepts first time. This guide explains what a logging app must do for an activator, what the official ADIF requirements are, how to choose between paper, phone, tablet and laptop logging, how to handle club activations and park-to-park contacts and how to upload your file without errors.

Apps update often, so features change. The requirements below come from the Parks on the Air documentation and from the public pages of the apps described. Check both before your first activation.

What an Activator’s Log Must Contain

Parks on the Air tallies contacts from ADIF files, the standard interchange format that most logging programs can export. The program’s ADIF technical reference lists the minimum fields POTA needs to count your contacts properly: STATION_CALLSIGN or OPERATOR, the hunter’s CALL, QSO_DATE, TIME_ON, BAND and MODE (or SUBMODE). A few details trip people up:

• Date and time are UTC. QSO_DATE is the date the contact started, in UTC, as eight digits in year, month, day order. Future dates are rejected. TIME_ON is the start time of the contact in UTC, in four or six digits, and POTA counts a contact by when it started, not when it finished.
• Band includes the unit. A contact on 20 metres is logged as 20M, not 20.
• Callsign fields use plain characters. Letters, numbers and the slash only, with no accents.
• Mode. POTA stores a single mode field, and if both mode and submode are present, the submode takes precedence.

Beyond those basics, optional fields carry park information. MY_SIG should be POTA, and MY_SIG_INFO holds the park reference, which is the program prefix, a hyphen and a number. For a park-to-park contact, SIG is POTA and SIG_INFO holds the other activator’s park reference. MY_STATE records the state, province or similar code of the logging station, and the uploader uses it when a park spans administrative boundaries. According to the documentation, when MY_SIG and MY_SIG_INFO are missing or invalid, the uploader prompts you for the information during upload, which is a useful safety net but slower than a log that is right to begin with.

What to Look for in an App

The needs of a park activation are different from home logging. Cell coverage in a park can be poor, the screen has to be readable in sun, batteries are limited and you may be logging fast during a pileup. A good activator’s app should:

• Work offline. No signal should mean no problem. Offline park lists and callsign data are a bonus.
• Use UTC automatically. You should not have to convert time zones while you are working a pileup.
• Write the park reference for you. Selecting the park once should add the correct MY_SIG and MY_SIG_INFO to every contact.
• Support park-to-park logging. It should let you enter the other station’s park reference quickly.
• Export valid ADIF. The file must contain the required fields in the right format, with band values like 20M.
• Handle duplicates sensibly. Dupe warnings help, but a duplicate with a different band or mode is a valid contact.
• Be fast. Logging a contact should take a callsign and one or two taps.
• Back up automatically. A phone that dies at the park should not take the log with it.

Logging Methods Compared

Many activators combine methods: a phone app as the primary log and a paper sheet as a backup, or a laptop logger for FT8 and a phone for SSB. Because POTA accepts multiple ADIF files from one activation, mixing is fine. The docs recommend combining logs from the same park and station callsign into one file where practical, though it is not required, and a single file may contain several UTC days.

An Example: HAMRS

One widely used option is HAMRS, which describes itself as a simple, portable logger tailored to activities like Parks on the Air and Field Day. Its public page lists several features that match the checklist above: it works offline, with bundled offline POTA park lists and a US callsign database; it syncs across iOS, Android and desktop; it imports and exports ADIF and can upload to QRZ with one click; it offers rig control through Hamlib and FLRIG and works with WSJT-X for digital modes; it supports custom templates; and it can look up callsigns from QRZ and HamDB. More recent versions add extras such as a QSO map, band conditions, a Field Day template and a live map of POTA spots.

Treat that list as a sample of what a good app offers rather than an endorsement. Other loggers, including general-purpose desktop programs, also export valid ADIF files, and the POTA documentation includes a guide for activators who use a popular commercial logger. The test of any app is simple: log a few practice contacts, export the file and read it before you rely on the app in a park.

Phone, Tablet or Laptop?

The device matters as much as the app. A phone is the lightest option and always with you, but its screen is small, its battery drains quickly in cold or heat and a call or notification can interrupt logging. A tablet gives a bigger screen and is easier to read in sunlight with a shade, though it is one more item to carry and charge. A laptop suits digital-mode activations and longer sessions, because it runs the radio software and the logger side by side, but it needs more power and a flat place to sit.

Whichever you choose, protect the device from sun and rain, use airplane mode to save battery if the app works offline and keep a small power bank in the bag. Many activators run a pile of contacts on a phone app, then switch to a laptop for FT8 and merge the files afterwards. Other portable logging apps, such as Ham2K PoLo, are also popular with activators, so try more than one before you commit, and compare how each handles park references, duplicates and export.

Logging While Using Digital Modes

If you run FT8 or other digital modes from the park, the software that decodes the signals usually writes its own log file in ADIF format. That file may not contain the park fields POTA needs, since the digital program does not know your park reference. Two approaches work. You can enter the park information in the digital program’s station settings if it supports it, or you can import the digital log into your logging app, which adds the park fields and merges the contacts with the rest of your log. Check the result in a text editor before uploading, and remember that your file can mix modes without any problem as long as each record is complete.

Checking the ADIF Before You Upload

Open the exported file in a text editor and look at one or two records. You should see fields like these, in any order:

• STATION_CALLSIGN with your callsign, or OPERATOR for club activations;
• CALL with the hunter’s callsign;
• QSO_DATE in eight digits and TIME_ON in four or six digits, both UTC;
• BAND with the unit, such as 20M;
• MODE or SUBMODE with a valid ADIF value;
• MY_SIG as POTA and MY_SIG_INFO with your park reference;
• SIG and SIG_INFO on park-to-park contacts.

If you see a band written as a number, a date in the wrong format or a park reference missing, fix the app settings before the next activation. Some apps let you edit these defaults. If you use an ADIF converter or a spreadsheet, be careful with character encoding and date formats. Our primer on ADIF and moving your log between programs explains how the format works and how to move records without losing fields.

Club Activations and Multi-Park Days

When several operators use one club callsign, the documentation says club and group activations must use the club’s callsign in STATION_CALLSIGN and must include the OPERATOR field with the individual’s callsign. A single log file may combine all operators, or each position may produce its own file. If you visit more than one park on the same UTC day, log each park’s contacts with the right MY_SIG_INFO, and the uploader will use those fields to credit each location correctly.

Park-to-park contacts need an extra step. Ask the other activator for their park reference and enter it in SIG_INFO. The result is credit for both of you. If the other station is not an activator, leave the field blank. The Logging Made Easy guide in the official documentation covers multi-operator and multi-park situations in detail, including naming files and replacing a log if you find a mistake.

Uploading Your Log

Once you are home, submit the log. The official page on submitting logs describes two routes. The first is the My Log Uploads page of pota.app, available since July 2022, where you upload ADIF files yourself. The second, if you cannot use the uploader, is to open a help desk ticket and attach the file, following a file-naming format that includes the callsign, the park number and the activation date. When the page is not accepting your file, read the error message carefully, because it usually names the field that failed.

A few habits make uploads painless:

• Upload the same evening while the details are fresh.
• Combine files for the same park and callsign if your apps created more than one.
• Keep a copy of the original file, so you can compare it if a correction is needed.
• Do not edit ADIF files by hand unless you know what you are doing. A small mistake in a tag length can corrupt a record.

If you are planning your first activation, our beginner guide to getting started with POTA covers the programme basics, and the article on battery power options for portable ham radio helps you make sure the phone, radio and logger last the whole day.

Field Habits That Protect the Log

• Charge everything. Bring a power bank and a short cable for the phone.
• Set up the app before you leave. Enter your callsign, park and state in advance, with the right defaults for band and mode.
• Log as you go. Do not rely on memory. A paper sheet is a fine safety net during a busy run.
• Confirm the callsign. A clear check at the time saves invalid records later.
• Watch the clock. Make sure the device shows UTC or that the app converts correctly.
• Save and back up. Export the ADIF before you pack up, and keep one copy off the device.

The Bottom Line

Good POTA logging apps let you spend the day on the radio instead of the keyboard. Look for offline operation, automatic UTC time, park references on every record, easy park-to-park entry and clean ADIF export. Learn the required fields from the official reference, check your exported file once before the first activation, keep a paper backup and upload the same evening through the pota.app uploader. With a tidy log, the activation is finished when you pack the car, not after an hour of fixing records.

Frequently Asked Questions

What file format does POTA need?

POTA requires logs in ADIF format. The documentation lists the required fields and shows how the program uses them.

Can I log offline?

Yes. A paper log always works, and several apps run offline, so you can export the file and upload it when you have a connection.

Are times local or UTC?

UTC. QSO_DATE and TIME_ON must be in UTC, and POTA counts a contact by the time it started. Future dates are rejected.

How do I log a park-to-park contact?

Set SIG to POTA and enter the other activator’s park reference in SIG_INFO. Most apps provide a field for the other park.

What do I do if the uploader asks for park details?

If MY_SIG and MY_SIG_INFO are missing or invalid, the uploader prompts for them. It is better to fix the app’s settings so that every record carries them.

Can several operators share one log?

Yes, but a club callsign must be the STATION_CALLSIGN and each contact needs the OPERATOR field. Combine files from the same park and callsign if you can.