Hello,
having done a little contest this Weekend (IARU Contest), I import the ADIF file generated by DXLog into Log4OM (in a test database) looking I find at least 2 errors in the CQ zones
In the contest ADIF file:
VE7ZO and VE7LWW have the ITU Zone = 2 (in this ADIF file there is no CQ zone) and when importing with option 1 - Apply quality check corrections Lo4OM sets the CQ zone for these 2 QSOs = 5
whereas normally it is not CQ=5 but CQ=3
So it's not a big deal I only have 2 QSOs I can change manually
But what concerns me is that I wonder if there are other errors of this kind and therefore how to identify these possible errors?
I also did Utilities / QSO Manager by selecting all the QSOs made during this contest and asking for "UpdateInfo" but that doesn't change anything, the CQ zone remains = 5
Is it a Bug?
Or is there a way to make sure you don't get other errors like this?
Thank you for your advice
I attach the input ADIF file for possible tests
73
CQ zone problem during an import
CQ zone problem during an import
Dan - F6FLU
Log4OM V2.35.1.0 - Windows 11 - i9-11900K - SSD 512Go - 32 Go
FTdx101D - Hexbeam - Wire dipole 40-30M
https://F6FLU.org
Log4OM V2.35.1.0 - Windows 11 - i9-11900K - SSD 512Go - 32 Go
FTdx101D - Hexbeam - Wire dipole 40-30M
https://F6FLU.org
- G4POP
- Log4OM Alpha Team
- Posts: 11592
- Joined: 21 Jan 2013, 14:55
- Location: Burnham on Crouch, Essex UK
Re: CQ zone problem during an import
What online lookup source are you using?
When you do a Utilities/qso manager update info it will not change existing information it only adds missing information - Like 'Updates'
When you do a Utilities/qso manager update info it will not change existing information it only adds missing information - Like 'Updates'
73 Terry G4POP
Re: CQ zone problem during an import
Thank you Terry for your help
73
I'm not sure I understand the question?
OK, I understandG4POP wrote: 14 Jul 2024, 22:30 When you do a Utilities/qso manager update info it will not change existing information it only adds missing information - Like 'Updates'
73
Dan - F6FLU
Log4OM V2.35.1.0 - Windows 11 - i9-11900K - SSD 512Go - 32 Go
FTdx101D - Hexbeam - Wire dipole 40-30M
https://F6FLU.org
Log4OM V2.35.1.0 - Windows 11 - i9-11900K - SSD 512Go - 32 Go
FTdx101D - Hexbeam - Wire dipole 40-30M
https://F6FLU.org
Re: CQ zone problem during an import
Tested but it doesn't change anything I still get CQ=5
Dan - F6FLU
Log4OM V2.35.1.0 - Windows 11 - i9-11900K - SSD 512Go - 32 Go
FTdx101D - Hexbeam - Wire dipole 40-30M
https://F6FLU.org
Log4OM V2.35.1.0 - Windows 11 - i9-11900K - SSD 512Go - 32 Go
FTdx101D - Hexbeam - Wire dipole 40-30M
https://F6FLU.org
- G4POP
- Log4OM Alpha Team
- Posts: 11592
- Joined: 21 Jan 2013, 14:55
- Location: Burnham on Crouch, Essex UK
Re: CQ zone problem during an import
I just realised that your referring to an imported log!
What zone is in the adif you exported from the other software, again we don't change incoming data during an import so if the zone is wrong in the incoming file we don't change it
What zone is in the adif you exported from the other software, again we don't change incoming data during an import so if the zone is wrong in the incoming file we don't change it
73 Terry G4POP
Re: CQ zone problem during an import
Terry
I gave my import file on this link and I specified that in the import file there is no CQ zone just the ITU zone

I gave my import file on this link and I specified that in the import file there is no CQ zone just the ITU zone


Dan - F6FLU
Log4OM V2.35.1.0 - Windows 11 - i9-11900K - SSD 512Go - 32 Go
FTdx101D - Hexbeam - Wire dipole 40-30M
https://F6FLU.org
Log4OM V2.35.1.0 - Windows 11 - i9-11900K - SSD 512Go - 32 Go
FTdx101D - Hexbeam - Wire dipole 40-30M
https://F6FLU.org
- G4POP
- Log4OM Alpha Team
- Posts: 11592
- Joined: 21 Jan 2013, 14:55
- Location: Burnham on Crouch, Essex UK
Re: CQ zone problem during an import
Puzzled!F6FLU wrote: 15 Jul 2024, 13:07 Terry
I gave my import file on this link and I specified that in the import file there is no CQ zone just the ITU zone
![]()
![]()
Entering those calls manually obtains the correct zones and they are logged as such
Importing the DXLog ADIF file with corrections selected adds, as you said, the incorrect zone
Importing WITHOUT corrections selected also adds the incorrect zone! - It should do nothing so there should be an empty field because there is no data in the ADIF?
Adding the missing zone data for those VE7 stations to the ADIF and then importing is OK!
So I think you should send a support request to Lele, please include the DXLog ADIF - Send to lele(AT)pisto.it
Be patient because he had an accident and is not oftern on the PC as he is mostly in bed
73 Terry G4POP
- IW3HMH
- Site Admin
- Posts: 2988
- Joined: 21 Jan 2013, 14:20
- Location: Quarto d'Altino - Venezia (ITA)
- Contact:
Re: CQ zone problem during an import
It's not technically a bug...
the only reliable source of CQ and ITU zones, when importing a QSO (so not using online resources) is Clublog exception file or the CTY.DAT file (from those guys: https://www.country-files.com/cty-dat-format/ ).
This file changes often, so actually Log4Om uses the info in the file only if the QSO is generated realtime (qso date = current date) or when importing an ADIF file with QSO created in the same date the PC is running (today).
That's because the quality of the information is not guarantee if the QSO is old, as this datasource usually "follows" operators movements and may change often.
That's a "restrictive approach" to ensure maximum reliability of the data, but in some cases the quality provided by the file is better than nothing (log4om country default file) even if the QSO is not actual.
To mitigate the issue i've added a check that, for CTY.DAT usage, will consider QSO's in the last 30 days to be "actual", allowing users to load ADIF produced in the last month and apply fixes to them as they were "actual" (aka using CTY.DAT file)
Will be available in the next release, after testing.
the only reliable source of CQ and ITU zones, when importing a QSO (so not using online resources) is Clublog exception file or the CTY.DAT file (from those guys: https://www.country-files.com/cty-dat-format/ ).
This file changes often, so actually Log4Om uses the info in the file only if the QSO is generated realtime (qso date = current date) or when importing an ADIF file with QSO created in the same date the PC is running (today).
That's because the quality of the information is not guarantee if the QSO is old, as this datasource usually "follows" operators movements and may change often.
That's a "restrictive approach" to ensure maximum reliability of the data, but in some cases the quality provided by the file is better than nothing (log4om country default file) even if the QSO is not actual.
To mitigate the issue i've added a check that, for CTY.DAT usage, will consider QSO's in the last 30 days to be "actual", allowing users to load ADIF produced in the last month and apply fixes to them as they were "actual" (aka using CTY.DAT file)
Will be available in the next release, after testing.
Daniele Pistollato - IW3HMH
Re: CQ zone problem during an import
OK Lele many many thanks
Dan - F6FLU
Log4OM V2.35.1.0 - Windows 11 - i9-11900K - SSD 512Go - 32 Go
FTdx101D - Hexbeam - Wire dipole 40-30M
https://F6FLU.org
Log4OM V2.35.1.0 - Windows 11 - i9-11900K - SSD 512Go - 32 Go
FTdx101D - Hexbeam - Wire dipole 40-30M
https://F6FLU.org