4C4C


Michael Black
 

I noticed that 4C4C comes up as Revillagigedo and then switches to Mexico after the QRZ lookup.

4C is not listed as a valid prefix

So was wondering why it initially comes up with Revillagigedo.

Mike W9MDB 


HamApps Support (VK3AMA)
 

On 25/11/2021 3:24 pm, Michael Black via groups.io wrote:
I noticed that 4C4C comes up as Revillagigedo and then switches to Mexico after the QRZ lookup.

4C is not listed as a valid prefix

So was wondering why it initially comes up with Revillagigedo.

Mike W9MDB 

4C4 is correct for Revillagigedo.

Your arrl posted link confirms that.

   

JTAlert uses a modified version of the cty.dat file provided by AD1C. It also lists 4C4 as Revillagigedo.

   

WSJTX also flags 4C4C as
Revillagigedo

   


Laurie VK3AMA


Michael Black
 

So will JTAlert send an alert on the default or the QRZ lookup?

Seems it sent out the DXCC alert on the default.  If QRZ is enabled perhaps the alert should be delayed until then?

Subject JTAlert Wanted DXCC
Lotw1:No  >1 year
Revillagigedo
40m FT8 Db +06
Freq 7074KHz
CQ 4C4C DL95
2021-11-24 07:17:45


Mike W9MDB




On Wednesday, November 24, 2021, 11:06:22 PM CST, HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:


On 25/11/2021 3:24 pm, Michael Black via groups.io wrote:
I noticed that 4C4C comes up as Revillagigedo and then switches to Mexico after the QRZ lookup.

4C is not listed as a valid prefix

So was wondering why it initially comes up with Revillagigedo.

Mike W9MDB 

4C4 is correct for Revillagigedo.

Your arrl posted link confirms that.

   

JTAlert uses a modified version of the cty.dat file provided by AD1C. It also lists 4C4 as Revillagigedo.

   

WSJTX also flags 4C4C as
Revillagigedo

   


Laurie VK3AMA


Michael Black
 

I just saw an alert in the callsigns windows on 4C4C with Revillagigedo instead of Mexico.  I do have QRZ lookups turned on.

Inline image


Revillagigedo




On Wednesday, November 24, 2021, 11:12:52 PM CST, Michael Black via groups.io <mdblack98@...> wrote:


So will JTAlert send an alert on the default or the QRZ lookup?

Seems it sent out the DXCC alert on the default.  If QRZ is enabled perhaps the alert should be delayed until then?

Subject JTAlert Wanted DXCC
Lotw1:No  >1 year
Revillagigedo
40m FT8 Db +06
Freq 7074KHz
CQ 4C4C DL95
2021-11-24 07:17:45


Mike W9MDB




On Wednesday, November 24, 2021, 11:06:22 PM CST, HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:


On 25/11/2021 3:24 pm, Michael Black via groups.io wrote:
I noticed that 4C4C comes up as Revillagigedo and then switches to Mexico after the QRZ lookup.

4C is not listed as a valid prefix

So was wondering why it initially comes up with Revillagigedo.

Mike W9MDB 

4C4 is correct for Revillagigedo.

Your arrl posted link confirms that.

   

JTAlert uses a modified version of the cty.dat file provided by AD1C. It also lists 4C4 as Revillagigedo.

   

WSJTX also flags 4C4C as
Revillagigedo

   


Laurie VK3AMA


Michael Black
 

Now I get Mexico in the main windows and Revliiagigedo in the callsigns window

Inline image





On Wednesday, November 24, 2021, 11:06:22 PM CST, HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:


On 25/11/2021 3:24 pm, Michael Black via groups.io wrote:
I noticed that 4C4C comes up as Revillagigedo and then switches to Mexico after the QRZ lookup.

4C is not listed as a valid prefix

So was wondering why it initially comes up with Revillagigedo.

Mike W9MDB 

4C4 is correct for Revillagigedo.

Your arrl posted link confirms that.

   

JTAlert uses a modified version of the cty.dat file provided by AD1C. It also lists 4C4 as Revillagigedo.

   

WSJTX also flags 4C4C as
Revillagigedo

   


Laurie VK3AMA


HamApps Support (VK3AMA)
 

On 25/11/2021 4:12 pm, Michael Black via groups.io wrote:
So will JTAlert send an alert on the default or the QRZ lookup?

Seems it sent out the DXCC alert on the default.  If QRZ is enabled perhaps the alert should be delayed until then?

User Alerts are generated for the real-time decodes. QRZ lookups only occur after initiating a QSO with the callsign, long after the initial decode alerting.

If you're already in QSO with the station, that is their callsign has been set in the WSJTX DXCall field, such that the QRZ lookup is initiated, what is the point of a user-alert?

If you're relying on email alerts to notify of needed stations having been decoded, how would JTAlert know to delay the alert pending an XML lookup result?

I can't see how a user-alert based on the QRZ XML lookup results would be useful or how it could be implemented.

de Laurie VK3AMA



HamApps Support (VK3AMA)
 

On 25/11/2021 4:20 pm, Michael Black via groups.io wrote:
I just saw an alert in the callsigns windows on 4C4C with Revillagigedo instead of Mexico.  I do have QRZ lookups turned on.

Real-time alerting does not use XML lookup results. XML lookups are only performed when the DXCall in WSJTX is set/changed. This is not new behavior, it is how JTAlert has always worked.

de Laurie VK3AMA


Michael Black
 

Hmmm...

If new DXCC and QRZ enabled add to delay queue.

After alerts are processed do QRZ lookups on the delay queue to update the DXCC and then generate alerts.

Alerting on the wrong country seems undesirable.

I would agree if you're in a QSO the alert seems unnecessary.

Mike




On Wednesday, November 24, 2021, 11:40:43 PM CST, HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:


On 25/11/2021 4:12 pm, Michael Black via groups.io wrote:
So will JTAlert send an alert on the default or the QRZ lookup?

Seems it sent out the DXCC alert on the default.  If QRZ is enabled perhaps the alert should be delayed until then?

User Alerts are generated for the real-time decodes. QRZ lookups only occur after initiating a QSO with the callsign, long after the initial decode alerting.

If you're already in QSO with the station, that is their callsign has been set in the WSJTX DXCall field, such that the QRZ lookup is initiated, what is the point of a user-alert?

If you're relying on email alerts to notify of needed stations having been decoded, how would JTAlert know to delay the alert pending an XML lookup result?

I can't see how a user-alert based on the QRZ XML lookup results would be useful or how it could be implemented.

de Laurie VK3AMA



HamApps Support (VK3AMA)
 

On 25/11/2021 4:24 pm, Michael Black via groups.io wrote:
Now I get Mexico in the main windows and Revliiagigedo in the callsigns window

That's correct. You have initiated a QSO, changed the DXCall in WSJTX which triggers the XML lookup after the Callsigns window alerted the decode (before the XML lookup). The XML lookup returned Mexico and JTAlert duly updated the log fields with this new data. This is not new, it is how JTAlert has always behaved.

Internet XML lookups for each decoded callsign in a period is not supported and never will be. The time and overhead is not suitable for the fast paced FT world.

 
de Laurie VK3AMA


Captain Fantastic
 

It's not the ARRL who assigns prefixes though. It's the ITU.

The ITU prefix ranges are found here:
https://en.wikipedia.org/wiki/ITU_prefix

Then...the ITU doesn't assign "sub" prefix ranges to DXCC countries, as the ITU isn't based off DXCC (these prefixes apply to more than ham radio).

As for 4C4C coming up as "Revillagigedo", that would be correct, based on how Mexico has assigned "4C" traditionally.

However...

The software we're using will never be 100% accurate.

Using the example of "K5K". That "prefix" is in the range assigned to the United States. But... one day it's a DXpedition on Kingman Reef. Another day, it's used by a group called "Hurricane Harvey and Kingwood Texas."

And Russian prefixes are particularly confusing.

So I'm comfortable that the software we use is 95% accurate. Things like "4C4C" (or "K5K") are things we'll just sort out ourselves as we go along.

Seth, KC9TLG