[Dxspider-support] Failure in cty.dat?

Dirk Koopman djk at tobit.co.uk
Tue May 3 01:12:35 BST 2022


As far as I know, and assuming nothing has changed in this area (and if 
it has, I shall want to know by whom), DXSpider uses wpxloc.raw to 
determine the DXSpider "country number" - which is not to be confused 
with any other (more modern) number. I believe that the wpxloc.raw 
(originally from AK!A PacketCluster) had the only unique "country 
number" for many years. So 10 or so years later, when someone decided 
that needed a country number for logging and contest programs, they 
decided to invent some other number (eg DXCC number). This has been a 
source of some confusion ever since.

Wpxloc.raw and cty.dat are generated at the same time and from the same 
database by the same person - who has gone to a LOT of trouble to make 
this all possible. And as I have said before: please treat Jim AD1C very 
gently because he has been providing this service for the Amateur Radio 
community and hacking him off will not be helpful to anyone.

It is important that wpxloc.raw and cty.dat are BOTH downloaded and then 
run through /spider/perl/create_sysop.pl AND then a load/prefix command 
is given to the node in a console connection (or the node is restarted). 
This the only reliable way of generating a prefix file. Usually, if one 
downloads one file and not the other, then create_prefix.pl will fail. 
But sometimes it won't. Then load/prefix might fail, but sometimes not. 
The solution is to always download BOTH files.

Having got that off my chest: (only) spots generated by local users on a 
node and NEW incoming spots are stored in the spot file(s) and that's 
the only time the country number is stored.

If you can point me to where you think the problem is (maybe offline) 
I'll have a look at it. And if it is wrong, then I shall speak quite 
sternly to the culprit.

73 Dirk G1TLH

On 02/05/2022 19:14, Kin via Dxspider-support wrote:
>
> Hi Dirk,
>
> I've been seeing for a while that some callsigns are shown with the 
> wrong entity number, although in the cty.dat they are correctly assigned.
> I have looked at the code and I think you are using the information 
> from cty.dat to assign the entity number.
>
> Here is an example where you can see the entity that arrives in the 
> spot and the one that should appear:
>
> 2022-05-02-02T08:27:33 - KG6JDX: 226 -> 107
> 2022-05-02-02T08:27:56 - RP77AB: 179 -> 182
> 2022-05-02-02T11:12:22 - WB4JTT: 226 -> 112
> 2022-05-02-02T13:04:04 - R9MA/1: 182 -> 179
> 2022-05-02-02T17:11:28 - K2GT: 226 -> 112
> 2022-05-02-02T17:43:19 - W5ERV: 226 -> 117
>
> Could you tell me if it's normal that it doesn't update them?
>
> Regards,
>
> Kin
>
>
> _______________________________________________
> Dxspider-support mailing list
> Dxspider-support at tobit.co.uk
> https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.tobit.co.uk/pipermail/dxspider-support/attachments/20220503/18144afd/attachment.htm>


More information about the Dxspider-support mailing list