[Dxspider-support] Failure in cty.dat?
Lee Sawkins
ve7cc at shaw.ca
Mon May 9 16:30:45 BST 2022
If I do a "sh/dx/1 KH6M" on my VE7CC-1 cluster I receive the following CC11:CC11^50000.0^KH6M^06-May-2022^0630Z^TEST^EA4URE^28^EA4URE-2^EA4URE-3^8^5^37^14^FL^^K^EA^EL96^IN80^^0^26.5/81^127.0.0.1^9122790Lee VE7CC.
----- Original Message -----
From: Joaquin via Dxspider-support <dxspider-support at tobit.co.uk>
To: The DXSpider Support list <dxspider-support at tobit.co.uk>
Cc: Joaquin <joaquin at cronux.net>
Sent: Mon, 09 May 2022 08:05:25 -0600 (MDT)
Subject: Re: [Dxspider-support] Failure in cty.dat?
<div dir="auto"><div dir="auto">I don't think I explained myself well.<br /></div><div dir="auto"><br /></div><div dir="auto">1. I connect to my spider node via telnet, run set/ve7cc</div><div dir="auto"><br /></div><div dir="auto">2. From another telnet connection against my spider node, I publish the spot:</div><div dir="auto">dx KH6M 50000 TEST</div><div dir="auto"><br /></div><div dir="auto">3. All users on my node receive the following spot:</div><div dir="auto">EA4URE DX: 50000.0 KH6M TEST 0630Z</div><div dir="auto"><br /></div><div dir="auto">4. In the session where I executed set/ve7cc I get:</div><div dir="auto">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</div><div dir="auto"><br /></div><div dir="auto">I believe that the CC11 sentencia sent to me by my spider node has been generated by my own node according to the values recorded for the dx entity and state in the wpxloc.raw, cty.dat and usdbraw.gz files. If so, I don't understand why it says it's in Hawaii but its State is FL.</div><div dir="auto"><br /></div><div dir="auto">All this comes from a complaint from one of the users of the cluster, and after analyzing it (I think correctly), I think that there is something wrong or I don't understand it. Excuse my clumsiness.</div><div dir="auto"><br /></div><div dir="auto">73 de Kin</div><div dir="auto">EA3CV</div><div dir="auto"><br /></div></div><div class="gmail_extra"><br /><div class="gmail_quote">El 9 may. 2022 14:06, Dirk Koopman via Dxspider-support <dxspider-support@tobit.co.uk> escribió:<br /><blockquote class="quote" style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>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. <br /><br />
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). <br /><br />
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. <br /><br />
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. <br /><br />
73 Dirk G1TLH<br />
<br />
On 06/05/2022 08:20, Kin via Dxspider-support wrote:<br /></div><blockquote><p><font face="Courier New, Courier, monospace">Hi Dirk,<br /><br />
* My scenario for capturing information is as follows:<br /><br />
DXspider node build 439<br />
cty.dat, wpxloc.raw, usdbraw.gz to last update<br />
I get the data via CC11<br /><br />
* To process the information:<br /><br />
Routine that uses a copy of the cty.dat, wpxloc.raw,
usdbraw.gz identical to the one that the DXSpider node has.<br /><br />
* Procedure:<br /><br />
For each CC11 I receive:<br /><br />
1. I get the fields "call dx" and "spotted dxcc country".<br />
2. Externally I do a search for "call/country" in cty.dat.<br />
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.<br /><br />
I tried to generate a spot locally from my DXSpider, and I
found that the entity number returned by a CC11 is wrong.<br /><br />
The test was as follows:<br /><br /><b>KH6M </b>is in Florida (see qrz.com).<br /></font></p><p><font face="Courier New, Courier, monospace">TX: dx KH6M 50000
TEST<br />
RX: DX de EA4URE: 50000.0 <b>KH6M </b>TEST
0630Z<br /><br /><br />
Debug file:<br />
...<br />
1651818621^(chan) -> D EA4M DX de EA4URE: 50000.0 <b>KH6M </b>
TEST 0630Z<br />
1651818621^(chan) -> D N5KD-4 CC11^50000.0^KH6M^
6-May-2022^0630Z^TEST^EA4URE^<b>112</b>^34^EA4URE-3^<b>61</b>^<b>31</b>^37^14^<b>FL</b>^^<b>Hawaii-KH6</b>^BA-CC-CR-CU-GU-M-TO-EA^EL86^IN80<br />
...<br /><br />
The CC11 sent to me by my dxspider shows:<br /><br />
Entity: <b>112 </b>-> Hawaii<br />
State: <b>FL</b><br />
ITU: <b>61</b><br />
CQ: <b>31</b><br /><br /><br />
I consult the files wpxloc.raw, cty.dat and usdbraw.gz<br /><br />
wpxloc.raw:<br />
... <br />
KH6 Hawaii-KH6 <b>112
61 31</b> 10.00 21 7 0 N 157 29 0 W @<br />
...<br />
K United-States-K <b>226
8 5</b> 5.00 37 36 0 N 91 52 0 W @<br />
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<br />
...<br /><br /><br />
cty.dat:<br /><br />
United States: <b>05</b>: <b>08</b>: NA:
37.60: 91.87: 5.0: <b>K</b>:<br />
...<br />
=KH2TJ(3)[6],=KH6CT(5)[8],=KH6GK(3)[6],=<b>KH6M(5)[8]</b>,=KH6VM(3)[6],<br />
...<br />
Hawaii: 31: 61: OC: 21.12: 157.48:
10.0: <b>KH6</b>:<br />
AH6,AH7,<b>KH6</b>,KH7,NH6,NH7,WH6,WH7,=AA7DI,=AB7RT,=AE7QR,=AG6QD,=K2GT,=K2SHO,<br />
...<br /><br />
usdbraw.gz:<br />
...<br /><b>KH6M|</b>NAPLES<b>|FL</b><br />
...<br /><br />
One of the two data is wrong, and knowing that KH6M is really
in Florida, the entity should be: <b>226</b>, ITU: <b>08 </b>and
CQ: <b>05</b>, and not the current entity: <b>112</b>, ITU:
<b>61</b> and CQ: <b>31</b>.<br /><br />
That's why I get the discrepancy:<br /><br />
2022-05-06-06T06:30:21 - <b>KH6M</b>: <b>112 </b>-> <b>226
</b>| EA4URE-3 | DX | EA4URE<br /><br />
I don't know if I've made myself clear.</font></p><p><font face="Courier New, Courier, monospace"><br /></font></p><p><font face="Courier New, Courier, monospace">Regards,</font></p><p><font face="Courier New, Courier, monospace">Kin<br /></font></p><p><br /></p><p><br /></p><p><br /></p><p>El 06/05/2022 a las 1:41, Dirk Koopman via Dxspider-support
escribió:<br /></p><blockquote><div>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 <u><b>not</b></u> provided by
an incoming spot (in PC protocol) from another node or the
RBN. <br /><br />
I don't understand where you are getting this "entity code"
from using standard data formats. <br /><br />
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. <br /><br />
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.<br /><br />
Dirk<br /><br />
On 05/05/2022 18:06, Kin via Dxspider-support wrote:<br /></div><blockquote><p><br /></p><div>El 05/05/2022 a las 10:52,
Joaquin escribió:<br /></div><blockquote><div dir="auto"><span style="color:rgb( 77 , 81 , 86 );font-family:'roboto' , 'helvetica neue' , 'arial' , sans-serif;font-size:small;background-color:rgb( 255 , 255 , 255 )">Hi,</span><div dir="auto"><span style="color:rgb( 77 , 81 , 86 );font-family:'roboto' , 'helvetica neue' , 'arial' , sans-serif;font-size:small;background-color:rgb( 255 , 255 , 255 )">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) :</span></div><div dir="auto"><span style="background-color:rgb( 255 , 255 , 255 )"><font size="2" face="roboto, helvetica
neue, arial, sans-serif" color="#4d5156"><div dir="auto"><br /></div><div dir="auto">2022-05-04T08:53:17 -
KG6DX: 226 -> 107 | DH1TW-2 | DX | SV9CVY</div><div dir="auto">2022-05-04T09:21:27 -
KG6DX: 226 -> 107 | SK3W-6 | DX | UN3GX</div><div dir="auto">2022-05-04T14:03:31 -
K5ZYO: 226 -> 112 | AE5E | DX | N5NOQ</div><div dir="auto">2022-05-04T18:50:33 - NP3K:
120 -> 226 | W3LPL | DX | W3LPL</div><div dir="auto">2022-05-05T04:11:47 - KH6M:
112 -> 226 | IZ3LSV-6 | DX | IV3JER</div><div dir="auto">2022-05-05T05:35:45 -
KC8JNV: 226 -> 112 | EA4URE-5 | DX | EA1US</div><div dir="auto">2022-05-05T08:44:58 -
RP77P: 179 -> 182 | VE7CC-1 | DX | R8LA<br /></div><div dir="auto"><br /></div></font></span></div><div dir="auto"><span style="color:rgb( 77 , 81 , 86 );font-family:'roboto' , 'helvetica neue' , 'arial' , sans-serif;font-size:small;background-color:rgb( 255 , 255 , 255 )">Most of the spots that arrive
with the wrong entity belong to the RBN network:</span></div><div dir="auto"><br /></div><div dir="auto"><span style="background-color:rgb( 255 , 255 , 255 )"><font size="2" face="roboto, helvetica
neue, arial, sans-serif" color="#4d5156"><div dir="auto">2022-05-05T08:46:38 -
RP77U: 179 -> 182 | | RB | HA8TKS-#</div><div dir="auto">2022-05-05T08:46:54 -
RP77AB: 179 -> 182 | | RB | JH7CSU1-#</div><div dir="auto">2022-05-05T08:47:21 -
RP77V: 179 -> 182 | | RB | HA8TKS-#</div><div dir="auto">2022-05-05T08:47:21 -
RP77KM: 179 -> 182 | | RB | OE8TED-#</div><div dir="auto">2022-05-05T08:47:29 -
RP77TT: 179 -> 182 | | RB | HA8TKS-#</div><div dir="auto">2022-05-05T08:47:32 -
RP77GK: 179 -> 182 | | RB | MM0HVU-#</div><div dir="auto">2022-05-05T08:47:32 -
RP77TZ: 179 -> 182 | | RB | MM0HVU-#</div><div dir="auto">2022-05-05T08:47:32 -
RP77J: 179 -> 182 | | RB | DL9GTB-#</div><div dir="auto">2022-05-05T08:47:57 -
RP77GB: 179 -> 182 | | RB | DL8LAS-#</div><div dir="auto"><br /></div><div dir="auto">Kin</div><div dir="auto"><br /></div></font></span></div></div><div><br /><div class="elided-text">El 2 may. 2022 20:14, Kin via
Dxspider-support <a href="mailto:dxspider-support@tobit.co.uk" target="_blank" rel="nofollow noopener noreferrer"><dxspider-support@tobit.co.uk></a>
escribió:<br /><blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div><p><font face="Calibri"><font face="Courier New,
Courier, monospace">Hi Dirk,<br /><br />
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.<br />
I have looked at the code and I think you are
using the information from cty.dat to assign
the entity number. <br /><br />
Here is an example where you can see the
entity that arrives in the spot and the one
that should appear:</font></font></p><p><font face="Calibri"><font face="Courier New,
Courier, monospace">2022-05-02-02T08:27:33 -
KG6JDX: 226 -> 107<br />
2022-05-02-02T08:27:56 - RP77AB: 179 -> 182<br />
2022-05-02-02T11:12:22 - WB4JTT: 226 -> 112<br />
2022-05-02-02T13:04:04 - R9MA/1: 182 -> 179<br />
2022-05-02-02T17:11:28 - K2GT: 226 -> 112<br />
2022-05-02-02T17:43:19 - W5ERV: 226 -> 117</font></font></p><p><font face="Calibri"><font face="Courier New,
Courier, monospace">Could you tell me if it's
normal that it doesn't update them?<br /><br />
Regards,<br /><br />
Kin</font><br /></font><br /></p></div></blockquote></div><br /></div><br /><fieldset></fieldset><pre>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 <a href="mailto:dxspider-support@tobit.co.uk" target="_blank" rel="nofollow noopener noreferrer"><dxspider-support@tobit.co.uk></a> escribió:
</pre><blockquote><pre>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
</pre></blockquote></blockquote><br /><fieldset></fieldset><pre>_______________________________________________
Dxspider-support mailing list
<a href="mailto:Dxspider-support@tobit.co.uk" target="_blank" rel="nofollow noopener noreferrer">Dxspider-support@tobit.co.uk</a><a href="https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support" target="_blank" rel="nofollow noopener noreferrer">https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support</a></pre></blockquote><br /><br /><fieldset></fieldset><pre>_______________________________________________
Dxspider-support mailing list
<a href="mailto:Dxspider-support@tobit.co.uk" target="_blank" rel="nofollow noopener noreferrer">Dxspider-support@tobit.co.uk</a><a href="https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support" target="_blank" rel="nofollow noopener noreferrer">https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support</a></pre></blockquote><br /><fieldset></fieldset><pre>_______________________________________________
Dxspider-support mailing list
<a href="mailto:Dxspider-support@tobit.co.uk" target="_blank" rel="nofollow noopener noreferrer">Dxspider-support@tobit.co.uk</a><a href="https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support" target="_blank" rel="nofollow noopener noreferrer">https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support</a></pre></blockquote><br /></div></blockquote></div><br /></div>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.tobit.co.uk/pipermail/dxspider-support/attachments/20220509/df3d5b31/attachment-0001.htm>
More information about the Dxspider-support
mailing list