[Dxspider-support] Failure in cty.dat?

Dirk Koopman djk at tobit.co.uk
Fri May 6 00:41:35 BST 2022 

The problem with this is nothing specific to do with DXSpider. All spots 
are prepared for storage or processing by one routine (Spot::prepare). 
This turns the fields of an incoming PC11 or PC61 into an array with all 
the extra information like: country code, cq zone, itu zone and any US 
State 2 letter code. It does not matter where that spot comes from, 
whether it originates from a PC11/PC61/RBN Spot line. That line is (one 
way or another) split up into a set of fields that these spots contain 
and then pushed through Spot::prepare. The result of that is a new, 
extended, record and it is this record that is the used for all 
processes in DXSpider (like filtering, spot formatting and display). The 
Spot code does not recognise any country code information because it is 
_*not*_ provided by an incoming spot (in PC protocol) from another node 
or the RBN.

I don't understand where you are getting this "entity code" from using 
standard data formats.

If you are trying to parse CC11 spot lines (a probably more successful  
way of doing "passive mode" connections than AR-C4 nodes used) then you 
need to know that DXSpider CC11 lines are subtly different from 
CCCluster ones in the area of "added information". Basically Lee VE7CC 
continued to extend his version of CC11 from the field order we agreed 
upon many years ago. This is a relatively new situation that has only 
recently come to light. Unfortunately, I don't believe that I can change 
my version to his without causing people more (and different) pain. So 
the solution is to just use the fields in CC11 that provide the standard 
spot information and then, if you need then, run that data through 
Spot::Prepare. This is the only way of getting a self-consistent 
"prepared" spot record. If that is not possible, then you will need to 
know (or work out) what sort of node you are connecting to so that you 
use the correct fields for the data that you are looking for.

If you need to know more about CC11 formats, email me offline and I'll 
dig out some emails on the subject from January this year.

Dirk

On 05/05/2022 18:06, Kin via Dxspider-support wrote:
>
>
> El 05/05/2022 a las 10:52, Joaquin escribió:
>> Hi,
>> From what you can see, there are DXSpider and CC nodes that are not 
>> pruning the correct entity. Among these there is one that I can 
>> assure you has updated your cty.dat (EA4URE-5) :
>>
>> 2022-05-04T08:53:17 - KG6DX: 226 -> 107 | DH1TW-2 | DX | SV9CVY
>> 2022-05-04T09:21:27 - KG6DX: 226 -> 107 | SK3W-6 | DX | UN3GX
>> 2022-05-04T14:03:31 - K5ZYO: 226 -> 112 | AE5E | DX | N5NOQ
>> 2022-05-04T18:50:33 - NP3K: 120 -> 226 | W3LPL | DX | W3LPL
>> 2022-05-05T04:11:47 - KH6M: 112 -> 226 | IZ3LSV-6 | DX | IV3JER
>> 2022-05-05T05:35:45 - KC8JNV: 226 -> 112 | EA4URE-5 | DX | EA1US
>> 2022-05-05T08:44:58 - RP77P: 179 -> 182 | VE7CC-1 | DX | R8LA
>>
>> Most of the spots that arrive with the wrong entity belong to the RBN 
>> network:
>>
>> 2022-05-05T08:46:38 - RP77U: 179 -> 182 |  | RB | HA8TKS-#
>> 2022-05-05T08:46:54 - RP77AB: 179 -> 182 |  | RB | JH7CSU1-#
>> 2022-05-05T08:47:21 - RP77V: 179 -> 182 |  | RB | HA8TKS-#
>> 2022-05-05T08:47:21 - RP77KM: 179 -> 182 |  | RB | OE8TED-#
>> 2022-05-05T08:47:29 - RP77TT: 179 -> 182 |  | RB | HA8TKS-#
>> 2022-05-05T08:47:32 - RP77GK: 179 -> 182 |  | RB | MM0HVU-#
>> 2022-05-05T08:47:32 - RP77TZ: 179 -> 182 |  | RB | MM0HVU-#
>> 2022-05-05T08:47:32 - RP77J: 179 -> 182 |  | RB | DL9GTB-#
>> 2022-05-05T08:47:57 - RP77GB: 179 -> 182 |  | RB | DL8LAS-#
>>
>> Kin
>>
>>
>> El 2 may. 2022 20:14, Kin via Dxspider-support 
>> <dxspider-support at tobit.co.uk> escribió:
>>
>>     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
>>
>>
>>
>> Hi,
>>  From what you can see, there are DXSpider and CC nodes that are not pruning the correct entity. Among these there is one that I can assure you has updated your cty.dat (EA4URE-5) :
>>
>> 2022-05-04T08:53:17 - KG6DX: 226 -> 107 | DH1TW-2 | DX | SV9CVY
>> 2022-05-04T09:21:27 - KG6DX: 226 -> 107 | SK3W-6 | DX | UN3GX
>> 2022-05-04T14:03:31 - K5ZYO: 226 -> 112 | AE5E | DX | N5NOQ
>> 2022-05-04T18:50:33 - NP3K: 120 -> 226 | W3LPL | DX | W3LPL
>> 2022-05-05T04:11:47 - KH6M: 112 -> 226 | IZ3LSV-6 | DX | IV3JER
>> 2022-05-05T05:35:45 - KC8JNV: 226 -> 112 | EA4URE-5 | DX | EA1US
>> 2022-05-05T08:44:58 - RP77P: 179 -> 182 | VE7CC-1 | DX | R8LA
>>
>> Most of the spots that arrive with the wrong entity belong to the RBN network:
>>
>> 2022-05-05T08:46:38 - RP77U: 179 -> 182 |  | RB | HA8TKS-#
>> 2022-05-05T08:46:54 - RP77AB: 179 -> 182 |  | RB | JH7CSU1-#
>> 2022-05-05T08:47:21 - RP77V: 179 -> 182 |  | RB | HA8TKS-#
>> 2022-05-05T08:47:21 - RP77KM: 179 -> 182 |  | RB | OE8TED-#
>> 2022-05-05T08:47:29 - RP77TT: 179 -> 182 |  | RB | HA8TKS-#
>> 2022-05-05T08:47:32 - RP77GK: 179 -> 182 |  | RB | MM0HVU-#
>> 2022-05-05T08:47:32 - RP77TZ: 179 -> 182 |  | RB | MM0HVU-#
>> 2022-05-05T08:47:32 - RP77J: 179 -> 182 |  | RB | DL9GTB-#
>> 2022-05-05T08:47:57 - RP77GB: 179 -> 182 |  | RB | DL8LAS-#
>>
>> Kin
>>
>>
>>
>>
>> El 2 may. 2022 20:14, Kin via Dxspider-support<dxspider-support at tobit.co.uk>  escribió:
>>> 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/20220506/1840b3c2/attachment-0001.htm>

More information about the Dxspider-support mailing list