CQ Zone "0"

[WB8ASI]

Sorry. Had trouble getting pic to attach.

[NS8K]

A couple nights ago I worked WB2UBW via WSJT-X / JTAlert. He should log as ITU=8, CQ=4. He logged as 6 0 instead. Here's my Info Provider Config.

Config2.png (17.55 KiB) Viewed 4686 times

I then just keyed this call into the UI. It shows Zones 8 5.

UI1.png (8.02 KiB) Viewed 4688 times

To figure out what was going on, I changed the Realtime Logging config to CTY None None. Keying the call into the UI gave Zones 8 0.
Changed Realtime Loging config to Clublog None None. Results were 6 5.
Changed Realtime Logging config to External None None (using QRZ). Results were 6 0.
Left Realtime Logging config the same but changed External source to HAMQTH. Results were 8 4.

It looks to me like with CTY Clublog External(QRZ or HAMQTH) it is retrieving ITU=8 from CTY and then it goes to Clublog to get CQ=5. When the "transaction" comes from JTAlert it logs 6 0 if External is set to QRZ and logs 8 4 if External is set to HAMQTH. It does not seem to go down through the priority list, it just uses the XML lookup. HAMQTH lists 8 4 for zones, QRZ lists nothing for zones.

One last thing, if I bring up the logged QSO in Edit and click on the Globe to refresh data, the zones change from 6 0 (or 8 4 if it had been logged using HAMQTH) to 6 5. That makes sense because Clublog is first priority for Historic QSOs although 6 5 certainly is not correct.

This is just one example of these very confusing and incorrect zone retrievals. I hope it helps.

[N6VH]

Tom,

I just did a test log of WB2UBW, from WSJT-X/JTAlert. The correct zones were logged. For real-time logging, I have my configuration set the same as yours, except I don't use lookups from external sources (QRZ, etc.). Try turning off look-ups from external sources, and then do a test log using WB2UBW, and see if you get the correct fields logged. It is possible that JTAlert is sending the correct zones, but that the external lookup might be over-riding them. Might be worth checking.

73,

Jim N6VH

[NS8K]

I just did a test log of WB2UBW, from WSJT-X/JTAlert. The correct zones were logged. For real-time logging, I have my configuration set the same as yours, except I don't use lookups from external sources (QRZ, etc.). Try turning off look-ups from external sources, and then do a test log using WB2UBW, and see if you get the correct fields logged. It is possible that JTAlert is sending the correct zones, but that the external lookup might be over-riding them. Might be worth checking.

73,

Jim N6VH

Jim,

I was hoping you would chime in, what an interesting idea. I did as you suggested and saw the same result you did. When logged from WSJT-X/JTAlert (without a look-up in JTAlert) the QSO is logged correctly as 8 4. When I just key WB2UBW in the UI I still get 8 5 just as I did before. That seems consistent, with 8 coming from CTY and the 5 coming from Clublog (if my analysis there was correct). Having or not having an external lookup at priority 3 wouldn't matter.

I did a little testing and indeed, JTAlert is properly sending 8 4 for the zone information. I don't know what Laurie's source is but it is correct. It seems maybe you are right, that information coming over is being overwritten by a Log4OM lookup which does not use the priority established in the Info Providers setup. It just does a straight XML lookup if enabled.

You made a comment earlier that was interesting to me. It was that 5 used to be supplied when the CQ zone was not known. In my log I have lots of invalid zone combinations, 6 5 being a very common one which is a west coast ITU and east coast CQ. With the current software perhaps those would be 6 0. I agree that 0 is better than 5 because it is obviously wrong and it comes to your attention.

[OZ2LC]

My setup up does the samething , hopeing for a fix , thanks for your work, please post a solution , incl pictures it easyer to see and compare

[WB8ASI]

Another WB2UBW test: Turned External Sources to "None" for Running and History. Logged from WSJTX and got 6 0. Updated with globe and got 8 5. Turned External Sources back on for both Running and History. Logged from WSJTX and got same 6 0. Updated with globe and got same 8 5. Looked in JTAlert Log Fields and see the correct 8 4. It's not coming across for me. Totally confused. 73 Herb WB8ASI

[N6VH]

Another WB2UBW test: Turned External Sources to "None" for Running and History. Logged from WSJTX and got 6 0. Updated with globe and got 8 5. Turned External Sources back on for both Running and History. Logged from WSJTX and got same 6 0. Updated with globe and got same 8 5. Looked in JTAlert Log Fields and see the correct 8 4. It's not coming across for me. Totally confused. 73 Herb WB8ASI

Herb,

When you said you logged from WSJT-X, is that straight from WSJT-X, or are you using JTAlert to do the logging? WSJT-X probbnly won't supply any zone information at all, but if it's coming from JTAlert it should be correct, in most cases.

73,

Jim N6VH

[WB8ASI]

Jim, I'm entering the callsign into the "DX Call" field on WSJTX, and then clicking the "Log QSO" button above on WSJTX. The WSJTX Log QSO window pops open and I hit OK. Guess I don't know how to log directly from JTAlert??? Herb WB8ASI

[N6VH]

Jim,

I was hoping you would chime in, what an interesting idea. I did as you suggested and saw the same result you did. When logged from WSJT-X/JTAlert (without a look-up in JTAlert) the QSO is logged correctly as 8 4. When I just key WB2UBW in the UI I still get 8 5 just as I did before. That seems consistent, with 8 coming from CTY and the 5 coming from Clublog (if my analysis there was correct). Having or not having an external lookup at priority 3 wouldn't matter.

I did a little testing and indeed, JTAlert is properly sending 8 4 for the zone information. I don't know what Laurie's source is but it is correct. It seems maybe you are right, that information coming over is being overwritten by a Log4OM lookup which does not use the priority established in the Info Providers setup. It just does a straight XML lookup if enabled.

You made a comment earlier that was interesting to me. It was that 5 used to be supplied when the CQ zone was not known. In my log I have lots of invalid zone combinations, 6 5 being a very common one which is a west coast ITU and east coast CQ. With the current software perhaps those would be 6 0. I agree that 0 is better than 5 because it is obviously wrong and it comes to your attention.

Tom,

I checked on Club Log, and they have zone 4 listed for WB2UBW. I then set Log4OM to use ONLY Club Log as a check during real time logging, and it still put WB2UBW in zone 5.

As far as Laurie's sources, I know that he uses cty.dat, but that doesn't have all possible exceptions in it. I checked, and the latest version of cty.dat doesn't have WB2UBW, for example. Laurie also uses info from the FCC, as well as LOTW and eQSL (the latter two are probably just to see who has uploaded to their services). He gets the state, probably from the FCC records. The correct zone can be determined from that in many, not all, cases. This might be how JTAlert comes up with the correct zone. Laurie is out of town presently, and not connected to the internet, so there is no way to ask him at this time.

73,

Jim N6VH

[N6VH]

Jim, I'm entering the callsign into the "DX Call" field on WSJTX, and then clicking the "Log QSO" button above on WSJTX. The WSJTX Log QSO window pops open and I hit OK. Guess I don't know how to log directly from JTAlert??? Herb WB8ASI

Herb,

If you don't have JTAlert setup to log to Log4OM, there are directions in the JTalert help file under "Logging \ Log4OM v2". There are also directions in the Log4OM user guide. If you do set up JTAlert to log to Log4OM, make sure you don't have WSJT-X also set to log to Log4OM - you will get duplicate logs.

73,

Jim N6VH