<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">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 type="cite"
cite="mid:743538c7-8032-b933-1d82-a46cb87bf18e@cronux.net">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p><br>
</p>
<div class="moz-cite-prefix">El 05/05/2022 a las 10:52, Joaquin
escribió:<br>
</div>
<blockquote type="cite"
cite="mid:2b13098f-502f-465a-974a-343b2668a55d@email.android.com">
<meta http-equiv="content-type" content="text/html;
charset=UTF-8">
<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" style=""><br>
</div>
<div dir="auto" style="">2022-05-04T08:53:17 - KG6DX:
226 -> 107 | DH1TW-2 | DX | SV9CVY</div>
<div dir="auto" style="">2022-05-04T09:21:27 - KG6DX:
226 -> 107 | SK3W-6 | DX | UN3GX</div>
<div dir="auto" style="">2022-05-04T14:03:31 - K5ZYO:
226 -> 112 | AE5E | DX | N5NOQ</div>
<div dir="auto" style="">2022-05-04T18:50:33 - NP3K: 120
-> 226 | W3LPL | DX | W3LPL</div>
<div dir="auto" style="">2022-05-05T04:11:47 - KH6M: 112
-> 226 | IZ3LSV-6 | DX | IV3JER</div>
<div dir="auto" style="">2022-05-05T05:35:45 - KC8JNV:
226 -> 112 | EA4URE-5 | DX | EA1US</div>
<div dir="auto" style="">2022-05-05T08:44:58 - RP77P:
179 -> 182 | VE7CC-1 | DX | R8LA<br>
</div>
<div dir="auto" style=""><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" style="">2022-05-05T08:46:38 - RP77U:
179 -> 182 | | RB | HA8TKS-#</div>
<div dir="auto" style="">2022-05-05T08:46:54 - RP77AB:
179 -> 182 | | RB | JH7CSU1-#</div>
<div dir="auto" style="">2022-05-05T08:47:21 - RP77V:
179 -> 182 | | RB | HA8TKS-#</div>
<div dir="auto" style="">2022-05-05T08:47:21 - RP77KM:
179 -> 182 | | RB | OE8TED-#</div>
<div dir="auto" style="">2022-05-05T08:47:29 - RP77TT:
179 -> 182 | | RB | HA8TKS-#</div>
<div dir="auto" style="">2022-05-05T08:47:32 - RP77GK:
179 -> 182 | | RB | MM0HVU-#</div>
<div dir="auto" style="">2022-05-05T08:47:32 - RP77TZ:
179 -> 182 | | RB | MM0HVU-#</div>
<div dir="auto" style="">2022-05-05T08:47:32 - RP77J:
179 -> 182 | | RB | DL9GTB-#</div>
<div dir="auto" style="">2022-05-05T08:47:57 - RP77GB:
179 -> 182 | | RB | DL8LAS-#</div>
<div dir="auto" style=""><br>
</div>
<div dir="auto" style="">Kin</div>
<div dir="auto" style=""><br>
</div>
</font></span></div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">El 2 may. 2022 20:14, Kin via
Dxspider-support <a class="moz-txt-link-rfc2396E"
href="mailto:dxspider-support@tobit.co.uk"
moz-do-not-send="true"><dxspider-support@tobit.co.uk></a>
escribió:<br type="attribution">
<blockquote class="quote" style="margin: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 class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">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 class="moz-txt-link-rfc2396E" href="mailto:dxspider-support@tobit.co.uk" moz-do-not-send="true"><dxspider-support@tobit.co.uk></a> escribió:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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 class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Dxspider-support mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Dxspider-support@tobit.co.uk">Dxspider-support@tobit.co.uk</a>
<a class="moz-txt-link-freetext" href="https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support">https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support</a>
</pre>
</blockquote>
<br>
</body>
</html>