I discovered two bugs when activating today using the POTA template on 0.11.1 on the iPad. The first led to the discovery of the second more significant issue.
The frequency field allows entry of more than one decimal place. I inadvertently entered 7.035.5 instead of 7.0355 and HAMRS allowed it. That could confuse other programs when ADIFs are exported and imported.
After discovering my error, I edited the QSOs and discovered that “Club Callsign” (which maps to “Station_Callsign” in the ADIF) somehow became my park number.
The latter could be a serious bug, depending upon how the POTA import feature treats this. The club (station) callsigns could be imported as “K-1943”, for instance, instead of a true call sign.
So I can’t seem to replicate this. I put in a few QSOs with 7.035.5, like you had done. With both look-ups on and off (hamdb on my test rig). Edited them to 7.0355 and couldn’t reproduce the error. Can you tell me more about your setup? Is the Club Callsign empty, and then becomes filled with with your park number, or do you have something in there and it’s overwritten?
I’ll have to do some more testing. During the activation there were several things happening, and I didn’t notice the glitch until I had exported and reviewed my ADIF after the activation. I attributed this to my editing of the QSOs but it may have been caused by a combination of things.
My phone’s hotspot was inconsistent, and accessibility to HamDB was intermittent as well. I ended up correcting the frequency as noted above, and did individual lookups for most or all of those same records.
In my exported log, 32 of my 58 QSOs have my park number in the “Club Callsign” field.
I always enter my own call into the Club Callsign field so it populates the Station Callsign field. That’s a requirement of the ADIF spec and it is also a required field when submitting to WWFF. It’s just simpler to enter it in HAMRS instead of adding another column later in ADIF Master.
So yes, I started the fresh log with my call in the club callsign field and it was later overwritten by my park number.
I’ll keep poking around on it. I plan on doing another bugfix release in the next week, I’ve got some noisy behind the scenes errors that are junking up my error reporting.
However, just a couple of additional observations that may be relevant. The HamDB feed was glitchy at the time. My first QSO was also one I had copied from the POTA Spots, and the error (putting my park number in the Club Callsign field) propagated until the next time I copied a spot.
Sure wish I could figure out what happened.
As for the frequency entry, some validation would be helpful. That field allows free text, including letters, multiple decimal places (as mentioned above), and spaces.
HamDB has been a bit slow I’ve noticed, I hope we’re not overwhelming the servers, and it could be I have some race condition happening with a slow lookup. I’m investigating that. I also have frequency input validation on my list for this next release.
Also recommend checking frequency and band when copying spots. Sometimes people are entering the spots on the POTA.app site wayyyy wrong (such as 72355 kHz when they really mean 7235.5 kHz, or 142355 instead of 14235.5). If HAMRS reads it as entered and doesn’t populate the band, that creates a log upload error. You could highlight the field (and band) when it appears to fall way out of spec and disallow entry of that QSO.
I wish the POTA spotting page would require MHz entry and validate the frequencies too, but that isn’t currently enforced.
Also, in case this fell off your radar, presenting the trailing zeros in the spot pages would be very helpful (e.g. show it as 14.230 MHz instead of 14.23 MHz).