[Dxspider-support] Failure in cty.dat?

Kin joaquin at cronux.net
Fri May 6 08:20:10 BST 2022 

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.tobit.co.uk/pipermail/dxspider-support/attachments/20220506/a817e857/attachment.htm>

More information about the Dxspider-support mailing list