I’m not sure if this is a bug, or a feature I’m not using correctly.
Out in the field I keep a paper log of my contacts and then log them into HAMRS later. Sometimes it’s the same day, and sometimes later.
Last night I was inputting 3 logs from January 1 activations. I paused the time/date and manually entered times beginning in the 1100 UTC hour on January 1. Quite often the time and date would revert to the current date and time. I thought I was being careful, but this kept happening, and I don’t know if it’s something I myself did. I kept the time on pause the entire time, but even after changing the time, it would sometimes revert to the current date/time before I could save it.
Any light you could shed on this would be appreciated.
KB9CNN,
Hey partner, you worked me on a few previous POTA activations I had. Thank you for answering the CQ. What I did was to create a logbook, then go and make at least one entry (for saving the park in a logbook on my computer). Then later on, when you are ready, knock out the rest of the log with the other QSOs you made, go and enter all the call signs and frequencies, modes and bands. Then circle back and edit each one of the entries with the correct date and time. It became frustrating for me to edit so many QSOs, so now I just enter them in real time.
The real time frustration for me comes in the form of Modes, Frequencies, and Park To Park entries. It can become time consuming after 100 QSOs. I keep asking, did I enter the time correctly, is it in UTC, is the date correct, is the Park correct etc… It can become taxing.
Hope this helps. Catch you out there again soon.
73,
KI5CDF
What platform are you using and which version of HAMRS do you have installed?
I had similar issues on my iPad after upgrading from an older version, until I force-closed the app and rebooted. The pause button worked properly for me after that and I’ve never had problems since on 0.11.6.
When you press the time pause button, does it turn red for you?
I had the chance to try this on my Windows 10 PC and could not replicate it.
A friend ran into the same problem yesterday on his system (Windows 10) but after closing and reopening the app, the glitch went away (at least for now).
You might try that as well: fully close the app, reboot your PC, and open it again.
I have now tried numerous approaches, but I continue to face the same problem.
On my PC I am incessantly having to be vigilant about the time feature. Inputting 117 contacts from this mornings paper log I paused the time in HAMRS and started entering my QSO’s. I overwrote the current time with the QSO time, pushed enter for the second QSO, and so on.
Repeatedly, the time in the next QSO would revert to the current time. Sometimes even after overwriting the time! I constantly had to check what times the entries showed because I just couldn’t trust that what I entered would keep. This is growing increasingly frustrating and I am about to pull the plug and try something else on my PC.
I do not have this issue on my iPhone, thankfully, where I also log my day to day contacts.
An issue I experience on both platforms is the inconsistency in the QSO mapping feature. Logging QSO’s does bring in the contact information, but though there is a grid number populated, the map only shows a fraction of the actual QSO’s. This is remedied by using the lookup feature, but I don’t understand why the map doesn’t display them in the first place. Selecting “lookup” 117 times gets old.
I’ve always loved the simplicity and user interface of HAMRS, but these persistent issues are dampening my patience with the platform.
Steve, are you using HAMRS v1.0.1? If so, I believe you are the first to report that the time pause feature doesn’t work in Windows. This is one of the fixes @jarrett addressed in the newest release, or at a minimum it was fixed for most users. (Some have had to fully close HAMRS and reboot… then it worked correctly.)
Regarding the map, that is odd, too… unless for some reason your own grid square isn’t populating for all of the QSOs. When this happens again, before you go through the lookup process, would you mind exporting your ADIF and sending it to me for a look? I’d like to see if anything odd jumps out at me. Use KZ3L at ARRL.net.
Thanks for offering to take a look. I will take the “day to day” contacts I am recording on my iPhone and populate those on the Windows version and send them over.
I close and restart my laptop daily, sometimes multiple times, so that doesn’t seem to be helping my HAMRS experience. The mapping issue has been an ongoing issue for me, but it really doesn’t make sense when Grid Squares are actually populated, unless it was a user error (i.e. O instead of 0), or a foreign entity.
I appreciate your attention, Kevin. I will try to get a small file over to you later today.
Do you happen to have a Windows 10 PC that you could compare this to? I’ve been trying and trying and can’t duplicate your time pause problems on either of my WIndows 10 PCs. (Unfortunately I haven’t taken the leap yet to go to Windows 11… just want to ensure all my software is compatible before doing so.)
Are you tabbing between the fields as you enter them, and if so, have you tried just clicking directly into each field and pressing “save” when you’re done instead of tabbing and pressing “Return”? Do you experience the same issue then?
EDIT: Well, well… I just managed to replicate your time pause issue. It is doing the same thing for me now. Previous attempt I couldn’t get it to act up but now it is.
I’ll do some more testing to see if I can determine a pattern here. @Jarrett, the bug still exists in WIndows 10 (and apparently WIndows 11).
And I was just able to replicate the other issue with missing grid squares. Using Hamdb.org as my lookup service, I entered a call and all of the QTH info was displayed, including the grid square, but the grid square wasn’t saved in the record. The remaining look-up info was saved properly.
I entered the same call a few minutes later, and the grid square was displayed again AND it was saved that time in the QSO record.
Doing a look-up for the first QSO entry populated the missing grid square.
I can’t determine a pattern for either of these bugs (date/time pause and grid square population). For me, these work sometimes and they don’t other times.
For instance, at the moment I can’t replicate the time pause issue again, despite doing everything the same.
I just entered a test log file and did not have any issues with times changing. However, I did have just 3 out of 13 (less one Swedish contact) populate the Grid Square. I did go into edit and found that the grids were NOT there, contrary to what I wrote previously. I will send you my adif at the address you provided. I tried capturing video, in case I could capture the date reversion “live”. But since that didn’t happen, there’s no use in sending that.
Baaaah. This is maddening. I wrote so many tests for this during the last pass. Ok. So looks like I need to focus on Windows for this one. I haven’t had a chance to replicate but I’ll look into it this sprint.
I am using HamDB, but I have had similar results with the other services.
I can’t speak to pausing, and how that affects things. I think in the test that I sent you had 2 back to back PR contacts that wouldn’t have had any pause in the entry.
If you think it helpful, I can try another service in my lookups and see if there is any difference. I really think I have done this already, but anything is worth a try.
@w4maf Mike, does this behavior clear up if you completely close HAMRS on your WIndows device and restart it? I assume you are also pressing the clock button to pause it (should turn red when paused).
@KZ3L Yes, I am pausing by pressing the clock (turns red). I THINK a PC reboot will pause the clock which only temporarily resolves the issue. I’ve got 30 paper logs to upload and about to reboot in an effort to digitize one of the 30 logs. If the reboot doesn’t work… I’ll probably hold off for the next update before working on these logs or try from another PC which runs Windows 7. That just might be “the ticket”. Thanks for asking which may lead me to a work around. If I have the same issue with Windows 7, I’ll share that with the group.
