POTA .adi file format

Hi, I am new to this program and Parks on the Air. I was looking at the .adi output file from a log I created using what I think is the POTA template. The .adi file looks nothing like the example on the POTA site. Is there something more I need to do, or does POTA accept these files as is? I have been looking for a manual, but I can’t find one.

You should only need to set the correct filename. The ADIF export from HAMRS should be just fine for POTA log submission from there.

I process tons of logs exported from HAMRS without issue. Actually, HAMRS, using the POTA Template, is the only logging program that provides all the data points needed by the new uploading system currently undergoing beta testing without a lot of modification or customizing.
I am curious specifically what example you are looking at that is different from the HAMRS export.
WA7SKG 7th Area Coordinator

1 Like

Here is the file output. My call is W3CAT and the park is K-1487. I replaced the “<” with [ to get it to upload herel

Generated on 2022-06-25T13:32:45.063Z
[adif_ver:5>3.0.5
[programid:5>HAMRS
[programversion:5>1.0.6
[EOH>

[band:3>20m
[call:6>KF0EHL
[country:13>United States
[freq:0>
[gridsquare:6>EN23fk
[mode:3>SSB
[my_gridsquare:6>EN82mi
[my_sig:4>POTA
[my_sig_info:6>K-1487
[my_state:2>MI
[name:15>Robert L Hoting
[operator:5>W3CAT
[qso_date:8>20220624
[qso_date_off:8>20220624
[rst_rcvd:2>59
[rst_sent:2>59
[sig_info:6>K-9329
[state:2>IA
[time_on:4>1340
[tx_pwr:2>12
[eor>

[band:3>20m
[call:6>KC1NDQ
[cnty:3>USA
[country:13>United States
[freq:0>
[gridsquare:6>FN41lm
[mode:3>SSB
[my_cnty:3>USA
[my_gridsquare:6>EN82mi
[my_sig:4>POTA
[my_sig_info:6>K-1487
[my_state:2>MI
[name:15>FRANCIS L KELLY
[operator:5>W3CAT
[qso_date:8>20220624
[qso_date_off:8>20220624
[rst_rcvd:0>
[rst_sent:0>
[sig_info:6>K-8412
[state:2>MA
[time_on:4>1359
[tx_pwr:2>12
[eor>

[band:3>20m
[call:6>VA3JIN
[cnty:6>CANADA
[country:6>Canada
[freq:0>
[gridsquare:0>
[mode:3>SSB
[my_cnty:3>USA
[my_gridsquare:6>EN82mi
[my_sig:4>POTA
[my_sig_info:6>K-1487
[my_state:2>MI
[name:15>Robert Lavigne
[operator:5>W3CAT
[qso_date:8>20220624
[qso_date_off:8>20220624
[qth:0>
[rst_rcvd:0>
[rst_sent:0>
[state:2>ON
[time_on:4>1402
[tx_pwr:2>12
[eor>

That is exactly what we are looking for in a file. What is the problem?

The HAMRS exported ADIF files include more info than the POTA uploader needs (such as RST), but that’s not a problem. The uploader will just ignore those additional fields.

I will say HAMRS does not add the station_callsign which is something that POTA says you should always have while operator is an optional field. At least I haven’t figured out how to get it to auto add it.

https://s3.us-east-2.amazonaws.com/resources.pota.app/documents/activator_guide/POTA-Activator_Guide-english.html#adif-logs-for-pota

If you enter your call sign into the “Club Call” field, that populates the “Station Callsign” field in the ADIF file.

FYI, technically neither the Operator nor the Station call is required in the POTA ADIF file if you are activating under your own call sign. The file name is where your call sign needs to appear.

station_callsign is one of the few fields labeled as required for the POTA ADIF.

Although up until now it didn’t matter since the coordinators would look at you file name to get your station callsign and then the system would use operator to set that part of the data entry.

But now with the Self Upload hamrs should be adding the station_callsign was was always a required field.

The uploader will grab the call sign from your file name if it isn’t in the ADIF as a discrete field. It isn’t strictly required, nor has it ever been required. This is one of the reasons they’ve mandated using the “CALL@K-PARK-yymmdd-ST.adi” file naming convention.

From the FAQs:

Q: Which fields are mandatory in POTA logs?

A: QSO_DATE, TIME_ON, BAND, MODE, and CALL. We usually exchange signal reports, but you must exchange something else as well besides just your call sign, like your station designation, or class (e.g. ARRL Field Day exchange). It is NOT mandatory to log information outside of Call Sign, Band, Mode, Time, and Date. We require a properly formatted ADIF file. Please only use logs generated by a program that ensures the ADIF format has been followed correctly. We see a large number of errors caused by people directly editing the text of their ADIF files by hand!

Watch Matt Heere’s video for more specifics on the self-uploader.

Personally, I always ensure Station_Callsign is filled in because I also submit my logs to WWFF. To my knowledge they DO require that field to be populated.

Yet in Parks On The Air Activator Guide is says it is a required field.

Hmmm. I don’t think that was in older versions of the guide.

Regardless, POTA accepts the file without it.

I’ve made the recommendation in the past to ALWAYS populate the STATION_CALLSIGN field with the Operator’s call sign if the HAMRS user leaves it blank. I still think it is the preferred way to go rather than using the “Club Call” terminology on the main screen. It is the STATION_CALLSIGN that always matters in any QSO. That’s the only legal callsign that matters.

The official POTA self uploader video says that the STATION_CALLSIGN is not required.

Yet, the coordinator I go thru said that to upload logs from HAMRS its suggested to use ADIF Master to add the required fields it is missing.

The post you quoted suggests HAMRS is “less robust” with capturing the required fields. That used to be true, but the more recent versions of HAMRS are, in my opinion, more robust than other logging apps. I haven’t had a rejected log in well over a year now (over 100 activations during that time).

That email was sent on July 1st 2022.

I have never had a rejected log either despite the missing required fields.

There are some changes with the new self-uploader. Our goal was to get as much information as possible from the individual contact records. To do that, the following fields are now required in the contact record:
CALL, BAND, MODE, QSO_DATE, TIME_ON, MY_SIG_INFO, MY_STATE, STATION_CALLSIGN, OPERATOR, and (for P2P contacts) SIG_INFO.
This has not been well advertised. There has been a lot of work to accommodate these if they are missing. The parser will try to pull them from the filename or ask for the data when processing the file. Our desire was to not rely on the filename at all. You could actually name your file “Playing at the park” and it will work.
As far as the documentation (including the new video) goes, all documentation is now under review and revision. It will not be removed until the new stuff is published. The old Activator Guide PDF had quite a few errors in it, so, don’t count it as gospel. In the rush to get the self-uploader video out in time, it also has a few errors. A decision was made to go ahead and publish the video with the errors rather than delay its release. They were deemed not significant enough to cause a problem.
Any questions may be addressed to your Area Coordinator or the helpdesk.

73,
Michael WA7SKG
POTA 7th Area Coordinator
POTA Helpdesk Log Support

1 Like

Thank you for making this known. I’m surprised nothing has been said yet on the POTA Facebook group to clarify this change. Some of the references should be easy to update, like the FAQs.

For those using the HAMRS POTA template, this means that the “Club Callsign” field MUST now be manually filled in since this becomes the STATION_CALLSIGN field in the ADIF file.

HAMRS doesn’t enforce the park and state fields, but does populate STATE when the park is entered.

For now, fortunately, the POTA uploader pulling from the file name continues to work fine. The file naming convention has been published for a couple of years now so I would expect activators to use that routinely now.

First, remembering all the POTA staff are volunteers with lives, jobs, families, etc besides POTA and ham radio, things have to be prioritized and everything takes time. Due to the nature of the beast, many of these are limited to just a couple (or one) people to facilitate collaboration. Otherwise, change management becomes too time consuming.
Honestly (IMHO) Facebook is a terrible platform for managing anything. It is nearly impossible to go back and find previous posts, most of the time people are answering questions they know nothing about, at least 50-75% of the information you see is wrong, it is just not a good way of running a program. As the POTA program has exploded in popularity (almost 25,000 users, over 37,000 parks worldwide), it is sometimes hard to keep up.

As for the STATION_CALLSIGN entry, perhaps a change to the app could rename it to something like “On Air Callsign”, since that entry would apply to not only Club Calls, but Special Event as well as the user’s call under normal operations?

Michael WA7SKG