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, 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.
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
No comments:
Post a Comment