Logging for POTA

I am a POTA activator, which means that in addition to just logging for my own benefit, I also have to submit an ADIF file to my POTA regional coordinator. The following process is what works for me. It’s not the only way to do this, and it may not be the best way, but it’s what I’ve developed over about 18 months, with more than 60 activations.

In the field, I log on paper. This is to eliminate one more device that can fail during an activation. Even when my log book fails (because I left it at home), there are usually enough scraps of paper in the car that I can log an activation. Things like gas receipts, parking passes or old shopping lists, even paper napkins from fast food restaurants all work for this purpose. So, don’t clean out your car too often or you will not have a backup for your logbook 🙂

The first thing I do when arriving at my operating location is to get a few pieces of information from my phone: The grid square I am in (using the HamSquare app), the county I am in (using the Where Am I app) and the correct UTC date and time (using the Pilot Time app). The apps just mentioned work on my iPhone, there are similar apps available for Android phones. All that information gets written at the top of my activation log. In addition to that, I log my operating frequency, and when I change frequencies, I create a new line with the new frequency.

While I am making contacts, all I write down is the abbreviated time – I only write down the minutes – the call sign, the outgoing and received signal report and the state. For a Park to Park contact, I also log the park reference number. A line in my log may look like this:

:23 KN4MQR @ K-1863 59/53 FL

After the activation, when I am at my computer I start my logging application RUMlogNG (this is only available for macOS systems), and I create a new log book. In RUMlogNG, this is done using the Logbook>New menu item, or ⌘N.

In general, submitting a plain ADIF file is sufficient, but may not give you all the Park to Park credits you’ve earned. The POTA database tries to identify Park to Park contacts automatically by matching two QSOs between two operators in different parks within a certain timeframe. This works as long as you’ve only had one contact with the other party during your activation. If one of you moves to a different park, and you have another QSO on the same band, the system will flag that as a duplicate and not give you credit for another Park to Park contact. You can learn more about the nitty gritty of what happens in the database and how to fix that by watching Vance’s (N3VEM) YouTube video: https://youtu.be/Xoyu2ptqoxQ

In the following, I show how to implement Vance’s recommendations in RUMlogNG.

When you instruct RUMlogNG to create a new log book, the first thing it does is to prompt for the location and the filename. I use the following naming convention for my activations:

K5KHK@Kxxxx-yyyymmdd.adif

The Kxxxx the park reference number (e.g. K-2001 for the Adirondacks State Park, but for filenames, I leave out the dash), yyyymmdd is the date (e.g. 20200101 for January 1st, 2020). At this point, we could add QSOs into the log, and if all you want is a simple ADIF file to upload, you can stop here. However, in order to keep track of Park to Park contacts, and to upload to LoTW using the correct station location, you may want to do a bit more setup work before copying the first QSO from the paper log.

To bring up the logbook preferences, use the RUMlogNG>Preferences menu item, or ⌘,

On the preferences dialog, we need to make modifications in two different tabs. We start out with basic settings on the “General” tab. Here is what my settings look like after applying everything I need:

In the “Operator” section, I add my call sign, my name and the grid square that I operated from (from my paper log). I use the six character version of the grid square here. For keeping track of the park reference I operated from, I use the first user defined field and call it “My Park”. The associated ADIF information field is MY_SIG_INFO, and I check the “Remember” setting so that I only have to enter it once. For the second party in a Park to Park contact, I use the second user defined field, and name it “P2P”. Here, the associated ADIF field is SIG_INFO.

The second tab we want to make modifications on is “LoTW/eQSL” (LoTW stands for “Logbook of the World”):



The only information I need to change for each activation is the “Location” field, where I pick a station location that I’ve configured in the TQSL application. If you’ve already set up LoTW logging for your main log book, then chances are that you don’t have to specify the details for how RUMlogNG can find TQSL, if not, then this can be set up here. I won’t go into how this is done, please reference the TQSL and RUMlogNG documentation if you need more help with this task.

If the correct station location is not yet known to TQSL, it needs to be added at this point. Open up the TQSL app and select the “Station Location” tab and select to add a new location:



This will bring up a wizard that will help to create the new location entry.

On the first page, we select the call sign and the grid square (and potentially the ITU zone, CQ zone and IOTA ID):



After clicking on “Next”, we add more information about the location:


As you see, here I only use the four character version of the grid square. This allows me to re-use this location for all parks that share the same county and grid square. Leave the “Park” field empty, TQSL does not know about POTA.

And finally, we give the new location a name. I use the naming schema “State – Grid Square – County”, so for example “NY – FN03 – Erie Cnty”. This is what I would then pick in RUMlogNG when selecting the appropriate station location.



That’s it. Now we can copy the information from our paper log into RUMlogNG. For the first QSO, I set the correct date and time and frequency. This information will be remembered by RUMlogNG, and used for the next QSO. This means that for advancing the time, I usually only have to change the minute information, the rest of the date/time remains the same. The same goes for the “My Park” information, I only enter it once and it will automatically be remembered for the next QSO. For any Park to Park, I enter the relevant information I also add the other park reference in the QTH field.



I usually add a “POTA Activation K-xxxx” to the comment field after I am done entering the individual logs by selecting all logs and then double clicking on one of them. This brings up a dialog in which changes can be made to all selected logs. I set the TX power and the comment at that time.

Now it’s time to verify that we did not make any mistakes. Part of that process is to retrieve information from QRZ.com or HamQTH by selecting a subset of the QSOs entered and then executing the QSO>Add QSO Data>use xxxx function. For QRZ and RUMlogNG, I usually cannot select all QSOs in the log book, I have to do it in multiple batches, otherwise RUMlogNG gets confused (you will see that it’s in that state when it gives you a lot of red indicators for the retrieved data).

Because part of the QSO data I just retrieved is the state information, I can now go down my list of QSOs in my paper log and compare the state with the state returned by QRZ.com. If I have a discrepancy, I know that I made a mistake, and I fix it.

The only remaining task is to upload to LoTW by selecting QSL>LoTW out for new QSOs.

At this time, the ADIF file can be exported. This is done using the Logbook>Export all QSOs as ADIF function. I use the same filename as for the logbook, just with the .adif extension, which RUMlogNG adds by default.

Submit this file to your regional coordinator. Your coordinator may have different recommendations for what the ADIF filename should look like, you can either start with a different filename in RUMlogNG, or rename the file before it gets attached to an email.

We are done with the submission part of the activation. If you also want to have a nice picture with all QSOs represented on a map, here is how I do that:

I create the QSO map with the service provided by qsomap.org – let me explain how it works. Qsomap.org does many different things, we are interested in one specific feature. The first step is to create an account. Keep in mind that you get to use this service for free, but it costs money to make the web site and the software available, so please consider donating a few bucks with PayPal. After the account is created, an ADIF file can be uploaded, and the contents can then be displayed on a map. We are interested in a map with lines, going from the activated park to the locations we had contacts with. This is done using the “Polymap” feature.

Qsomaps.org keeps all uploaded QSOs unless you deliberately delete the QSOs associated with your account.



The upload function is accessed via “File>Upload single ADIF file”. Before we upload a file, we select to delete the existing QSO information:



After confirming that we actually want to delete the list of QSOs, we need to select the upload function again. This time, we can pick the ADIF file and select to upload. Based on the information on the site, it should not matter if the ADIF file as a .adif extension, or uses .adi – however, my experience is that only .adi works, so we need to rename the .adif file we created out of RUMlogNG.

After the upload finishes, the map data is not yet available. Depending on the load on the qsomap.org server, it may take a while until the confirmation email arrives. When you try to display the map before the email arrives, you may get no QSOs on the map, or just a partial map.

Assuming the map data is available, the next step is to display the map by selecting Maps>Polylines Map (or Polylines Map w/labels if you want to see the callsigns at the end of the arrows). Qsomap.org will use the grid data from the ADIF file, and if that does not exist, the location provided by QRZ.com for a given call sign to place the arrow on the map. Our location is specified on the page that opens when we select to create the map.



Specify your location as a six character grid square (that was one of the things I wrote on my paper log before I even started to operate).



After that, it’s just a matter of moving the map around so that the arrows are visible, and to zoom in so that the part of the map we are interested in is as big as possible, so that when we take a screenshot, we get the best possible resolution.



I usually load the screenshot into Photoshop and apply a label with the park reference and the activation date in the upper left corner.