POTA Activator's Actual QTH - Export to QRZ.com

[K3YR]

I’ve used HAMRS for two POTA activations, it’s excellent software and easy to use.

The ADIF file created by HAMRS correctly shows the location information (grid square) for the park I activated (which is different from my home station grid square). When I import the ADIF file into QRZ.com, the grid square data overrides the information on file for my home station, but nothing else changes. So the QSO record is wrong, because although it shows the correct grid square, it shows the “wrong” county and latitude/longitude coordinates for my activation. (And presumably if I were activating in a different state, it would also have the wrong state information).

QRZ support forum says:

I routinely upload to QRZ a “thin” record ADI file to QRZ having only Callsigns, Mode, Band, DXCC nr, UTC Date, UTC Time. There is no RST, frequency, etc. and it works. If that file had the location based fields in it, it should override the Logbook Properties fields for that record(s). Perhaps try it on a few records.

POTA logging/ OP address vs. POTA address

That seems to work for grid square, but not for other location data.

In the HAMRS community I saw another thread suggesting manually changing the QRZ Logbook Properties to reflect the state county and grid square where the activation took place before uploading the HAMRS ADIF file, and then changing them back to the operator’s home QTH after the upload is complete.

Is this the best available workaround? Since HAMRS is pulling complete geographical data for the park, can’t it insert the state and county into the ADI file as well as the grid square? Then that data should override the QRZ Logbook Properties for that activation.

[KZ3L]

Have you tried manually entering the state, county, city name, etc. in HAMRS to see if those fields will override the ones in QRZ.com? Although HAMRS doesn’t retrieve some of these fields (like County and QTH/city) from the park info, you can enter them yourself. However, I’ve never been able to get those fields to override the QRZ location fields.

I usually upload my HAMRS-exported ADIF into Log4OM (my Windows-based Master logbook application), change all of the relevant location fields for my actual park location, then export that ADIF and pull it into QRZ.com. But QRZ.com always uses the location data from its location settings for my logbook and ignores those from the ADIF. The only solution I’ve found is the one I believe you are referencing above… temporarily change the QRZ location fields, import the log, then change them back.

If you find another solution, I would love to try it out. But I don’t think HAMRS will be able to solve this for us despite Jarrett’s great programming talent.

Fortunately LoTW does allow override of its location data, so at least that is a little simpler to handle.

[K3YR]

KZ3L thanks for the quick reply. It is very helpful and prompted me to do some more digging.

To be honest, I wasn’t aware that I can set location fields in HAMRS but your comment prompted me to look and I now realize that in “Expanded Mode” I can set the state and county. I am going to try that in my next activation to see what happens. According to the folks at QRZ, as long as the geographic information appears in the ADIF file, it will override the Logbook Preferences.

And that did happen for grid square just as QRZ says it should.

HAMRS populated the gridsquare information based on the park location, and in the exported ADI file, the field <my_gridsquare> contained the data supplied by HAMRS. When I uploaded the file to QRZ, the data from HAMRS overrode the gridsquare data in my QRZ Logbook Preferences.

The <my_state> field also appears in the HAMRS-generated ADI file but because I activated a park in my home state, there was no change from the data in my QRZ Logbook Preferences.

But the ADI file does not contain any entry for <my_cnty>. Not surprising, because I did not fill up that field before starting the activation. I wasn’t aware the option existed until just now.

But you’re more experienced at this than I am and you seem to be saying that even if the fields appear in the ADI file with the correct values, the <my_cnty> and <my_state> fields won’t override the QRZ location data.

So here’s my plan for an experiment:

(1) Next activation will be in a neighboring state. I will enter the correct county and state in HAMRS and will inspect the ADI file before I upload it to QRZ. Hopefully the ADI file will contain the fields for <my_state> and <my_cnty>.

(2) If the ADI file generated by HAMRS contains those fields with the correct values then, according to QRZ’s support forum, the imported data should override the QRZ settings. If the override does not happen, that is a bug on QRZ’s side and I will take it up with them. QRZ may or may not provide a solution, but it will be their problem to solve not Jarrett’s.

(3) If the ADI file generated by HAMRS does not contain the fields <my_state> and <my_cnty> then there is nothing for QRZ to work with and of course there will be no override. So in that case, I will do the manual workaround that you suggest, but I will put in a feature request to enable <my_cnty> and <my_state> fields to be written to the ADI file upon export.

And yes, in LoTW you can (and must) set location data. It seems that if you do not do so, LoTW will reject upload of the file because of the mismatch. For my first POTA activation, I tried uploading the ADIF file and LoTW would not take it until I created a new location that matched the grid square of the POTA park.

[KZ3L]

Your experiment sounds like a great test! I’m anxious to hear how it turns out. Be sure to use v.1.0.1 since that makes the State and County visible in the QSO panel and keeps them “sticky” so they apply to all subsequent QSOs. Prior versions of HAMRS didn’t retain county information for you.

You should also be aware that your own “QTH” field (which translates to MY_CITY in the ADIF export) is NOT sticky and unfortunately, if it matters to you, will be blank unless you edit and enter it for every QSO in the log. You can also use ADIF Master to add it later. I hope @Jarrett adds it to the panel along with the other QTH data in a future release.

By default, HAMRS should get your state correct by retrieving the park number. For multi-state parks, v.1.0.1 prompts you to choose your state.

For LoTW, if you use TQSL to upload your logs, just check the “Override Station Location with QTH Details from your log” option in the settings, and provided you have the state, county, and grid square in your log, you can pick any Station Location profile (I built one called “KZ3L-Portable”) and always upload your portable activations to that one. It’s much easier than creating a new station location for every park you visit.

Here’s a write-up that may help. Skip right down to the “There’s a better way” section (and ignore the “/R” discussion earlier on the page… nearly no one uses /R or /P in POTA and it gets confusing when matching QSLs):

Logbook of the World for Rovers - K5ND

[K3YR]

KZ3L I realized I didn’t have to wait for my activation to perform this experiment.

A few minutes ago, I created a new logbook called Test Logbook and I created three “fake” QSOs. One with myself using a callsign I have in another country, one with my son who is usually my second op on POTA and one with an old friend who is licensed but inactive.

You’re correct that HAMRS populated the state field and grid square correctly, based on the park number. I filled in the “county” field manually.

I then exported the logbook to ADI.

I opened the ADI file with TextEdit on my Mac and I can see the fields <my_cnty>, <my_state> and <my_gridsquare> all with the correct values based on the park number I gave.

I then uploaded the ADI file to QRZ and opened the QSO records.

They show the correct gridsquare taken from HAMRS, but not the correct state and county. They show my home station data. In other words, the ADI file failed to override the QRZ Logbook Preferences just as you predicted.

I then deleted the fake QSOs from QRZ.

So now I have to “park” this issue on this forum (excuse the pun) and go over to the user forums on QRZ to complain that their site isn’t doing what it is supposed to do when it handles the ADI file import. I will report back on what they say.

Oh, and for LoTW: normally, I import everything into my logging software (MacLogger DX) and then upload it to LoTW, Clublog, and eQSL from there. I don’t normally use the TQSL software. But I think you’re right - it will be easier to use the TQSL software for POTA uploads to LoTW - it will save me a step.

[KZ3L]

Hey, that sounds great. Thanks for testing this out and I’m glad you were able to confirm my experience with QRZ.com.

It’s possible Maclogger DX contains a setting to override LoTW location data. Log4OM didn’t have it previously, but when I requested it the developer changed it for me in about a week. I don’t need to take any extra steps now–Log4OM interacts with TQSL and takes care of that setting for me.

---

ADDED: According to this page, Maclogger DX offers a setting to override LoTW location data:

https://www.dogparksoftware.com/MacLoggerDX%20Help/mldxfc_dx_contest.html