Closed bhtooefr closed 1 year ago
The search is not failing, but US QSOs are in zone 3, 4 or 5. It will be the same for all DXCC's that have several CQ zones. VE, K, VK, UA9/0 all comes to mind with the same problem.
Cloudlog doesn't know the correct zone when logging either. Unless it is provided in the information sent to Cloudlog via the API. for US it will be set to 5.
Ah, so it's more that it's incomplete than a bug per se.
I'm not sure which method GridTracker is using to determine zone (for its wanted zone check), there's four ways (one of which it can't be doing because it can't get that from the QSO) I can see to do it in decreasing order of preference (but it doesn't seem to be reporting it in the log entry, then):
Ways I can think of to guess the CQ zone of a the grid square straddling a zone line, if you didn't get a state in the QSO:
I suspect for Cloudlog, the best approach would be using the state, then the grid square, and then (to avoid unnecessary lookups for ambiguous grid squares) using the CQ zone that the majority of the grid square is in, or leaving it empty.
Another suggestion: is it possible for Cloudlog to get the fixed up CQ zones back from, for example, LoTW when checking for confirmation? I know it can correct the zones, as I've got plenty that it had to correct over there.
Compared to the steps you list (which are very good), the check is incomplete.
We have a table in the database that has all CQ zones for each DXCC. A query is run against that table, and lists those QSOs with CQ zones that are not found for that DXCC. It is very basic, but it was never written to determine the CQ zone for a DXCC.
If someone wants to improve this and write a function that determines the CQ zone, feel free to make a code contribution.
I will add a text to the page to inform that DXCC's with several CQ zones, will not be shown as incorrect if the zone exist in that DXCC. It is not a tool to determine the correct zone, only to show zones that does not exists in the logged DXCC.
As for the LoTW confirmation, the code does not set the CQ zone.
I made a patch in https://github.com/magicbug/Cloudlog/pull/2179 that allows to pull CQ and ITU zone data from LoTW confirmations. At least a partial fix.
On my install of Cloudlog 2.4.2 on FreeBSD 12.4, it appears that the incorrect CQ zones search is failing to find incorrect CQ zones for US QSOs, at least when using Vivaldi 6.0.2979.18 (Stable channel) (64-bit) on Windows 10.
It appears all of my lower 48 US contacts were also logged as CQ zone 5, when some are CQ zone 3 or 4 - not sure if this was GridTracker (which is injecting the QSOs) or Cloudlog's fault, but I'd at least expect the search to find the incorrect ones.