Log4OM

N6VH wrote: 28 Apr 2020, 20:09 FWIW, I use WSJT-X and JTAlert, and I have never had a Zone 0 entered in my log from that combination. I don't normally use lookups from QRZ, HamQTH, etc.

I do not use JTAlert, and I do use QRZ XML for lookups.

My WSJT-X contacts are fed to Log4OM via UDP connection.

Almost all USA contacts, and occasional DX contacts are recorded as CQ Zone 0.

Perhaps it all has to do with the order of info providers ?
FWIW exporting & importing is by now way a solution. It's a workaround which is not good at all and a possible source for other trouble.

Isaac 4Z1TL

K0HB wrote: 29 Apr 2020, 04:36
I do not use JTAlert, and I do use QRZ XML for lookups.

My WSJT-X contacts are fed to Log4OM via UDP connection.

Almost all USA contacts, and occasional DX contacts are recorded as CQ Zone 0.

This could be why zone 0 is showing up. QRZ doesn't have a zone listed for every call. Log4OM doesn't have any other way of knowing what zone a station is in, so it must be purring a "0" in the zone field. This seems to have changed from earlier versions, including v1. In earlier versions, Log4OM would put "5" in the zone field, if it didn't know what the zone should be (speaking about stateside stations here). Actually, I prefer the "0" to be used in this situation. It is easy to find all qsos that have a zone 0 entered, using QSO Manager. Then you can use whatever means you can to make the correction. Incidentally, I have found that HamQTH seems to have some zones listed where QRZ doesn't. No guarantees, however.

73,

Jim N6VH

N6VH wrote: 29 Apr 2020, 20:32

K0HB wrote: 29 Apr 2020, 04:36
I do not use JTAlert, and I do use QRZ XML for lookups.

My WSJT-X contacts are fed to Log4OM via UDP connection.

Almost all USA contacts, and occasional DX contacts are recorded as CQ Zone 0.

This could be why zone 0 is showing up. QRZ doesn't have a zone listed for every call. Log4OM doesn't have any other way of knowing what zone a station is in, so it must be purring a "0" in the zone field. This seems to have changed from earlier versions, including v1. In earlier versions, Log4OM would put "5" in the zone field, if it didn't know what the zone should be (speaking about stateside stations here). Actually, I prefer the "0" to be used in this situation. It is easy to find all qsos that have a zone 0 entered, using QSO Manager. Then you can use whatever means you can to make the correction. Incidentally, I have found that HamQTH seems to have some zones listed where QRZ doesn't. No guarantees, however.

73,

Jim N6VH

Slight thread drift here:

I've noticed generally that HamQTH provides a 4-dit grid ID and QRZ (more times than not) has a 6-digit grid ID.

And ... that has little to nothing to do with a "0" zone field.

Just an observation.

I've made 34 contacts in the last 3 days using ver 2.5 and have 6 contacts logging ITU=6 and CQ=0. If I go into edit of these contacts and hit refresh, 4 of them update to ITU=8 CQ=5 which is correct for their gridsquare.

One is gridsquare EM13 which should be ITU=7 CQ=4 and it refreshes to ITU=6 CQ=5.
Another is gridsquare EM66 which should be ITU=8 CQ=4 and it refreshes to ITU=8 CQ=5.

The contacts were logged from JTAlert 2.16.4 with WSJT-X 2.1.2. Lookups occur only in Log4OM and I'm using QRZ.

The 0 zones are brand new with 2.5 however zones getting goofed up while in edit have been this way since I changed to V2. I can't say what happened in V1, never noticed.

There were some other threads regarding the zone problem but it related to manual entry of a QSO and having fields locked vs unlocked. I've never been able to figure out any pattern for the zones changing to bad values when I refresh while in edit.

I don't mean to hi-jack this thread with this additional info.

New information relative to this issue:

This evening I ran a hundred or so CW QSO's, feeding Log4OM from N1MM+.

All QSO's from N1MM+ were recorded on Log4OM with the CORRECT CQ zone.

Then I went to FT8 (WSJT-x) for a few QSO's. Several of them were recorded as Zone 0.

Another tidbit:

I upload all QSO's to LoTW. If QSO originally recorded as a "Zone 0" is matched in LoTW, then the CQ & ITU zones are corrected in Log4OM.

We made Log4OM less "precise" but more coherent in V. 2.5
Log4OM use some sources to retrieve correct data from available sources we have: CTY file, Clublog and, of course, QRZ.COM/HAMQTH/QRZCQ/HAMCALL

The priority order is always the data coming from external source, so if N1MM is providing a CQ zone (and it usually does, as many callsigns are registered in the CTY.DAT file), Log4OM imports that value.

Other sources are applied in the order specified in the settings, between external sources, clublog and CTY.DAT file, if CQ data is missing.
If no sources provide a valid value, then ZERO is set, as it's an "invalid value" and doesn't inserts "fake" data into your log.
That is not true for realtime registered QSO (from the user interface), as the user has the possibility (and the duty) to check data provided by Log4OM during lookup in order to apply necessary corrections, as you're the last responsible of your data.

Finally, when reporting those issues, always include a callsign, an adif string or something that can help us finding how the application is answering in the specific situation and eventually be able to intercept and correct issues.

Checked my log and found a few CQzone = 0 coming from JTDX. Also a few from older contacts
are logged with V1 from 2017. So not only a problem in V2. Have used the filter CQzone <equals> 0
in QSO Manager filter settings. After select the 66 matches and hit "Update Info" for 26 of them a
correct zone was found. For the other 40 contacts no CQzone could be found at HamQTH. That´s
stations like Z6xxx or /MM or things like this.

Only a short info about my CQzone 0 tests ...

I just worked KB5RGH. Log4OMv2 2.5.0.0. WSJTX v2.1.2. His grid showed EM20wa, ITU 7, CQ 4 on Main UI screen. When I logged the QSO, it recorded grid OK as EM20wa, but changed to ITU 6, CQ 0. Went to Edit QSO and ran Update using the globe, and it updated to ITU 7, CQ 4. Found many CQ 0's back to when I first loaded 2.5.0.0 on April 22. See attached. 73 Herb WB8ASI

WB8ASI wrote: 02 May 2020, 00:58 I just worked KB5RGH. Log4OMv2 2.5.0.0. WSJTX v2.1.2. His grid showed EM20wa, ITU 7, CQ 4 on Main UI screen. When I logged the QSO, it recorded grid OK as EM20wa, but changed to ITU 6, CQ 0. Went to Edit QSO and ran Update using the globe, and it updated to ITU 7, CQ 4. Found many CQ 0's back to when I first loaded 2.5.0.0 on April 22. See attached. 73 Herb WB8ASI

Herb,

Nothing attached to your post.

Pls try again.