See the linked file discussing how the ADIF file generated by HAMRS does not override the default QTH settings on QRZ.com.
I’ve been discussing this problem on the QRZ user forum.
A user there suggested that the ADIF standard for the <MY_CNTY> field is supposed to contain the two letter abbreviation of the state followed by the name of the county, and supplied the following screenshot.
Wow! That’s an amazing catch, and frankly it’s counterintuitive. Most databases rely on discrete fields for different elements such as this. I’m surprised the ADIF spec defines counties to include the state. And I never noticed this before.
In HAMRS, I guess the solution is to enter ST,CNTY in the county field if this matters to you. My home QTH would be “OH,Warren”.
I don’t know if that will override QRZ’s log, but if it does, that would be a huge time-saver.
I, too, thought it was counterintuitive and then I thought about it a little bit more. Now that I think about it, in order for <MY_CNTY> to represent a unique value, it would have to include the state abbreviation. This would be needed to disambiguate between, for example, Orange County, New York and Orange County, California.
So what’s the easiest fix for POTA users like us? For example, if I’m activating a park in Salem County, NJ should I enter NJ, Salem in the county field in the HAMRS POTA log template instead of simply Salem? We have to test this to see if it works.
I created a test log in HAMRS with dummy contacts for a mock activation of K-2016, Blauvelt State Park in Rockland County, NY.
Entering the park number in HAMRS automatically populates the “MY STATE” box, which then exports to ADIF’s <MY_STATE> field. When the ADIF file is imported to QRZ, the <MY_STATE> field overwrites the existing location set by QRZ.
So the real problem is only the <MY_CNTY> field, the value for which does not get automatically generated when you enter the park number into the MY COUNTY box in HAMRS.
In my test log, I entered “NY, Rockland”. This value exports to ADIF’s <MY_CNTY> field. When I imported the ADIF file to QRZ, it overwrote the default county data for my home QTH stored in QRZ.
Hooray, problem identified.
Short-term fix: When setting up at the beginning of the activation, the HAMRS user should fill up the MY COUNTY box by typing the two-letter state abbreviation followed by a comma and then the county name. If this is done, then HAMRS will generate an ADIF file with the correct value that will then override the corresponding QRZ data. No need to change Logbook Properties before and after each upload. Hooray!!
Long-term fix: feature request so that the “MY COUNTY” box is automatically populated with an ADIF-compliant value when the park number is entered, the same way as happens for the “MY STATE” box.
KZ3L, would appreciate you testing this separately and verifying my findings.
Brilliant! It worked for me, too! I tried a test QSO and it is good to go. All location fields (including the MY_QTH, e.g. City) uploaded correctly without the need for me to change anything in the settings. What a time-saver!
Now the next question is whether or not LoTW accepts the County field in the “ST, County” format and handles it correctly. As you pointed out, that is the ADIF spec, so hopefully it is compatible. LoTW certainly recognizes the MY_CNTY field with only the county entered–so it must use the state field to look it up.
I just tested QRZ and LoTW with the County field identified in the ADIF-specified format. Both work now.
It would be helpful for @jarrett to make the “My QTH” field sticky now – that’s where I like to put the name of the park when I’m activating, and it’s a bit of a time sync to edit this for every QSO within HAMRS. I usually edit it later outside of HAMRS. Bringing it to the right panel alongside my county and state fields would be helpful.
Yes, that and also making the “My County” field automatically populate with the correct value derived from the park number. At the moment, “My County” remains blank unless you input a value manually.
That said, some parks span two or more counties. Perhaps populate automatically for single-county parks, and then give a prompt if a park spans multiple counties (just like the software already does if a park spans multiple states).
