Doing a simultaneous activation of a Summits On The Air (SOTA) summit and a Parks On The Air (POTA) park is becoming more common. There is a lot of crossover between the two programs. Here in Colorado, many of the SOTA peaks are in national forests or national parks, making them an ideal double activation.

Creating one file for logging both programs can be a challenge but I’ve settled in on an approach that works for me. I’ve decided to use HAMRS for this, whether it is real-time logging or transcribing a paper log after the event. HAMRS provides useful templates for both SOTA and POTA, but not both simultaneously. HAMRS still has a few quirks on entering callsigns and timestamps, but I am hopeful those things will get addressed in the fullness of time. If you are using a different logging program, you can probably still benefit from this post.

I wrote about the different ADIF fields that POTA and SOTA use here:

More Logging Tips for SOTA & POTA

Simplest Case: No P2P or S2S

For an activation that does not involve making contact with other parks or summits, the logging requirements are simple. POTA refers to these contacts as Park-to-Park or P2P, while SOTA refers to them as Summit-to-Summit or S2S. Same basic idea.

The ADIF file for POTA needs to have the usual logging information but the special POTA fields (MY_SIG_INFO, SIG_INFO) can be left blank. The filename will indicate the park you are operating from and must meet the standard POTA format. (Example: K0NR-K-4404-20211017.adi for K0NR operating from K-4404 on 17 Oct 2021). If you do have some simple P2P QSOs in there (one park contacting another single park, no double activations), the POTA database will attempt to identify these contacts by comparing the logs of the two POTA activators. I believe this works pretty well but I have not tested it extensively.

For the SOTA log, you must provide your SOTA summit using the MY_SOTA_REF field. If you use the HAMRS SOTA template, it will take care of this for you. Then you can use the same ADIF file for POTA by setting the filename to the right format. If you need to add the MY_SOTA_REF manually, ADIF Master is a good tool to use.

With P2P or S2S

When there are P2P or S2S contacts, things get a bit more complicated. The ADIF log needs to have MY_SIG_INFO for each QSO set to your POTA number and SIG_INFO set to the other station’s POTA number. If the other POTA station is activating more than one park, this can be handled by entering multiple QSOs in the file. (I think this is the cleanest way of handling it, but let me know if you have other methods.)

The SOTA logfile requires something similar, with MY_SOTA_REF set to your SOTA summit and SOTA_REF set to the other station’s SOTA summit.

One ADIF can be created that has all four SOTA/POTA fields set correctly but you’ll probably have to use ADIF Master or a text editor to get this all entered. HAMRS can help you with either SOTA or POTA, using the corresponding template. Normally, I try to determine if I have more P2P or S2S contacts and choose the template (POTA or SOTA) with that in mind. Then, I use ADIF Master to add in the other -OTA program logging info.

POTA does allow for simultaneous activations of more than one park. For example, the Continental Divide Trail is considered a park and it often runs through a national forest, so both can be activated together.) If you are activating more than one POTA park, you will need to create a log file for each park and submit them individually. A SOTA activation can only be from a single summit.

Wrap Up

I treat my SOTA/POTA logs as separate files but I also import them into my master logging program, which is currently Log4OM2. I also upload the file to Logbook of The World (LoTW). It is important to set up a new LoTW location with the grid locator, state and county set correctly. This may create a long list of locations in your LoTW account but provides proper confirmation for stations chasing grids, states, and counties.

These are some things I’ve learned along the way and I hope you find them useful.

73 Bob K0NR

Update 14 Apr 2022: Mike/KD5KC pointed out that AC-LOG from N3FJP can be configured to handle the SOTA and POTA fields simultaneously.

I previously wrote about some of the tools I use for managing SOTA and POTA logs. See Tips and Tools for Managing Logs. I continue to learn about the file formats and various tricks for generating the logs. Some of this is not well-documented…at least I haven’t found it…so I am sharing what I’ve figured out. My apologies in advance if I get any of this wrong. Reader Beware!

Lately, I’ve been trying to figure out how to do one log file for both SOTA and POTA. I am not aware of a logging program that will handle both simultaneously. (Let me know if you do.)  The ADIF file format can handle this and is the way to go for such a log file. Also, an ADIF file can be imported into other logging programs and Logbook of The World. The complete documentation for ADIF can be found here: https://www.adif.org/

SOTA Logs

Our combination SOTA + POTA activations usually start out as a SOTA activation. Then, if the SOTA summit is inside a POTA-designated park, we may try to do both simultaneously.

The SOTA database supports uploading ADIF files, including support for Summit-to-Summit (S2S) contacts. The figure below shows a recent SOTA log, in ADIF format, displayed by ADIFMaster. The 6th column is MY_SOTA_REF, which is the SOTA reference for the summit I was activating. In this case, it was W0C/SP-084 and is the same for all of the QSOs. The 9th column is SOTA_REF, which is the SOTA reference of the other station’s summit, if any. Most of the rows are blank, because the other station was not on a summit. However, N0TZW and N3ALT were on W0C/PR-031 that day resulting in a pair of S2S contacts. If you get these fields set correctly in the ADIF file, the SOTA database will log the activation and the S2S contacts correctly.

POTA Logs

For simple POTA activations, you just need to get the QSO information correct and the file name indicates the park you were operating from. For example, the file name K0NR-K-4404-20211017.adi indicates the station callsign (K0NR), operating from park K-4404 on 17 Oct 2021. The POTA system will try to identify Park-to-Park (P2P) radio contacts in the file, by comparing activator logs. My understanding is that this works only for the simple case of two activators working each other, each operating from only one park.

The figure below shows a POTA log using ADIFMaster. The 7th column is MY_SIG_INFO, which is the POTA designator (K-8295) for the park I was activating. This is the same for all of the rows. The eleventh column is SIG_INFO, which is the POTA designator for the other station. Most of these are blank because the other station was not in a park. However, there are six QSOs shown that were Park-to-Park. Note that the QSO with N7OOS was entered twice, with two different park numbers. This is because he was doing a double activation that day…putting two parks on the air at the same time. Yes, activating multiple parks at once is possible, even common, in POTA. A good example is when a national scenic trail runs through a national forest. One operating location is in both parks simultaneously.

It might be possible to have two POTA designators tagged to one QSO, I am not sure. But I think it is cleaner to just enter it as two separate QSOs. I know the POTA database will interpret it correctly. When I imported the file into Logbook of The World, it complained there were duplicate QSOs, which were easily ignored.

The 6th column in the figure is MY_SIG, which indicates a special interest activity or event (e.g., POTA). In the general case, the logging program would use this field to interpret the meaning of SIG_INFO and MY_SIG_INFO. It appears that the POTA system does not require MY_SIG to be set to POTA and will just go ahead and interpret SIG_INFO and MY_SIG_INFO for POTA use. Not shown is another field called SIG, which is the special interest activity or event of the other station. I thought I would mention these SIG fields in case you encounter them. I don’t think they are required in a POTA log.

Creating a SOTA/POTA Log

When doing a combination activation, I’ll set up the logging program for SOTA or POTA based on whether I expect to have more S2S or P2P radio contacts. For example, if I just expect to work a few summits and many parks, I’ll use HAMRS with the POTA template. That way, all of the parks get entered correctly from the start. I will note any S2S contacts in the comment field and come back later to fix them.

The easiest way to manage ADIF files is via ADIF Master. You can also edit the files manually using a basic text editor but that can be error-prone. To add a new field in ADIF Master, you insert a new column (right-click on a column, then left-click insert column). Then create a label for the column by right-clicking the top of the column, followed by Custom, entering the name of the new ADIF field.

Here’s the short list of ADIF fields that may need to be used:

MY_SOTA_REF is your SOTA reference, the summit you are activating

SOTA_REF is the SOTA reference for the other station, assuming its an S2S radio contact. If you submitting a Chaser log, this is the SOTA reference for the summit you are chasing. Your MY_SOTA_REF would be left blank.

SIG is the name of the contacted station’s special activity or interest group (e.g., POTA)

MY_SIG is your special interest activity or event (e.g., POTA)

MY_SIG_INFO is your park number that is being activated.

SIG_INFO is the park number for the park you are working (P2P).

By editing my log files using ADIFMaster, I’ve been able to create log files that can be submitted to SOTA, POTA and LoTW without errors. It takes a little bit of work to get the file right. Before you submit a log file, it is always a good idea to view it using ADIFMaster, to try and spot any obvious errors. This is especially useful for POTA logs, when the turnaround time can take up to two weeks.

This is what I’ve learned. How about you?

73 Bob K0NR

22 May 2023 Update: The POTA folks have been busy creating a way for you to upload your log file directly, so you no longer have to email it in. The specific file name is not longer required and the turnaround time is essentially immediate. My comments on the format of the file are still valid.