Topics

locked Zones Problem


Jim N6VH
 


On 5/12/2020 3:04 PM, WB8ASI Herb wrote:
Jim,  I'm a Log4OM user.  I know I can change the column positions on log page, but can we change it on the Main UI window since that's where I look first?  That would be great.  73 Herb WB8ASI


Herb,

I see what you mean. No, I don't think that can be changed. That would be an issue for the Log4OM team.

73,

Jim N6VH


WB8ASI Herb
 

Jim,  I'm a Log4OM user.  I know I can change the column positions on log page, but can we change it on the Main UI window since that's where I look first?  That would be great.  73 Herb WB8ASI

On May 12, 2020 at 12:18 PM Jim N6VH <N6VH@...> wrote:


On 5/11/2020 10:13 PM, HamApps Support (VK3AMA) wrote:
On 12/05/2020 12:11 pm, Joe Subich, W4TV wrote:

Please don't!  CQ is the only one that is associated with a useful award
and should always come first.  I would not even mind if ITU zone were
not displayed at all.

73,

   ... Joe, W4TV

Don't worry Joe there will be no changes.

I have always referred to zone pairs as CQ first ITU second. To me it feels more natural because "C" comes before "I" in the alphabet I am guessing.
 
Referring to the Gold-Standard, DXLab, I note DXView is CQ first, same for DXKeeper and the Capture window. A qucik look at ACLog it is the same. I don't bother checking any other loggers.

de Laurie VK3AMA


 


Jim N6VH
 


On 5/11/2020 10:13 PM, HamApps Support (VK3AMA) wrote:
On 12/05/2020 12:11 pm, Joe Subich, W4TV wrote:

Please don't!  CQ is the only one that is associated with a useful award
and should always come first.  I would not even mind if ITU zone were
not displayed at all.

73,

   ... Joe, W4TV

Don't worry Joe there will be no changes.

I have always referred to zone pairs as CQ first ITU second. To me it feels more natural because "C" comes before "I" in the alphabet I am guessing.
 
Referring to the Gold-Standard, DXLab, I note DXView is CQ first, same for DXKeeper and the Capture window. A qucik look at ACLog it is the same. I don't bother checking any other loggers.

de Laurie VK3AMA

_._,_._,_


Laurie,

In Log4OM, the order of the columns can be arranged in any order, so I have mine arranged with CQ first, then ITU.

73,

Jim N6VH


HamApps Support (VK3AMA)
 

On 12/05/2020 12:11 pm, Joe Subich, W4TV wrote:

Please don't!  CQ is the only one that is associated with a useful award
and should always come first.  I would not even mind if ITU zone were
not displayed at all.

73,

   ... Joe, W4TV

Don't worry Joe there will be no changes.

I have always referred to zone pairs as CQ first ITU second. To me it feels more natural because "C" comes before "I" in the alphabet I am guessing.
 
Referring to the Gold-Standard, DXLab, I note DXView is CQ first, same for DXKeeper and the Capture window. A qucik look at ACLog it is the same. I don't bother checking any other loggers.

de Laurie VK3AMA


WB8ASI Herb
 

OK Joe. Consistency is good for me, but atleast you have a reason.

On May 11, 2020 at 10:11 PM "Joe Subich, W4TV" <lists@subich.com> wrote:



So maybe switch the order of the ITU and CQ postions on the JTA Fields Window......
Please don't! CQ is the only one that is associated with a useful award
and should always come first. I would not even mind if ITU zone were
not displayed at all.

73,

... Joe, W4TV


On 2020-05-11 9:29 PM, WB8ASI Herb wrote:
Happy to report that Terry responded in the Log4OM forum that the Zone problem should be fixed in the next release.  Now my SUGGESTION BOX item for JTALERT is that since I've been focused on zone problems, I'm used to reading them ITU then CQ.  The only place they are reversed is on the JTA Log Fields Window.  Not a big deal, but just a cosmetic item for when you are comparing screens from different sources reading left to right it's a quick stumble for an old brain.   So maybe switch the order of the ITU and CQ postions on the JTA Fields Window......unless I've stumbled upon another US vs Metric thing, or Month/Day switcheroo, or what side of the road to drive on kinda custom. LOL.  Thanks. 73 Herb WB8ASI




Joe Subich, W4TV
 

So maybe switch the order of the ITU and CQ postions on the JTA Fields Window......
Please don't! CQ is the only one that is associated with a useful award
and should always come first. I would not even mind if ITU zone were
not displayed at all.

73,

... Joe, W4TV


On 2020-05-11 9:29 PM, WB8ASI Herb wrote:
Happy to report that Terry responded in the Log4OM forum that the Zone problem should be fixed in the next release.  Now my SUGGESTION BOX item for JTALERT is that since I've been focused on zone problems, I'm used to reading them ITU then CQ.  The only place they are reversed is on the JTA Log Fields Window.  Not a big deal, but just a cosmetic item for when you are comparing screens from different sources reading left to right it's a quick stumble for an old brain.   So maybe switch the order of the ITU and CQ postions on the JTA Fields Window......unless I've stumbled upon another US vs Metric thing, or Month/Day switcheroo, or what side of the road to drive on kinda custom. LOL.  Thanks. 73 Herb WB8ASI


WB8ASI Herb
 

Happy to report that Terry responded in the Log4OM forum that the Zone problem should be fixed in the next release.  Now my SUGGESTION BOX item for JTALERT is that since I've been focused on zone problems, I'm used to reading them ITU then CQ.  The only place they are reversed is on the JTA Log Fields Window.  Not a big deal, but just a cosmetic item for when you are comparing screens from different sources reading left to right it's a quick stumble for an old brain.   So maybe switch the order of the ITU and CQ postions on the JTA Fields Window......unless I've stumbled upon another US vs Metric thing, or Month/Day switcheroo, or what side of the road to drive on kinda custom. LOL.  Thanks. 73 Herb WB8ASI


Jim N6VH
 


On 5/10/2020 6:20 PM, WB8ASI Herb wrote:
...and Log4OM also has the correct zones in its Main UI window, however something goes wrong upon the logging of the QSO.  It happens over and over again.  Guess we need more chatter on the Log4OM forum to get some attention.  Jim, I switched to HamQTH per your suggestion.  73 Herb WB8ASI

Herb,

Testing with the call N3BNA, Log4OM has the zones as CQ 5 and ITU 6, and it gets logged that way. ITU should be 8. This happens whether I have Log4OM set to do no lookups, lookups from QRZ, or from HamQTH. It seems that if Log4OM doesn't know the correct zone, it enters either a "5" or "0" for the CQ zone and "6" for ITU. The odd thingis, HamQTH does have the correct zones, but they apparently weren't used, even when I had lookups set for HamQTH.

You're right - we should put this discussion on the Log4OM forum, since the problem is clearly not on the JTAlert end, and there is really nothing that can be done about it in JTAlert.

73,

Jim N6VH


WB8ASI Herb
 

...and Log4OM also has the correct zones in its Main UI window, however something goes wrong upon the logging of the QSO.  It happens over and over again.  Guess we need more chatter on the Log4OM forum to get some attention.  Jim, I switched to HamQTH per your suggestion.  73 Herb WB8ASI

On May 10, 2020 at 9:07 PM Jim N6VH <N6VH@...> wrote:

Dave,

That isn't true. Log4OM does receive the correct zones from JTAlert, unless JTAlert doesn't have a zone to send (very rare). The problem is what Log4OM does with the info. As I already said in an earlier post, if Log4OM is set to do lookups, it will overwrite the info that is sent to it from JTAlert. If it doesn't get the ifo from QRZ (or wherever) it puts in either a "0" or a zone number that might not be correct. In the case of a station in the US, that will be "5" for the CQ zone. As I said in an earlier post, I tested this both with and without using lookups in Log4OM. If I didn't have Log4OM do lookups, it used the zones sent to it from JTAlert. If I had Log4OM do lookups from QRZ, using a call that QRZ didn't have zones for, then it used arbitrary zone numbers rather than the zones from JTAlert. So, yes, Log4OM does get the zones from JTAlert. The problem is what it does with them.

73,

Jim N6VH

On 5/10/2020 4:03 PM, Dave Garber wrote:
That's what I was trying to say.  Log4om is not receiving any correct info on itu and cq zones from j talert.  

sent by my LG phone

On Sun, May 10, 2020, 6:21 PM HamApps Support (VK3AMA), < vk3ama.ham.apps@...> wrote:
On 10/05/2020 12:58 pm, Dave Garber wrote:
> I suspect an issue with adi from jtalert

It is not a JTAlert problem. If JTAlert shows zones in the log fields
area, that is what gets sent in the ADIF packet to Log4OM.

If a zone is unknown than there will be no zone data in the adif packet
sent. JTAlert deliberately does not send any Zone numbers if the value
is NOT greater than zero. Similarly any data fields that are empty the
corresponding adif field is simply not included in the adif packet. That
is JTAlert only includes adif fields for non-empty and non-zero (> 1)
data fields.

The problem is clearly with Log4OM V2.

de Laurie VK3AMA





 


Jim N6VH
 

Dave,

That isn't true. Log4OM does receive the correct zones from JTAlert, unless JTAlert doesn't have a zone to send (very rare). The problem is what Log4OM does with the info. As I already said in an earlier post, if Log4OM is set to do lookups, it will overwrite the info that is sent to it from JTAlert. If it doesn't get the ifo from QRZ (or wherever) it puts in either a "0" or a zone number that might not be correct. In the case of a station in the US, that will be "5" for the CQ zone. As I said in an earlier post, I tested this both with and without using lookups in Log4OM. If I didn't have Log4OM do lookups, it used the zones sent to it from JTAlert. If I had Log4OM do lookups from QRZ, using a call that QRZ didn't have zones for, then it used arbitrary zone numbers rather than the zones from JTAlert. So, yes, Log4OM does get the zones from JTAlert. The problem is what it does with them.

73,

Jim N6VH

On 5/10/2020 4:03 PM, Dave Garber wrote:
That's what I was trying to say.  Log4om is not receiving any correct info on itu and cq zones from j talert.  

sent by my LG phone

On Sun, May 10, 2020, 6:21 PM HamApps Support (VK3AMA), <vk3ama.ham.apps@...> wrote:
On 10/05/2020 12:58 pm, Dave Garber wrote:
> I suspect an issue with adi from jtalert

It is not a JTAlert problem. If JTAlert shows zones in the log fields
area, that is what gets sent in the ADIF packet to Log4OM.

If a zone is unknown than there will be no zone data in the adif packet
sent. JTAlert deliberately does not send any Zone numbers if the value
is NOT greater than zero. Similarly any data fields that are empty the
corresponding adif field is simply not included in the adif packet. That
is JTAlert only includes adif fields for non-empty and non-zero (> 1)
data fields.

The problem is clearly with Log4OM V2.

de Laurie VK3AMA





Dave Garber
 

That's what I was trying to say.  Log4om is not receiving any correct info on itu and cq zones from j talert.  

sent by my LG phone

On Sun, May 10, 2020, 6:21 PM HamApps Support (VK3AMA), <vk3ama.ham.apps@...> wrote:
On 10/05/2020 12:58 pm, Dave Garber wrote:
> I suspect an issue with adi from jtalert

It is not a JTAlert problem. If JTAlert shows zones in the log fields
area, that is what gets sent in the ADIF packet to Log4OM.

If a zone is unknown than there will be no zone data in the adif packet
sent. JTAlert deliberately does not send any Zone numbers if the value
is NOT greater than zero. Similarly any data fields that are empty the
corresponding adif field is simply not included in the adif packet. That
is JTAlert only includes adif fields for non-empty and non-zero (> 1)
data fields.

The problem is clearly with Log4OM V2.

de Laurie VK3AMA





HamApps Support (VK3AMA)
 

On 10/05/2020 12:58 pm, Dave Garber wrote:
I suspect an issue with adi from jtalert
It is not a JTAlert problem. If JTAlert shows zones in the log fields area, that is what gets sent in the ADIF packet to Log4OM.

If a zone is unknown than there will be no zone data in the adif packet sent. JTAlert deliberately does not send any Zone numbers if the value is NOT greater than zero. Similarly any data fields that are empty the corresponding adif field is simply not included in the adif packet. That is JTAlert only includes adif fields for non-empty and non-zero (> 1) data fields.

The problem is clearly with Log4OM V2.

de Laurie VK3AMA


Jim N6VH
 

Dave,

See my reply to Herb. As a test, I logged N3BNA from WSJT-X / JTAlert to Log4OM. Without using lookups, the zones were logged correctly. When I turned on lookups from QRZ, the QSO was logged with wrong zones since N3BNA doesn't have zones listed on QRZ. As i mentioned to Herb, this is A Log4OM problem, not WSJT-X or JTAlert.

73,

Jim N6VH

On 5/9/2020 7:58 PM, Dave Garber wrote:
Again, I say I had the same issue, and tried to report it on the log4om forum.  never saw an answer yet.  I suspect an issue with adi from jtalert, as to how they are handling it, cause jtalert shows correct info ( per qrz anyway), but it is not the info logged.

perhaps if more add to the forum complaint THEY will look into it, please then I will return to the software

Dave Garber
VE3WEJ / VE3IE




Jim N6VH
 

Herb,

I'm guessing you have lookups turned on, possibly from QRZ. Since N3BNA doesn't have zones listed on his QRZ page, Log4OM puts in arbitrary zones. When the QSO gets logged from WSJT-X / JTAlert, Log4OM uses the lookup info (or lack thereof) and overrides what was sent from WSJT-X / JTAlert. This is a Log4OM problem, not WSJT-X or JTAlert. The solution is to not use lookups (my choice), or to use them from HamQTH instead. That site seems to have more zones than QRZ. I don't have any idea why.

73,

Jim N6VH

On 5/9/2020 6:26 PM, WB8ASI Herb wrote:
Thanks Jim.  This Zones thing is driving me crazy.  Not sure where data is coming from.  Just finished QSO with N3BNA.  All agree Grid is FN10uf.  Log4OMv2 has location as ITU/CQ as 8/5, and so does JTAlert as 8/5, but logged QSO is 6/0.  All captured on attached pic.  Will post over on Log4OM forum as well.   73 Herb WB8ASI

On May 9, 2020 at 7:56 PM Jim N6VH <N6VH@...> wrote:


On 5/9/2020 2:35 PM, WB8ASI Herb wrote:
I've started seeing CQ zone=0.  In my pursuit of accurate data I find many misloggings of ITU and CQ zones based on a good Gridsquare.  I know there is confusion when some one is operating from a different gridsquare from their licensed location on QRZ.  I have 2 locations and try and make sure I QSO and QSL appropriately.  However, something is off normal in lookups.   There is an active discussion on the Log4OMv2 Forum on the CQ zone=0 thread.  In my log review and cleanup attempt, I found one that seems to have a JTAlert twist.  Looking up an old QSO with WQ6X.  All appears that he is on Alameda Is in CA grid CM87US on QRZ, V2 Main UI, and JTAlert all agree. Zone-Check.eu shows that it should be ITU 6, CQ 3.  The Main V2 UI shows such and logs properly this time as 6 3.  JTAlert shows ITU 6, CQ 5.  That is not possible.  Where does the 5 come from???.   If I update the QSO in my V2 log it changes to from correct CQ 3 to CQ 5, so I will not save.  I'm not a big Zone watcher, thus not a big issue for me, but would rather have blank info rather than bad info.  This Zone Problem is not at all JTAlert, but it is in this example.  Something in the lookups is not right.  I will try and determine when it started as I continue to check in my extra COVID19 time, and let you know.  I thought it started with V2, but the above example is dated July 2019.  I'm not losing sleep over it.  Don't anyone else either.  73 Herb WB8ASI  

 


WB8ASI Herb
 

Thanks Dave.  I'm not alone.  Now that I'm aware of what is happening I keep on top of it best I can, but still seems to like logging ITU 6 and CQ 0, even tho the Log4OM main screen and JTAlert say otherwise.  I'll try and keep it alive over on the Log4OM Forum.  Maybe a fresh thread is needed? or they are quietly thinking on it?  Something is awry.  73 Herb WB8ASI

On May 9, 2020 at 10:58 PM Dave Garber <ve3wej@...> wrote:

Again, I say I had the same issue, and tried to report it on the log4om forum.  never saw an answer yet.  I suspect an issue with adi from jtalert, as to how they are handling it, cause jtalert shows correct info ( per qrz anyway), but it is not the info logged.

perhaps if more add to the forum complaint THEY will look into it, please then I will return to the software

Dave Garber
VE3WEJ / VE3IE


On Sat, May 9, 2020 at 10:22 PM David De Coons < RocketNJ@...> wrote:
Check your station location in TQSL. My friend had same issue. Needed to delete station from TQSL and create a new one with correct ITU and CQ info.

Dave wo2x

 

On May 9, 2020, at 9:26 PM, WB8ASI Herb < WB8ASI@...> wrote:

Thanks Jim.  This Zones thing is driving me crazy.  Not sure where data is coming from.  Just finished QSO with N3BNA.  All agree Grid is FN10uf.  Log4OMv2 has location as ITU/CQ as 8/5, and so does JTAlert as 8/5, but logged QSO is 6/0.  All captured on attached pic.  Will post over on Log4OM forum as well.   73 Herb WB8ASI
<image.png>

On May 9, 2020 at 7:56 PM Jim N6VH < N6VH@...> wrote:


On 5/9/2020 2:35 PM, WB8ASI Herb wrote:
I've started seeing CQ zone=0.  In my pursuit of accurate data I find many misloggings of ITU and CQ zones based on a good Gridsquare.  I know there is confusion when some one is operating from a different gridsquare from their licensed location on QRZ.  I have 2 locations and try and make sure I QSO and QSL appropriately.  However, something is off normal in lookups.   There is an active discussion on the Log4OMv2 Forum on the CQ zone=0 thread.  In my log review and cleanup attempt, I found one that seems to have a JTAlert twist.  Looking up an old QSO with WQ6X.  All appears that he is on Alameda Is in CA grid CM87US on QRZ, V2 Main UI, and JTAlert all agree. Zone-Check.eu shows that it should be ITU 6, CQ 3.  The Main V2 UI shows such and logs properly this time as 6 3.  JTAlert shows ITU 6, CQ 5.  That is not possible.  Where does the 5 come from???.   If I update the QSO in my V2 log it changes to from correct CQ 3 to CQ 5, so I will not save.  I'm not a big Zone watcher, thus not a big issue for me, but would rather have blank info rather than bad info.  This Zone Problem is not at all JTAlert, but it is in this example.  Something in the lookups is not right.  I will try and determine when it started as I continue to check in my extra COVID19 time, and let you know.  I thought it started with V2, but the above example is dated July 2019.  I'm not losing sleep over it.  Don't anyone else either.  73 Herb WB8ASI  

 

 

 


 


Dave Garber
 

Again, I say I had the same issue, and tried to report it on the log4om forum.  never saw an answer yet.  I suspect an issue with adi from jtalert, as to how they are handling it, cause jtalert shows correct info ( per qrz anyway), but it is not the info logged.

perhaps if more add to the forum complaint THEY will look into it, please then I will return to the software

Dave Garber
VE3WEJ / VE3IE


On Sat, May 9, 2020 at 10:22 PM David De Coons <RocketNJ@...> wrote:
Check your station location in TQSL. My friend had same issue. Needed to delete station from TQSL and create a new one with correct ITU and CQ info.

Dave wo2x


On May 9, 2020, at 9:26 PM, WB8ASI Herb <WB8ASI@...> wrote:


Thanks Jim.  This Zones thing is driving me crazy.  Not sure where data is coming from.  Just finished QSO with N3BNA.  All agree Grid is FN10uf.  Log4OMv2 has location as ITU/CQ as 8/5, and so does JTAlert as 8/5, but logged QSO is 6/0.  All captured on attached pic.  Will post over on Log4OM forum as well.   73 Herb WB8ASI
<image.png>

On May 9, 2020 at 7:56 PM Jim N6VH <N6VH@...> wrote:


On 5/9/2020 2:35 PM, WB8ASI Herb wrote:
I've started seeing CQ zone=0.  In my pursuit of accurate data I find many misloggings of ITU and CQ zones based on a good Gridsquare.  I know there is confusion when some one is operating from a different gridsquare from their licensed location on QRZ.  I have 2 locations and try and make sure I QSO and QSL appropriately.  However, something is off normal in lookups.   There is an active discussion on the Log4OMv2 Forum on the CQ zone=0 thread.  In my log review and cleanup attempt, I found one that seems to have a JTAlert twist.  Looking up an old QSO with WQ6X.  All appears that he is on Alameda Is in CA grid CM87US on QRZ, V2 Main UI, and JTAlert all agree. Zone-Check.eu shows that it should be ITU 6, CQ 3.  The Main V2 UI shows such and logs properly this time as 6 3.  JTAlert shows ITU 6, CQ 5.  That is not possible.  Where does the 5 come from???.   If I update the QSO in my V2 log it changes to from correct CQ 3 to CQ 5, so I will not save.  I'm not a big Zone watcher, thus not a big issue for me, but would rather have blank info rather than bad info.  This Zone Problem is not at all JTAlert, but it is in this example.  Something in the lookups is not right.  I will try and determine when it started as I continue to check in my extra COVID19 time, and let you know.  I thought it started with V2, but the above example is dated July 2019.  I'm not losing sleep over it.  Don't anyone else either.  73 Herb WB8ASI  

 


David De Coons
 

Check your station location in TQSL. My friend had same issue. Needed to delete station from TQSL and create a new one with correct ITU and CQ info.

Dave wo2x


On May 9, 2020, at 9:26 PM, WB8ASI Herb <WB8ASI@...> wrote:


Thanks Jim.  This Zones thing is driving me crazy.  Not sure where data is coming from.  Just finished QSO with N3BNA.  All agree Grid is FN10uf.  Log4OMv2 has location as ITU/CQ as 8/5, and so does JTAlert as 8/5, but logged QSO is 6/0.  All captured on attached pic.  Will post over on Log4OM forum as well.   73 Herb WB8ASI
<image.png>

On May 9, 2020 at 7:56 PM Jim N6VH <N6VH@...> wrote:


On 5/9/2020 2:35 PM, WB8ASI Herb wrote:
I've started seeing CQ zone=0.  In my pursuit of accurate data I find many misloggings of ITU and CQ zones based on a good Gridsquare.  I know there is confusion when some one is operating from a different gridsquare from their licensed location on QRZ.  I have 2 locations and try and make sure I QSO and QSL appropriately.  However, something is off normal in lookups.   There is an active discussion on the Log4OMv2 Forum on the CQ zone=0 thread.  In my log review and cleanup attempt, I found one that seems to have a JTAlert twist.  Looking up an old QSO with WQ6X.  All appears that he is on Alameda Is in CA grid CM87US on QRZ, V2 Main UI, and JTAlert all agree. Zone-Check.eu shows that it should be ITU 6, CQ 3.  The Main V2 UI shows such and logs properly this time as 6 3.  JTAlert shows ITU 6, CQ 5.  That is not possible.  Where does the 5 come from???.   If I update the QSO in my V2 log it changes to from correct CQ 3 to CQ 5, so I will not save.  I'm not a big Zone watcher, thus not a big issue for me, but would rather have blank info rather than bad info.  This Zone Problem is not at all JTAlert, but it is in this example.  Something in the lookups is not right.  I will try and determine when it started as I continue to check in my extra COVID19 time, and let you know.  I thought it started with V2, but the above example is dated July 2019.  I'm not losing sleep over it.  Don't anyone else either.  73 Herb WB8ASI  

 


WB8ASI Herb
 

Thanks Jim.  This Zones thing is driving me crazy.  Not sure where data is coming from.  Just finished QSO with N3BNA.  All agree Grid is FN10uf.  Log4OMv2 has location as ITU/CQ as 8/5, and so does JTAlert as 8/5, but logged QSO is 6/0.  All captured on attached pic.  Will post over on Log4OM forum as well.   73 Herb WB8ASI

On May 9, 2020 at 7:56 PM Jim N6VH <N6VH@...> wrote:


On 5/9/2020 2:35 PM, WB8ASI Herb wrote:
I've started seeing CQ zone=0.  In my pursuit of accurate data I find many misloggings of ITU and CQ zones based on a good Gridsquare.  I know there is confusion when some one is operating from a different gridsquare from their licensed location on QRZ.  I have 2 locations and try and make sure I QSO and QSL appropriately.  However, something is off normal in lookups.   There is an active discussion on the Log4OMv2 Forum on the CQ zone=0 thread.  In my log review and cleanup attempt, I found one that seems to have a JTAlert twist.  Looking up an old QSO with WQ6X.  All appears that he is on Alameda Is in CA grid CM87US on QRZ, V2 Main UI, and JTAlert all agree. Zone-Check.eu shows that it should be ITU 6, CQ 3.  The Main V2 UI shows such and logs properly this time as 6 3.  JTAlert shows ITU 6, CQ 5.  That is not possible.  Where does the 5 come from???.   If I update the QSO in my V2 log it changes to from correct CQ 3 to CQ 5, so I will not save.  I'm not a big Zone watcher, thus not a big issue for me, but would rather have blank info rather than bad info.  This Zone Problem is not at all JTAlert, but it is in this example.  Something in the lookups is not right.  I will try and determine when it started as I continue to check in my extra COVID19 time, and let you know.  I thought it started with V2, but the above example is dated July 2019.  I'm not losing sleep over it.  Don't anyone else either.  73 Herb WB8ASI  

 


Jim N6VH
 


On 5/9/2020 2:35 PM, WB8ASI Herb wrote:
I've started seeing CQ zone=0.  In my pursuit of accurate data I find many misloggings of ITU and CQ zones based on a good Gridsquare.  I know there is confusion when some one is operating from a different gridsquare from their licensed location on QRZ.  I have 2 locations and try and make sure I QSO and QSL appropriately.  However, something is off normal in lookups.   There is an active discussion on the Log4OMv2 Forum on the CQ zone=0 thread.  In my log review and cleanup attempt, I found one that seems to have a JTAlert twist.  Looking up an old QSO with WQ6X.  All appears that he is on Alameda Is in CA grid CM87US on QRZ, V2 Main UI, and JTAlert all agree. Zone-Check.eu shows that it should be ITU 6, CQ 3.  The Main V2 UI shows such and logs properly this time as 6 3.  JTAlert shows ITU 6, CQ 5.  That is not possible.  Where does the 5 come from???.   If I update the QSO in my V2 log it changes to from correct CQ 3 to CQ 5, so I will not save.  I'm not a big Zone watcher, thus not a big issue for me, but would rather have blank info rather than bad info.  This Zone Problem is not at all JTAlert, but it is in this example.  Something in the lookups is not right.  I will try and determine when it started as I continue to check in my extra COVID19 time, and let you know.  I thought it started with V2, but the above example is dated July 2019.  I'm not losing sleep over it.  Don't anyone else either.  73 Herb WB8ASI  
_._,_._,_


Herb,

As a test, I just logged  WQ6X in Log4OM directly, not through JTAlert / WSJT-X, and it logged as ITU 6 CQ 5. I deleted that QSO and logged using WSJT-X / JTAlert. That time it correctly logged ITU 6 CQ 3. When I entered WQ6X into WSJT-X, it appeared in JTAlert with the correct zones. See attached picture. Incidentally, I don't normally use lookups from either QRZ or HamQTH. 

73,

Jim N6VH


Dave Garber
 

I was having this error too, but only in log4om v2.   does not occur ( yet) in n3fjp


Dave Garber
VE3WEJ / VE3IE


On Sat, May 9, 2020 at 5:35 PM WB8ASI Herb <WB8ASI@...> wrote:
I've started seeing CQ zone=0.  In my pursuit of accurate data I find many misloggings of ITU and CQ zones based on a good Gridsquare.  I know there is confusion when some one is operating from a different gridsquare from their licensed location on QRZ.  I have 2 locations and try and make sure I QSO and QSL appropriately.  However, something is off normal in lookups.   There is an active discussion on the Log4OMv2 Forum on the CQ zone=0 thread.  In my log review and cleanup attempt, I found one that seems to have a JTAlert twist.  Looking up an old QSO with WQ6X.  All appears that he is on Alameda Is in CA grid CM87US on QRZ, V2 Main UI, and JTAlert all agree. Zone-Check.eu shows that it should be ITU 6, CQ 3.  The Main V2 UI shows such and logs properly this time as 6 3.  JTAlert shows ITU 6, CQ 5.  That is not possible.  Where does the 5 come from???.   If I update the QSO in my V2 log it changes to from correct CQ 3 to CQ 5, so I will not save.  I'm not a big Zone watcher, thus not a big issue for me, but would rather have blank info rather than bad info.  This Zone Problem is not at all JTAlert, but it is in this example.  Something in the lookups is not right.  I will try and determine when it started as I continue to check in my extra COVID19 time, and let you know.  I thought it started with V2, but the above example is dated July 2019.  I'm not losing sleep over it.  Don't anyone else either.  73 Herb WB8ASI