[Dxspider-support] Failure in cty.dat?

Dirk Koopman djk at tobit.co.uk
Mon May 9 13:06:57 BST 2022 

As a matter of policy, I don't take into account information in CC11 
that is not in a stock PC11 or PC61. I don't recommend that you do 
either. DXSpider using wpxloc.raw country numbers and CCCluster doesn't 
(and I don't know what is uses). Similarly there are one or two other 
makes of cluster software, e.g. ARC4 & ARC6, even one or two original 
AK1A nodes, connected by AX25 that use (only) AD1C knows. Then there is 
the issue of which version of wpxloc.raw any node (that uses it) has 
installed.

One of the advantages of wpxloc.raw is that new countries, that have 
existing country codes, but have split away/become independent/otherwise 
been give a new prefix to differentiate them from what ever country they 
were part of - any of which makes them a new DXCC entity - gets a new 
wpxloc.raw country number.  This means that spots from 1997 will still 
have decodable country numbers pointing to the prefix in use at the time 
(mostly).

On the occasions that I decode CC11 (and DXSpider itself does not do 
this), I *always* ignore any of the country code/zones/US state info. If 
I find it necessary, I take this information from the generated prefix 
file that DXSpider used.

I think you are trying to compare apples and aubergines with this 
program and I doubt you will ever be able to (100%) reliably get the 
information you are after.

73 Dirk G1TLH

On 06/05/2022 08:20, Kin via Dxspider-support wrote:
>
> Hi Dirk,
>
> * My scenario for capturing information is as follows:
>
> DXspider node build 439
> cty.dat, wpxloc.raw, usdbraw.gz to last update
> I get the data via CC11
>
> * To process the information:
>
> Routine that uses a copy of the cty.dat, wpxloc.raw, usdbraw.gz 
> identical to the one that the DXSpider node has.
>
> * Procedure:
>
> For each CC11 I receive:
>
> 1. I get the fields "call dx" and "spotted dxcc country".
> 2. Externally I do a search for "call/country" in cty.dat.
> 3. I compare the spotted entity number from CC11 with the one I get, 
> and if it is different I send it to a log.
>
> I tried to generate a spot locally from my DXSpider, and I found that 
> the entity number returned by a CC11 is wrong.
>
> The test was as follows:
>
> *KH6M *is in Florida (see qrz.com).
>
> TX: dx KH6M 50000 TEST
> RX: DX de EA4URE:    50000.0 *KH6M *TEST 0630Z
>
>
> Debug file:
> ...
> 1651818621^(chan) -> D EA4M DX de EA4URE:    50000.0 *KH6M * 
> TEST                           0630Z
> 1651818621^(chan) -> D N5KD-4 CC11^50000.0^KH6M^ 
> 6-May-2022^0630Z^TEST^EA4URE^*112*^34^EA4URE-3^*61*^*31*^37^14^*FL*^^*Hawaii-KH6*^BA-CC-CR-CU-GU-M-TO-EA^EL86^IN80
> ...
>
> The CC11 sent to me by my dxspider shows:
>
> Entity: *112 *-> Hawaii
> State: *FL*
> ITU: *61*
> CQ: *31*
>
>
> I consult the files wpxloc.raw, cty.dat and usdbraw.gz
>
> wpxloc.raw:
> ...
> KH6 Hawaii-KH6 *112 61 31*  10.00 21  7  0 N 157 29  0 W @
> ...
> K United-States-K *226 8  5*   5.00 37 36  0 N  91 52  0 W @
> AA,AB,AC,AD,AE,AF,AG,AI,AJ,AK,N,W United-States-K     226  8 5   5.00 
> 37 36  0 N  91 52  0 W
> ...
>
>
> cty.dat:
>
> United States: *05*: *08*:  NA: 37.60:    91.87:     5.0: *K*:
> ...
>     =KH2TJ(3)[6],=KH6CT(5)[8],=KH6GK(3)[6],=*KH6M(5)[8]*,=KH6VM(3)[6],
> ...
> Hawaii:                   31:  61:  OC:   21.12:   157.48: 10.0: *KH6*:
>     
> AH6,AH7,*KH6*,KH7,NH6,NH7,WH6,WH7,=AA7DI,=AB7RT,=AE7QR,=AG6QD,=K2GT,=K2SHO,
> ...
>
> usdbraw.gz:
> ...
> *KH6M|*NAPLES*|FL*
> ...
>
> One of the two data is wrong, and knowing that KH6M is really in 
> Florida, the entity should be: *226*, ITU: *08 *and CQ: *05*, and not 
> the current entity: *112*, ITU: *61* and CQ: *31*.
>
> That's why I get the discrepancy:
>
> 2022-05-06-06T06:30:21 - *KH6M*: *112 *-> *226 *| EA4URE-3 | DX | EA4URE
>
> I don't know if I've made myself clear.
>
>
> Regards,
>
> Kin
>
>
>
>
> El 06/05/2022 a las 1:41, Dirk Koopman via Dxspider-support escribió:
>
>> 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
>>
>>
>> _______________________________________________
>> Dxspider-support mailing list
>> Dxspider-support at tobit.co.uk
>> https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
>
> _______________________________________________
> 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/20220509/543c321b/attachment-0001.htm>

More information about the Dxspider-support mailing list