Parks on the Air® Logging Made Easy

Original author: KB2FMH

To ensure problem free processing, remember to always double check your log based on the information contained herein before uploading.

The integrity of your log is Your responsibility

Table of Contents

1. Why is logging for Parks on the Air so complicated?
2. How does an ADIF log work?
3. What is required in a POTA Log?
4. What are the other fields for?
5. One Call, Different Operators (Club activations)
6. One Park, more than one geographical location
7. What about Multi Operators that are not in a club?
8. What if we’re operating a Special Event Station (SES) from a Park?
9. Spotting an SES with multiple operators
10. How do I log a multi-park activation properly, so all credits are given?
11. Do I need to make separate files if I use different modes?
12. What’s with the file naming rules – why can’t I name it My Way?
13. Naming your files
14. What if I made a mistake, how do I replace the log file?
15. Summary
16. References

Why is logging for Parks on the Air so complicated?

That is a question often asked by both veteran and new amateur operators upon joining the program. They are accustomed to just entering a call into a computer / web based logging application and that’s it – the computer does the rest.

Well, the answer is: It isn’t complicated at all. There are some very easy to follow parameters (Rules if you like that word) that are in place to make sure every log entered goes the right way and both activators and hunters get the award credits due them.

Yes, it is an award driven program in a way so to ensure the integrity of the program certain simple rules are in place, easily found on the website, docs.pota.app. But this is about logging only so let’s go….

POTA has a log sorting system that uses the common “Amateur Data Interchange Format” (ADIF) file type which is used to exchange information between logging programs and log databases such as QRZ, eQSL, LoTW etc. It is globally uniform and simple.

For the purpose of continuity, POTA uses this format so any logging program an activator may use will be compatible with our system.

How does an ADIF log work?

Imagine a spreadsheet such as that used in software like Excel or the like; there are columns and rows.

In an ADIF file the columns are called Fields and the Rows are where the data goes. Software that reads ADIF files is designed to look for particular fields, labeled in the top row (header) of each column, then it extracts the information from those fields to essentially read the log and sort the information accordingly.

The result is what you see in your activator or hunter logs as well as your activity stats and award allocations.

What is required in a POTA Log?

POTA has just Five required data fields that Must be in your log for it to be accepted and Five secondary fields for particular situations. The fields are labeled with “Tags” as they’re called.

The five required fields are: CALL (callsign you receive) QSO_DATE, TIME_ON, MODE and BAND. These are self-explanatory. No other fields are needed but may be in it without harm.

For a simple activation by one operator in a single park this set is enough to get your log processed without issue. You still only need these five data sets, just remember to change the date and put the correct UTC time when logging or transcribing from paper!

What are the other fields for?

The first set of “optional” fields come into play if you get a call of Park to Park (P2P). Many will tell you that they aren’t needed, the system catches them automatically, and in essence it Should but, it doesn’t Always so these fields are insurance in a way, making sure the cross reference is applied. Remember, insurance never hurts to have.

These fields are MY_SIG_INFO and SIG_INFO. “SIG” meaning Special Interest Group. Your park ID: Location appropriate letter(s) (US, JP, AU, NL), a dash (-) and 4 or more numbers, is put in MY_SIG_INFO. This field is the same for Every contact whether a P2P or not. If you have no P2Ps, it is ignored but, when you get that call of “park to park” in your radio, you will put the “other” operator’s park in the field labeled SIG_INFO and together these two fields ensure your P2P is credited (as long as the other operator sends in a properly formatted log of course).

NOTE: If you receive a 2fer or 3fer P2P from the Other activator, just make additional entries in your log But, make sure to put the correct park numbers in the SIG_INFO field so the entries do not dupe.

All data can be identical, Including Time, except the park numbers. That is what will present them as unique entries to our parsing system.

One Call, Different Operators (Club activations)

The remaining pair of fields are not commonly used and often forgotten. They are STATION_CALLSIGN and OPERATOR. These are used when there are two or more calls associated with an activation.

Example:

The We Love Radio Club of Galifray activates a POTA entity for its anniversary using the club call, W1WHO, as the on air callsign. Club member N1ABC is at the mic / key. Both the club and the operator are registered with individual POTA accounts.

Since the club call is the one given on air to incoming calls / hunters, it is put in the field STATION_CALLSIGN and N1ABC is put in OPERATOR. These fields are carried through with each entry by your logging application when put in during the initial setup for that park’s specific log.

When submitted and processed, the club and the operator get credit for the activation, but hunters get credit for the actual contact with the club call only, since it was a single contact. If the operator Also gives his / her call, then a separate log must be submitted for each call.

If operators are changed during the activation the OPERATOR field must be updated with the different call when the change occurs..

One Park, more than one geographical location

If you activate a park that is in more than one state / province / territory, you should include the specific location in the file field labeled MY_STATE. This will allow our parsing algorithms to assign the credits properly for hunters WAS awards and activators trying to build their Activated States matrix there are many parks, historic trails and rivers that span multiple locations in all countries, so it is Your Job to know where you were and put it in the filename. If you Do Not include the MY_STATE field you’ll have to choose it manually when uploading your file(s).

The MY_STATE field will be parsed for any location whether a US State, Canadian Province, Australian Territory or Russian Oblast.

What about Multi Operators that are not in a club?

When two or more operators activate a park, presuming they all make the same contacts, a single log can be replicated for each and named accordingly for each callsign (more about naming later).

What if we’re operating a Special Event Station (SES) from a Park?

For SES calls, if it will be used by a Single Operator, that operator creates a secondary account under their own account, properly date limited with particular start – stop for that event. (If using a short 1x1 call, remember that those can be recycled many times so putting the specific beginning and ending dates are important for proper credit distribution) That SES Call is put in the log file field labeled Station_Callsign with the single operator’s call in the Operator field. Hunters will get the park / points from Only the SES call, which is what is given Over the Air, while the operator gets the activation and any award specific to the activation Only.

If the SES activity will have a conglomerate of operators then it must be added to a Club account, so All operators get their activation credit. Registered Clubs log files are parsed differently than personal accounts, which won’t recognize the Other calls in the Operator field and will be rejected as the other operators are not associated with the personal account.

Spotting an SES with multiple operators

When many are spotting the same call on our spotting page there must be a /X (a unique identifier) appended after the call to not have one spot bump the previous, even if different bands / modes are used. Only the SES call is given on the air though, without the /x identifier. I suggest using the band after the / such as K3Y/40 for 40 meters as an example.

Some folks will log it with the /X in their personal log but it only matters if they expect confirmations Outside of POTA. The important thing would be to make sure to tell any P2Ps to log ONLY the SES call, sans the /x, and You do the same in the event log. Hunters wil get the park regardless of They log the contact.

How do I log a multi-park activation properly, so all credits are given?

This situation is commonly referred to as 2fers, 3fers etc.. and logging is very simple for these. Create one initial log for Any of the park numbers you’re activating, it makes no difference which – just make sure it is identified in the MY_SIG_INFO field when initiating the log so it carries over to each entry. Of course, any P2Ps during this activation go in the SIG_INFO field as usual.

DO NOT USE Any other field names! We’ve seen some folks create their own field labels for P2P entries and then hammer our help desk asking Why they aren’t seeing the matches. The ONLY fields recognized for a P2P match are those described above.

When complete, open the log in any text editing software – I use Notepad in Windows or ADIF Master which is an application for reading and editing ADIF files. Find the MY_SIG_INFO field if using ADIF Master and select all cells in the column. Right click in one of the selected cells and choose Replace in Selection. It should show the park number in the find box, and you put the second (and third if needed in a sequential edit) park number in the “Replace With” box, apply the changes and click FILE > “Save As” and rename the file with the new park number (presuming you saved and correctly named the initial log).

In Notepad, which is on every Windows based computer, open the file, then EDIT > Replace, put the initial park number in the Find What box, put the other park(s) in the Replace With box and click Replace All. Close that dialog window and again, FILE > Save As, changing the park number in the filename accordingly. For MAC / Apple users, the equivalent application is called simply “TextEdit”

NOTE: Always make sure there is a DASH (-) between the location identifier and the numbers in the Park ID.

If you forget and just have for example K1234, the file will be rejected. This goes for Your park and the P2P parks as described above.

Do I need to make separate files if I use different modes?

Absolutely not. Whether you operated with all SSB or a mix of SSB, CW, AM, FT4/8, Satellite and PSK31 (or Any mode you like) you only make One file for a given park. If you mix modes during an activation and use WSJT-X, just import those entries into your adi file before uploading.

As long as you enter the data accordingly for each mode, our system will sort it out during processing – we’re That good!

What’s with the file naming rules – why can’t I name it My Way?

Before we launched the Self-Uploader feature we had just 10 area coordinators processing All logs; not just from US operators but from around the globe.

During that time having a standardized file naming system made tracking logs for any future repairs easier. I personally saved every log I ever processed and if an activator said they did not get what they expected once the log was in, I could easily find what they’d sent and look for any problems.

Naming your files

Now, to the naming issue: In preparing for self-uploading a standard had to be agreed upon for the developers to work with thus, a standard filename format was mandated to get everyone ready for when self-uploading was released.

The standard is as such –

callsign@park#-yyyymmdd

An example using one of my own activations would look like this:

KB2FMH@US-8088-20220202.adi

which was an activation at park US-8088 on February 2nd , 2022. Maintaining a uniform naming system will help You now.

What if I made a mistake, how do I replace the log file?

If you find you need a log replaced due to an error of any kind, you Must ask either the Help Desk Or, you area coordinator. Users cannot Delete logs – only upload.

In the event of a log file error just click the Down Arrow next to the file on your “My Uploaded Logs” portal and click Request Help. Include the park ID and date of the file you’d like removed and one of our support staff will reply when it is done, allowing You to upload a new replacement log.

If the file presents errors during upload that you cannot figure out, again, click the Request Help button and we’re on our way to resolve the issue!

Lastly, there are may different logging programs out there that put many different fields in a log file.

Fields such as Frequency, Name, Grid / Locator, County etc.. are Not required for our system so do not waste time worrying about this data.

Of course, you can always ask your area coordinator for help if you feel more comfortable.

Summary

If you have Any questions that are Not answered in this document or the documents at docs.pota.app ask our Help Desk or your call area coordinator Before doing anything – we’re here to help.

Please, do not rely on hearsay from others or the so-called Facebook experts. The people who built the system and use it daily know how it works and what is required, that’s why they are doing it.

Now get out and activate!

References

• We recommend / Support the N3FJP ACLog software and have very clear instructions on setting it up for POTA use. In Fact, the developer, Scott Davis, created a POTA Template at our request.
• A great video by our own Matt Herre, N3NWV, on how to customize your ACLog application can be viewed here - youtu.be/VePKcyP8ppw
• Instructions for ACLog in general can be viewed Here - youtu.be/aIaNKCKkstM
• To download ACLog, follow this link - www.n3fjp.com/aclog.html
• Our old Help / Getting Started - FAQs section is now docs.pota.app
• You can always start your journey at www.parksontheair.com