locked Where does the data come from for the lookup?


Rich McCabe
 

Just curious where the data comes from. I just worked the last state I needed on 17 meters (N7RE) and JTAlert alerted me to the proper state but appears the grid was wrong. So by time it got logged in Log4OM and sent to QRZ it showed as Arizona (AZ).

Easy fix but glad I caught it.

RIch


Michael Black
 

You should do a ?/Contact support and note what time that occurred and the call signs involved.
That way your debug info will still contain what's needed to determine what happened.  It only hangs around for something like 24 hours.

de Mike W9MDB




On Friday, February 9, 2018, 12:00:40 PM CST, Rich McCabe <r.mccabe@...> wrote:


Just curious where the data comes from. I just worked the last state I needed on 17 meters (N7RE) and JTAlert alerted me to the proper state but appears the grid was wrong. So by time it got logged in Log4OM and sent to QRZ it showed as Arizona (AZ).

Easy fix but glad I caught it.

RIch


Rich McCabe
 

Done

 

From: Support@HamApps.groups.io [mailto:Support@HamApps.groups.io] On Behalf Of Michael Black via Groups.Io
Sent: Friday, February 9, 2018 12:08 PM
To: Support@HamApps.groups.io
Subject: Re: [HamApps] Where does the data come from for the lookup?

 

You should do a ?/Contact support and note what time that occurred and the call signs involved.

That way your debug info will still contain what's needed to determine what happened.  It only hangs around for something like 24 hours.

 

de Mike W9MDB

 

 

 

 

On Friday, February 9, 2018, 12:00:40 PM CST, Rich McCabe <r.mccabe@...> wrote:

 

 

Just curious where the data comes from. I just worked the last state I needed on 17 meters (N7RE) and JTAlert alerted me to the proper state but appears the grid was wrong. So by time it got logged in Log4OM and sent to QRZ it showed as Arizona (AZ).

Easy fix but glad I caught it.

RIch


HamApps Support (VK3AMA)
 

On 10/02/2018 5:00 AM, Rich McCabe wrote:
Just curious where the data comes from. I just worked the last state I needed on 17 meters (N7RE) and JTAlert alerted me to the proper state but appears the grid was wrong. So by time it got logged in Log4OM and sent to QRZ it showed as Arizona (AZ).

Easy fix but glad I caught it.

RIch

Rich,

TLDR: AZ appears to be correct for K7RE at this time.

JTAlert doesn't perform any sort of GridSquare to State mapping/changes so a Grid can be incorrectly on the other side of the world and JTAlert will log it regardless of the State/DXCC/Zone data being logged.

Regarding K7RE (as indicated in your support email, not N7RE quoted in your original message), JTAlert sets his State as "SD" and if the QRZ.xml service is enabled, the returned Grid is "DN84am". The HamQTH xml data is similar with the Grid reduced to 4 characters.

Unless, you have a previous QSO with K7RE in your log with different State & Grid data, "SD" & "
DN84am" is what JTAlert logs to Log4OM.

Your session files show that the Grid logged by WSJT-X was "DM22", the Grid used on-air, and since that is different to what JTAlert has set, that was the Grid Logged to Log4OM.

Also from your session files, Log4OM returned previous K7RE QSO data of "AZ" & "DM23", so ultimately JTAlert sent to Log4OM "AZ" & "DM22" with "DM22" being the on-air grid

Looks to me like K7RE has moved from SD to AZ and hasn't bothered to update their QRZ or FCC data.
There is nothing on his QRZ page indicating if the move is temporary or permanent.

de Laurie VK3AMA
   


Rich McCabe
 

Well I dropped him an email and asked 😊

 

Thanks Laurie

 

Rich

 

From: Support@HamApps.groups.io [mailto:Support@HamApps.groups.io] On Behalf Of HamApps Support (VK3AMA)
Sent: Friday, February 9, 2018 2:15 PM
To: Support@HamApps.groups.io
Subject: Re: [HamApps] Where does the data come from for the lookup?

 

On 10/02/2018 5:00 AM, Rich McCabe wrote:

Just curious where the data comes from. I just worked the last state I needed on 17 meters (N7RE) and JTAlert alerted me to the proper state but appears the grid was wrong. So by time it got logged in Log4OM and sent to QRZ it showed as Arizona (AZ).

Easy fix but glad I caught it.

RIch


Rich,

TLDR: AZ appears to be correct for K7RE at this time.

JTAlert doesn't perform any sort of GridSquare to State mapping/changes so a Grid can be incorrectly on the other side of the world and JTAlert will log it regardless of the State/DXCC/Zone data being logged.

Regarding K7RE (as indicated in your support email, not N7RE quoted in your original message), JTAlert sets his State as "SD" and if the QRZ.xml service is enabled, the returned Grid is "DN84am". The HamQTH xml data is similar with the Grid reduced to 4 characters.

Unless, you have a previous QSO with K7RE in your log with different State & Grid data, "SD" & "DN84am" is what JTAlert logs to Log4OM.

Your session files show that the Grid logged by WSJT-X was "DM22", the Grid used on-air, and since that is different to what JTAlert has set, that was the Grid Logged to Log4OM.

Also from your session files, Log4OM returned previous K7RE QSO data of "AZ" & "DM23", so ultimately JTAlert sent to Log4OM "AZ" & "DM22" with "DM22" being the on-air grid

Looks to me like K7RE has moved from SD to AZ and hasn't bothered to update their QRZ or FCC data.
There is nothing on his QRZ page indicating if the move is temporary or permanent.

de Laurie VK3AMA
   


Jim N6VH
 

I just googled K7RE, and found a listing on the aprs web site:

https://aprs.fi/info/a/K7RE-1

This was just a few minutes ago, and he was in or near Yuma, AZ. He might be a snowbird, and only there for the winter, hence no need to change his listing with the FCC.

73,

Jim N6VH

On 2/9/2018 12:14 PM, HamApps Support (VK3AMA) wrote:
On 10/02/2018 5:00 AM, Rich McCabe wrote:
Just curious where the data comes from. I just worked the last state I needed on 17 meters (N7RE) and JTAlert alerted me to the proper state but appears the grid was wrong. So by time it got logged in Log4OM and sent to QRZ it showed as Arizona (AZ).

Easy fix but glad I caught it.

RIch
Rich,
TLDR: AZ appears to be correct for K7RE at this time.
JTAlert doesn't perform any sort of GridSquare to State mapping/changes so a Grid can be incorrectly on the other side of the world and JTAlert will log it regardless of the State/DXCC/Zone data being logged.
Regarding K7RE (as indicated in your support email, not N7RE quoted in your original message), JTAlert sets his State as "SD" and if the QRZ.xml service is enabled, the returned Grid is "DN84am". The HamQTH xml data is similar with the Grid reduced to 4 characters.
Unless, you have a previous QSO with K7RE in your log with different State & Grid data, "SD" & "DN84am" is what JTAlert logs to Log4OM.
Your session files show that the Grid logged by WSJT-X was "DM22", the Grid used on-air, and since that is different to what JTAlert has set, that was the Grid Logged to Log4OM.
Also from your session files, Log4OM returned previous K7RE QSO data of "AZ" & "DM23", so ultimately JTAlert sent to Log4OM "AZ" & "DM22" with "DM22" being the on-air grid
Looks to me like K7RE has moved from SD to AZ and hasn't bothered to update their QRZ or FCC data.
There is nothing on his QRZ page indicating if the move is temporary or permanent.
de Laurie VK3AMA


Rich McCabe
 

Yea, I just found that too.

So guessing he is AZ. Was excited when JTalert flagged him as SD on 17.
Rich

-----Original Message-----
From: Support@HamApps.groups.io [mailto:Support@HamApps.groups.io] On
Behalf Of Jim Preston
Sent: Friday, February 9, 2018 4:06 PM
To: Support@HamApps.groups.io
Subject: Re: [HamApps] Where does the data come from for the lookup?

I just googled K7RE, and found a listing on the aprs web site:

https://aprs.fi/info/a/K7RE-1

This was just a few minutes ago, and he was in or near Yuma, AZ. He might
be a snowbird, and only there for the winter, hence no need to change his
listing with the FCC.

73,

Jim N6VH


On 2/9/2018 12:14 PM, HamApps Support (VK3AMA) wrote:
On 10/02/2018 5:00 AM, Rich McCabe wrote:
Just curious where the data comes from. I just worked the last state
I needed on 17 meters (N7RE) and JTAlert alerted me to the proper
state but appears the grid was wrong. So by time it got logged in
Log4OM and sent to QRZ it showed as Arizona (AZ).

Easy fix but glad I caught it.

RIch
Rich,

TLDR: AZ appears to be correct for K7RE at this time.

JTAlert doesn't perform any sort of GridSquare to State
mapping/changes so a Grid can be incorrectly on the other side of the
world and JTAlert will log it regardless of the State/DXCC/Zone data
being logged.

Regarding K7RE (as indicated in your support email, not N7RE quoted in
your original message), JTAlert sets his State as "SD" and if the
QRZ.xml service is enabled, the returned Grid is "DN84am". The HamQTH
xml data is similar with the Grid reduced to 4 characters.

Unless, you have a previous QSO with K7RE in your log with different
State & Grid data, "SD" & "DN84am" is what JTAlert logs to Log4OM.

Your session files show that the Grid logged by WSJT-X was "DM22", the
Grid used on-air, and since that is different to what JTAlert has set,
that was the Grid Logged to Log4OM.

Also from your session files, Log4OM returned previous K7RE QSO data
of "AZ" & "DM23", so ultimately JTAlert sent to Log4OM "AZ" & "DM22"
with "DM22" being the on-air grid

Looks to me like K7RE has moved from SD to AZ and hasn't bothered to
update their QRZ or FCC data.
There is nothing on his QRZ page indicating if the move is temporary
or permanent.

de Laurie VK3AMA



HamApps Support (VK3AMA)
 

On 10/02/2018 9:24 AM, Rich McCabe wrote:
Yea, I just found that too.

So guessing he is AZ. Was excited when JTalert flagged him as SD on 17.
Rich
Rich,

Not a lot that can be done with the current JTAlert implementation if his QRZ and FCC data doesn't match the true location of the Callsign being logged.

I do have some partially implemented code, written a few years ago but never fully developed, that would alert the user that the on-air grid locater suggests a location (Country, State, Zones, etc) different from what was being logged. I might revisit that code to see how much work is left to make it usable for a future JTAlert release. No promises however ;-)

de Laurie VK3AMA
   


Rich McCabe
 

Thanks Laurie,

 

No big deal. Was just excited to finally finish off 17 meters. SD has been a challenge 😊

 

Rich

 

 

From: Support@HamApps.groups.io [mailto:Support@HamApps.groups.io] On Behalf Of HamApps Support (VK3AMA)
Sent: Friday, February 9, 2018 4:47 PM
To: Support@HamApps.groups.io
Subject: Re: [HamApps] Where does the data come from for the lookup?

 

On 10/02/2018 9:24 AM, Rich McCabe wrote:

Yea, I just found that too.
 
So guessing he is AZ. Was excited when JTalert flagged him as SD on 17.
Rich

Rich,

Not a lot that can be done with the current JTAlert implementation if his QRZ and FCC data doesn't match the true location of the Callsign being logged.

I do have some partially implemented code, written a few years ago but never fully developed, that would alert the user that the on-air grid locater suggests a location (Country, State, Zones, etc) different from what was being logged. I might revisit that code to see how much work is left to make it usable for a future JTAlert release. No promises however ;-)

de Laurie VK3AMA
   


Brian Kassel K7RE
 

Hello Folks:

K7RE here in AZ.
Yes, I am a snow bird, or winter visitor to AZ from SD, my home QTH.
I have been trying for months to get my temporary QTH, AZ, listed on JT-Alert
instead of my home QTH, SD.
I am well aware that JT-Alert is not at fault in any way.
This is only a TEMPORARY change, as we will be returning to SD in May.
Since this move is temporary, and we will be running the Grid Chase
event from several additional states before we return home, there seems
to be no easy method to correct my QTH as we move from state to state.

Of course my Grid Squre identifier will always be correct.

There has to be many other traveling hams who are having this same issue.

If anyone has a clue as to what I can do from my end to correct this,
please let me know.

I am very sorry for the confusion.

--
Sent by my Raspberry PI3
Brian K7RE


Rich McCabe
 

Hi Brian,

 

Thanks for the contact and not a big deal.  Wishing you were in SD though !

 

Log4OM did log you correct despite the SD state in JTalert.

 

I was more interested in learning what was going on.

 

73,


Rich

 

 

From: Support@HamApps.groups.io [mailto:Support@HamApps.groups.io] On Behalf Of Brian Kassel
Sent: Saturday, February 10, 2018 9:01 AM
To: Support@HamApps.groups.io
Subject: Re: [HamApps] Where does the data come from for the lookup?

 

Hello Folks:

K7RE here in AZ.

Yes, I am a snow bird, or winter visitor to AZ from SD, my home QTH.

I have been trying for months to get my temporary QTH, AZ, listed on JT-Alert

instead of my home QTH, SD.

I am well aware that JT-Alert is not at fault in any way.

This is only a TEMPORARY change, as we will be returning to SD in May.

Since this move is temporary, and we will be running the Grid Chase

event from several additional states before we return home, there seems

to be no easy method to correct my QTH as we move from state to state.

Of course my Grid Squre identifier will always be correct.

 

There has to be many other traveling hams who are having this same issue.

 

If anyone has a clue as to what I can do from my end to correct this,

please let me know.

 

I am very sorry for the confusion.


--

Sent by my Raspberry PI3
Brian K7RE


Jim Cooper
 

On 10 Feb 2018 at 8:00, Brian Kassel wrote:

Of course my Grid Squre identifier will always be correct.

There has to be many other traveling hams who are having this same
issue.

If anyone has a clue as to what I can do from
my end to correct this, please let me know.
seems to me that the grid square info transmitted at the time
of the current QSO should over-ride all else... I don't really
understand why a previous contact in the log should over-ride
current info ... xml lookup could be used if there was NO grid
info received on the current QSO ... previous log info only to
be used if all else fails. just my humble observation.

w2jc


HamApps Support (VK3AMA)
 

On 11/02/2018 7:09 AM, Jim Cooper wrote:
seems to me that the grid square info transmitted at the time 
of the current QSO should over-ride all else...  I don't really
understand why a previous contact in the log should over-ride 
current info ...   xml lookup could be used if there was NO grid 
info received on the current QSO ...  previous log info only to 
be used if all else fails.   just my humble observation. 

w2jc 
W2JC,

That is how JTAlert handles discrepancies in the grid data. The on-air grid is "Gospel" and is always logged regardless of previous log entires or xml data.

However, JTAlert doesn't perform any Grid to State or DXCC mapping. If a TX Station wants RX Stations to accurately know their location then it is incumbent on them to take the necessary steps to correct the online sources of their Station location data.

de Laurie VK3AMA
   



HamApps Support (VK3AMA)
 

On 11/02/2018 2:00 AM, Brian Kassel wrote:
I have been trying for months to get my temporary QTH, AZ, listed on JT-Alert
instead of my home QTH, SD.

Brian,

I don't recall any such discussions. A search of the online messages and my personal local message archive of the Yahoo and Groups.io messages didn't reveal any such request.

If you want JTAlert to provide accurate State alerts I can put in-place a Callsign override in the FCC Data import code so that each time the Callsigns database is updated (as well as HamSpots,net) your State is recorded per your last request. I already do this for 6 other Callsigns, adding another is not a problem.

If you request an override, please be aware that the override is permanent until you request its removal. It is a manual process (not onerous, 5 seconds to comment out the code). It is not automated based on date or some online service lookup change detection. You simply request via email that the current override be removed or changed.

Note: While an override to the Callsign database will correct the incorrect State alerting, it does not correct the incorrect State data being received via XML lookups. It is your responsibility to keep the online sources of your data up-to-date. JTAlert doesn't contain any hard-coded Callsign checks and never will.

de Laurie VK3AMA
   


HamApps Support (VK3AMA)
 

On 11/02/2018 7:35 AM, HamApps Support (VK3AMA) wrote:
JTAlert doesn't contain any hard-coded Callsign checks and never will.

A correction on this statement. There is one hard-coded Callsign in JTAlert and that is "VK3AMA" and that is to provide a popup "hope they enjoy the software" message to new JTAlert users when they first log a contact with the JTAlert developer.

Apart from the above, there are no Callsign specific code checks within JTAlert.

de Laurie VK3AMA
   


Brian (N2MLP)
 

Well now we all need to find you on the bands and see it

 

From: Support@HamApps.groups.io [mailto:Support@HamApps.groups.io] On Behalf Of HamApps Support (VK3AMA)
Sent: Saturday, February 10, 2018 3:45 PM
To: Support@HamApps.groups.io
Subject: Re: [HamApps] Where does the data come from for the lookup?

 

On 11/02/2018 7:35 AM, HamApps Support (VK3AMA) wrote:

JTAlert doesn't contain any hard-coded Callsign checks and never will.


A correction on this statement. There is one hard-coded Callsign in JTAlert and that is "VK3AMA" and that is to provide a popup "hope they enjoy the software" message to new JTAlert users when they first log a contact with the JTAlert developer.

Apart from the above, there are no Callsign specific code checks within JTAlert.

de Laurie VK3AMA
   


Rich McCabe
 

I keep looking for VKAMA but figure too busy responding to our stupid questions on here 😊

 

I did have an Alert for K5SDR which worked and I got him over Christmas break.

 

From: Support@HamApps.groups.io [mailto:Support@HamApps.groups.io] On Behalf Of Brian (N2MLP)
Sent: Saturday, February 10, 2018 2:47 PM
To: Support@HamApps.groups.io
Subject: Re: [HamApps] Where does the data come from for the lookup?

 

Well now we all need to find you on the bands and see it

 

From: Support@HamApps.groups.io [mailto:Support@HamApps.groups.io] On Behalf Of HamApps Support (VK3AMA)
Sent: Saturday, February 10, 2018 3:45 PM
To: Support@HamApps.groups.io
Subject: Re: [HamApps] Where does the data come from for the lookup?

 

On 11/02/2018 7:35 AM, HamApps Support (VK3AMA) wrote:

JTAlert doesn't contain any hard-coded Callsign checks and never will.


A correction on this statement. There is one hard-coded Callsign in JTAlert and that is "VK3AMA" and that is to provide a popup "hope they enjoy the software" message to new JTAlert users when they first log a contact with the JTAlert developer.

Apart from the above, there are no Callsign specific code checks within JTAlert.

de Laurie VK3AMA
   


Brian Kassel K7RE
 

Laurie Said:
"If you want JTAlert to provide accurate State alerts I can put in-place a Callsign override in the FCC Data import code so that each

time the Callsigns database is updated (as well as HamSpots,net) your State is recorded per your last request. I already do this for

6 other Callsigns, adding another is not a problem.

If you request an override, please be aware that the override is permanent until you request its removal. It is a manual process (not

onerous, 5 seconds to comment out the code). It is not automated based on date or some online service lookup change detection. You

simply request via email that the current override be removed or changed."

Apparently I had been dealing with all of the wrong sources in my quest to get the state changed.
I was not aware of the process in which state names are determined.

Your suggestion as to how to get an over ride for the state names was unknown to me, so
I ended up pursuing the wrong  sources.

I now understand the process, and I thank you for your direction.

Since my state changes and locations will change from week to week, I am not sure
that I should bother you with the constant updates that would be required.

Thanks again for the excellent reply, and for your time in supporting the applcation.

I will think on it a bit.

--
Sent by my Raspberry PI3
Brian K7RE


Lawrence Godek
 

Brian, I'd think that as long as you updated your GRID locator in QRZ.com when you change locations, if the grid does indeed change, would be all you need to do.  My thoughts for correct grid logging since QRZ.com is where the data comes from.

Larry
W0OGH


On Sun, Feb 11, 2018 at 7:25 AM, Brian Kassel <briank7re@...> wrote:
Laurie Said:
"If you want JTAlert to provide accurate State alerts I can put in-place a Callsign override in the FCC Data import code so that each

time the Callsigns database is updated (as well as HamSpots,net) your State is recorded per your last request. I already do this for

6 other Callsigns, adding another is not a problem.

If you request an override, please be aware that the override is permanent until you request its removal. It is a manual process (not

onerous, 5 seconds to comment out the code). It is not automated based on date or some online service lookup change detection. You

simply request via email that the current override be removed or changed."

Apparently I had been dealing with all of the wrong sources in my quest to get the state changed.
I was not aware of the process in which state names are determined.

Your suggestion as to how to get an over ride for the state names was unknown to me, so
I ended up pursuing the wrong  sources.

I now understand the process, and I thank you for your direction.

Since my state changes and locations will change from week to week, I am not sure
that I should bother you with the constant updates that would be required.

Thanks again for the excellent reply, and for your time in supporting the applcation.

I will think on it a bit.

--
Sent by my Raspberry PI3
Brian K7RE



Brian Kassel K7RE
 

Thanks Larry.  I think that will do as you say.

Thanks to all for the help.

--
Sent by my Raspberry PI3
Brian K7RE