search

magicbug / Cloudlog

Web based amateur radio logging application built using PHP & MySQL supports general station logging tasks from HF to Microwave with supporting applications to support CAT control.
http://www.cloudlog.co.uk
MIT License
456 stars 188 forks source link

Incorrect CQ Zones search not finding incorrect CQ zones #2175

Closed bhtooefr closed 1 year ago

bhtooefr commented 1 year ago

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.

AndreasK79 commented 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.

bhtooefr commented 1 year ago

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):

  1. Use the reported state. (Not available in the modes WSJT-X uses, so irrelevant to this specific GridTracker case, but if you directly got a state in the QSO, that's totally accurate.)
  2. Use the grid square. If you got the grid square in the QSO, and the grid square doesn't straddle a CQ zone line, this is totally accurate. If it does straddle a line, guess (using a few ways).
  3. Use the state determined from the callsign lookup. (I know GridTracker uses this for wanted state checks, and ignores the grid square, because I've seen a few cases where it reports the state the operator has registered with the FCC, but the grid square is somewhere else entirely. Honestly, I feel like that's a bug on its part, and the grid square should take precedence over the address for that. It doesn't log the state into Cloudlog, though, at least.)
  4. Use the callsign region. (Incredibly inaccurate because operators can operate and even have a registered address out-of-region, and because the 4, 7, and 8 callsign regions straddle CQ zone lines.)

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:

  1. If location information was found in the callsign lookup, and there's an available address or 6-character Maidenhead locator, and that location is within the reported grid square, use the CQ zone implied by that lookup. (Which is really just using the state from the callsign lookup, but only after verifying the grid square matches. And, I know GridTracker is doing this to put 6-character locators in the log when only a 4-character locator was reported.)
  2. If location information is unavailable or doesn't match, use the CQ zone that most of the grid square is in.
  3. Leave it empty if it's ambiguous?

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.

AndreasK79 commented 1 year ago

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.

phl0 commented 1 year ago

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.