Refresh Data (World Globe) Edit QSO changes ITU & CQ zones incorrectly.

[KS4VOL]

I am having some of the same problem that the others are or had with previous versions. (See https://forum.log4om.com/viewtopic.php?t=7524&start=10) My version is 2.31.0.0. I have noticed it since I moved to new QTH, so luckily the new log database is under 500 so easily put back to original after noticing that Refresh data doesn't work well it changes info ITU and CQ numbers on USA and Canada countries with multiple numbers depending on USA States or Canada location.
What I do is sometimes the FT8 mode when I use Log4OM 2.13.0.0, WSJT 2.6.1. and JTAlert 2.62 or manually log contact sometimes the name and address doesn't populate so I double click the contact QSO. Then I go to Refresh Data (world globe image) and have noticed both the ITU and CQ zones changes. I have populated quite a few of the QSO names so now they are wrong before I noticed the changes to ITU and CQ zones. For example VA3WHU Canada is ITU #4 and CQ #4. You go to Refresh Data and it will change it to ITU #2 and CQ #5 which is wrong to start with when originally logged and QRZ page. I checked the Onterio area from another website and it shows ITU #4 and CQ #4.

Hope this makes sense. LOL

I posted it with the others on https://forum.log4om.com/viewtopic.php?t=7524&start=10 and the posted fixes there didn't work as others have stated and I received zero response from my post so I thought I would post it as a new post.

If you need more info let me know.

Thanks all for the help.

[G4POP]

Try unchecking the 'Use CTY database' in the settings/program configuration/info providers/configuration tab

[KS4VOL]

Thanks for responding Terry. Tried both with and without checks and both times I logged out of Log4OM and logged in still changing the ITU and CQ Zones. I looked in the manual it shows them checked. I got something a foot. LOL Did you just out of curiosity try to log VA3WHU to see if you have the same problem? Here is the screenshot.

Screenshot (18).png (37.46 KiB) Viewed 633 times

Is there somewhere else I need to look? It seems the CQ and ITU source priority doesn't change don't know if it should.

Thanks again Terry for the response.

[KS4VOL]

Even if I check Use Clublog database still changes ITU and CQ zone.

[G4POP]

Then the info is probably coming from your on line lookup source, check that call on the QRZ web site to see if its correct on the web

[KI5IO]

Ken & Terry,

I am verifying the ITU/CQ Zone changes noted.

I am getting the same response as Ken as noted.

My source is QRZ.com (XML Data Member) and I've also confirmed that the zones are properly noted at QRZ.com. I've also confirmed the 6-digit grid as belong to ITU-4 and CQ-4.

I've tested both with CTY and Clublog on and off. Log4OM (for some reason) says that VA3WHU has ITU-2 and CQ-5.

My results are from manually entering VA3WHU in the callsign field in the Main UI.

I do not have any FTxx 3rd party APPs installed on my computer ... thus they are not impacting the data.

I also did a test with QRZ.com (off) and used HamQTH as the primary data source and the data provided there was FB with ITU-4 and CQ-4.

So it appears that the XML download data is different than what we see when logging into QRZ.com. Pretty sure that is a common occurrence. Probably more issues with QRZ.com that are just ongoing.

I've tested the same callsign on 2 other loggers and they provide the proper ITU-4 and CQ-4 Zones. QRZ.com is also the main source for data for those loggers as well.

Something is amiss inside Log4OM. Probably should advise Lele.

[KS4VOL]

Nolan Kienitz - KI5IO Thank you for your in depth research.

Yes USA is changed if not in the ITU 6 and CQ 5 zones State side. It seems that REFRESH DATA is defaulted to ITU 6 and CQ 5 zones. That is how I noticed it. It wasn't just the one call. Then I noticed after looking closer it was also the ITU. As living in the USA you notice the CQ zones not being right. Just try any manually or automatic logged USA callsigns and you will see it changes them to the default ITU 6 and CQ 5 zones.

I just tried six more USA logged contacts and they changed to a default ITU 6 & CQ 5. I checked a call from those zones and of course they stayed 6 & 5. So it seems any call outside the 6 & 5 zones in USA is the problem.

Let me know what is found out.

Thank You again Terry & Nolan

[IW3HMH]

The problem is an unexpected behaviour in the XML response from QRZ.COM
It doesn't contains any CQ/ITU zone. The function is passing the QSO through the external engine, assuming it's updating the relevant data (and assuming CQ and ITU are always available).
in this case the default value is passed to the external engine but is not updated, so the passed one is assumed to have been validated by external source, that is wrong.

<Callsign>
<call>VA3WHU</call>
<aliases>CF3WHU</aliases>
<dxcc>1</dxcc>
<fname>Carole A KIng</fname>
<name>VA3WHU</name>
<addr1>136 mountville Ave</addr1>
<addr2>Hamilton</addr2>
<state>on</state>
<zip>L9A1E5</zip>
<country>Canada</country>
<lat>43.249204</lat>
<lon>-79.865112</lon>
<grid>FN03bf</grid>
<ccode>49</ccode>
<land>Canada</land>
<expdate>0000-00-00</expdate>
<codes>W</codes>
<email>caz63_ca@yahoo.com</email>
<u_views>4496</u_views>
<bio>374</bio>
<biodate>2021-04-30 13:59:29</biodate>
<image>https://cdn-xml.qrz.com/u/va3whu/IMG_0048.JPG</image>
<imageinfo>549:601:96889</imageinfo>
<moddate>2021-07-04 15:12:46</moddate>
<eqsl>1</eqsl>
<mqsl>1</mqsl>
<born>1963</born>
<lotw>0</lotw>
<user>VA3WHU</user>
<geoloc>user</geoloc>
<name_fmt>Carole A KIng VA3WHU</name_fmt>
</Callsign>

[G4POP]

So the short answer is that the zone data you see on the QRZ website is not being transmitted in the xml file sent by qrz via API?

[IW3HMH]

Yes
as i was assuming the data was always available, when i passed the QSO through the external source (containing default 5/2) i assumed the output was validated in all fields.
As external source has priority over CTY, usually, the CTY data (that are valid, 4 / 4) are not used because QRZ doesn't have the data and the default was 5/2

I've changed a bit (a lot) the logic under that, not updating country/cq/itu inside the external source routine but passing out as standard value to the external priority engine.
That fixed the issue (non regression checks must be performed, but seems ok so far)

If someone wants to test the latest alpha:

ALPHA release with installer
https://www.log4om.com/l4ong/release/al ... 0_1619.zip
ALPHA release (portable edition)
https://www.log4om.com/l4ong/release/al ... 0_1619.zip