It isn’t showing up here on either card or table view. This is after I clicked on the “update” link at the bottom of the HAMRS page. (An additional idea occurred to me this morning: perhaps it might be useful to include the release number on the display just to ensure that what I’m reporting actually corresponds to the latest release?)
Hmmmm. I’ll add some extra tests for 40m conversion - is there another that’s wrong in your screenshot and I’m just not seeing it?
This looks like it was a server side error, with my api proxy, so I pushed it out - I did see an odd freq of like 14.xxx00000001, so something somewhere might be doubled-floated or something, so if you see some with a lot of useless digits, let me know.
Release 2.3.2
- Chore: added build version to app footer
Yeah there is definitely some type conversion oddity going on 
A few minutes ago, CW entry W3PYF, which was at 14.0599 was being shown in HAMRS as 14.058999999 or some such. JL!CQT/1 shown on the POTA site at 7002.9 is shown in HAMRS at 7.0028999999999995.
2 Likes
Just pushed out another API fix. Wrote a test and found the floating-point precision issue. You’d THINK dividing by 1000 would easy…
Floating point numbers can be surprising.
1 Like
When I open a new log the top right pane displays the info from my most recent activation. The only way to “fix” it is to correct the info in the right pane and then enter a “dummy” QSO. Otherwise, every time I open the “new” log it shows the info from the previous activation. I hope I’m making sense. Thanks for all the hard work!
Solid bug find! I’m on it.
When coming back to a HAMRS session after the computer has been sleeping for a few hours, callsign lookups don’t return anything (fMaybe telds remain blank). After a refresh, lookups resume as expected.
I am looking up in qrz.com with a paid subscription.
Maybe the connection gets logged out during the sleep and not logged back in after the lookup error?
The QRZ token does go stale after I think an hour, so I refresh it, but maybe something’s up when it’s sleeping. I’ll get a ticket going and investigate
2.6.3
- Fixed: fixed new logbooks using sticky fields from previous logbooks
Release 2.6.4
- Fixed: only require HH:MM for QSO Time On
- Fixed: refetch stale QRZ session key if error returned
Release 2.6.5
- Fixed: editing a previously saved QSO’s ‘Their Park’ field will now trigger Park lookup
- Fixed: updated time input colors for clarity
Any chance to include a TIME_ON validation? We’ve been receiving some logs from version 2.6.5 with invalid times, like 2447, 2449, 1397, 1575, etc. Obviously fat finger errors in transcribing from paper or not understanding 24-hour time format, but still in there and causing the log upload to fail.
Thanks and 73,
Michael WA7SKG
I’ll get on it right away.
@WA7SKG
I assumed something was able to get through on my end, but I can’t seem to replicate this…
Edit: Validation was missing on when editing QSOs. I’ll get a fix out in 10 mins.
Release 2.7.1
- fix: validate and mask time input when editing a QSO
Release 2.8.0
- Feature: users can now toggle Qso Table column visibility
I’m not quite figuring out what the toggle QSO Table feature is. Could I ask for a bit more info?;
Also I was wondering if you had a ticket for providing assistance in entering duplicate record to help with logging multiple operators. If not, could I request it as a feature?
Thanks!