I belong to the POTA group on Facebook, and the K9 coordinator just posted this, and since part of his post concerns HAMRS I thought I would post it here, see section “Second,”:
Warning: Long winded statistical post
Morning POTA folk. This is attempt 2 at this post as Facebook ate the first version. I wanted to give you some statistics from 9-land from February with regards to rejected and corrected logs. Hopefully, it can provide a little insight into trends and help you all be a little more efficient.
Three quick disclaimers:
This information alone does not point out any inherent issues with any one particular logging program nor does it discount issues experienced at the activator’s level.
This is obviously a smaller sampling size as 9-land isn’t the most populous or busiest area, nationally or internationally.
No specific activator or activation information is going to be given or addressed in this. We all screw up and I’m not going to call anyone out on that.
So, what does this information say?
First, the bulk of the corrective actions are initiated by the activators themselves, with roughly 75% of all actions being some type of correction to a QSO (e.g. busted callsign, bad time/date, incorrect mode, wrong p2p information, etc). This means that the logs themselves are actually getting uploaded and processed the first time around. That part is great! The only things that will cause me as the coordinator to kick something back are a bad filename, missing state information, or an actual upload error. Everything else is the activator needing to correct their own submitted log after the fact.
Second, HAMRS is immensely popular. I do not track all logs processed as that would send me over the edge and cause me to curl up in the fetal position and cry. However, if you extrapolate the number of errors in a given program to represent total logs and programs used, people like HAMRS. The percentage of corrections/issues with HAMRS shown here does not indicate an issue with the program. Of the issues associated with the app itself, only one was an issue caused by the program – it threw away all MODE information, deleted random QSO info, and had the times incorrect. All other observed issues were user-driven negotiating the nuances of the program with the biggest one being forgetting to stop the clock on the app to input log information in the past.
February saw a large upswing in correction requests. A portion of this can be attributed to new activators learning the system, but about 2/3 of it were existing activators who know the system and requirements. To me, that means one thing: people aren’t checking their logs before submitting. This is important because a correction triples the workload and slows down the process. Additionally, it can create confusion for the studious hunter who watches his or her POTA log very closely. They notice when suddenly credit for 3 parks disappears because an activator needed to make a correction on that coveted 3-fer. Corrections aren’t instantaneous. There’s a time gap between when I delete an old log and the new one is fully processed by the system. This has led to hunter emails inquiring why they suddenly lost credit for something and further slows things down while I try to investigate what’s going on…if I even can.
So, to make a short story long: double check your logs before submitting, multiple days in a single park by a single activator go on a single log, multiple logs on a single email, use the correct file naming convention, and POTA on. Your logs keep me too busy to buy more radio gear.
de W4BKR, your friendly 9-land coordinator