locked Re: Not ignoring /MM stations - ISSUE Found, ACLog Defect

JTAlert Support (VK3AMA)


Thanks for your ACLog file. I provided me with the clue as to what was happening.

JTAlert when it performs the rebuild operation pre-loads the log into a fast memory-based database. This applies to all the supported log types, not just ACLog. This allows for a standard set of routines to be run against a very fast lookup database that is independent of the differences in the different logs (lack of indexes, inconsistent data recording, missing data, bad qsos, etc). This operation does not consider callsigns, just the raw data recorded for each QSO in the log. It ignores Country names, which can be spelt differently on different systems and relies on the unique dxcc number recorded in the QSO to determine dxcc needs. That was the problem.

ACLog, while it correctly had no Country name recorded in the log for /MM stations, it incorrectly recorded dxcc numbers for /MM stations. That is a defect in ACLog IMO. /MM QSOs should have no dxcc number recorded. JTAlert was seeing the dxcc number and the confirmations set for the /MM QSOs and applying credit during the rebuild.


Check you email, I have sent you a new JTAlert build to test. Let me know if this works for you.

Note: During this testing, there were some additional /MM callsigns in your log that were given incorrect credit. I note that on 17m you had credit for Ukraine due to the UW5EJX/MM QSO. Once I coded the ACLog /MM patch into JTAlert, your 17m credit count was reduced by 2 rather than the expected one for the RA0LQ/MM qso only.

de Laurie VK3AMA

Join Support@HamApps.groups.io to automatically receive all group messages.