Jason Johnston from POTA reached out to today to let me know HAMRS was causing some headaches and wasted time for their coordinators and activators, by “dropping mandatory fields like MODE and BAND on the first few contacts”.
I want to fix this ASAP, but wanted to gather feedback from you all. Here are my thoughts:
I don’t believe that during the export process, HAMRS is dropping fields and not placing them in the ADIF file. I could easily be wrong, so if someone has an example of a QSO having either BAND or MODE populated, but NOT being exported, please let me know here.
EDIT: Jason just said sometimes the entire MODE column was missing for some logs, so maybe there is something wonky with the ADIF exporter, I’m currently looking to replicate.
More than likely, MODE and BAND, are not required to save a QSO, just a call. I’d like to make all POTA fields required to save a QSO. Does anyone see this causing friction? Other options would be to alert the user on export that invalid QSOs were not exported, or something else more hairy.
I feel like there is a thread around here somewhere that may have mentioned this issue, but I cannot for the life of me find it.
If you can reproduce, or have seen this, please provide your Version number and Operating system - a sample ADIF and screenshots woulb be amazing as well.
Here’s another thread where I recommended validating all POTA-required fields, along with a report from a user who had his log rejected:
Agree this validation, or at least providing a warning or highlighting QSO records with missing info, needs to be done. Adding the band and mode column in the log list has certainly helped me but you should take it a step further.
Call, band, mode, date, and time are all required fields. They should all be validated as present and confirmed as meeting the ADIF specs (e.g. 40M for band, not 40).
I’ve also mentioned the time stamp–if there is a delay in entering the next QSO (for instance, I created the log at 2345 and activated at 0030), the time stamp and date will be off. Some people have ended up with a failed activation with only a single QSO for this reason.
I also suspect some users aren’t upgrading their versions of HAMRS and aren’t taking advantage of the additional features you are implementing. Some way to check and warn of an update would be beneficial.
It’s happened to me a couple of times . . . but it’s always been my fault — forgetting to enter Mode at all or leaving out the “m” for Band.
Have learned to ALWAYS upload to ADI Master for its automatic check and no problems after I do. I don’t trust what I enter on HAMRS in the heat of the battle (activation).
Joe KK9TT
I have been guilty of starting a POTA activation without Mode/Band missing, and occasionally forgetting to put the Park Reference in. I’ve also had a couple of them kick back from the K3 POTA person for it. I’ve used HAMRS at least 3 dozen times now, and I 100% can confirm each have been a fault of my own and not the HAMRS program itself.
First, HAMRS is fantastic. I can’t thank you enough for the hard work you’ve invested in this project.
I recently had the same problem - I submitted two logs that had both band and mode missing from the first two records. The third log submitted at the same time had no errors. I therefore think the missing information was 100% due to my error. On the options you’ve suggested (make all POTA fields required to save a QSO’ or 'Alert the user on export that invalid QSOs were not exported) I’d prefer the alert versus the requirement. It’s really busy when working a pileup and getting hung up by the logger to fill in missing fields could get frustrating. Having an alert would warn about the problem and allow me to fix it later.
I just went to my travel POTA log an was able to enter a contact without the freq. if I were to export and send it in it would get rejected. I would recommend making all required data be present before the contact can be saved. Everyone should be checking their logs prior to sending them in but some don’t. I have never had an issue with HAMRS messing up my log, but I have had a couple issues of me messing up my data entry that I was able to fix prior to sending. Sadly many people need things build idiot proof, the easiest way I see to do that is by preventing tha saving of a QSL unless the required data is present.
Wow, the criticism is a little harsh. I, the operator, do my due diligence before submitting my logs to either the World Wide Flora and Fauna (WWFF-KFF, U.S. program) or the POTA program. HAMRS works great for both!
It is MY responsibility, not the developer of HAMRS, to ensure that the log is in the proper format. I use ADIF Master as a check and ‘tweaker’ to my log before submitting to both programs area co-ordinator. I suspect that these ‘MODE and BAND problems’ are operator error.
Thank Jarrett for HAMRS, it is great and I appreciate your efforts. It is perfect for what it was designed for, a lightweight, easy to use tablet/phone/mobile logger. I wish, perhaps, just a little more mention of the WWFF program. Remember, WWFF preceeds NPOTA and POTA and continues on. Thanks again for HAMRS!
Same here, but as the regional coordinators can attest, a lot of activators aren’t filling in all the required fields or are entering them incorrectly. Most of this, IMHO, is due to inexperience. ignorance, or a general adversity to using computers/tablets/phones. This causes a lot of rejected logs and wastes time for those who are volunteering to upload the logs.
A few tweaks to minimize these errors could go far toward closing the error gap.
Maybe POTA should post a how to, when it comes to using HAMRS for logging.
I don’t really think it is the fault of HAMERS it is that activators’ not bothering to learn how to use the logger. Or that the information on using it is not made easily available.
I just did a test with all templates looking at the QSO map issue. I had 11 contracts per Logbook.
I just did an export on all the logbooks and checked the output.
All exports included the Band and Mode for all entries.
I did notice that the Band field auto-populates when entering the frequency, but the user can modify this field. To reduce errors on the Band field, I am thinking that if that was a read-only field, this would reduce the errors relating to the Band field.
This is a downloaded version of Hamrs (0.11.3) running on my Intel MacBook Pro 16"
The only bug issue I have been experiencing is the QSO Map is not working at all. I have a few contacts that are listed but the vast majority of contacts are NOT being displayed.
