<html><head><style> body {height: 100%; color:#000000; font-size:12pt; font-family:lucida console,sans-serif;}</style></head><body><div>If I do a "sh/dx/1 KH6M" on my VE7CC-1 cluster I receive the following CC11:</div><div><br data-mce-bogus="1"></div><div>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^9122790</div><div><br data-mce-bogus="1"></div><div>Lee VE7CC.</div><div><br></div><div>----- Original Message -----<br>From: Joaquin via Dxspider-support <dxspider-support@tobit.co.uk><br>To: The DXSpider Support list <dxspider-support@tobit.co.uk><br>Cc: Joaquin <joaquin@cronux.net><br>Sent: Mon, 09 May 2022 08:05:25 -0600 (MDT)<br>Subject: Re: [Dxspider-support] Failure in cty.dat?<br></div><div><br></div><div><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<br>into account information in CC11 that is not in a stock PC11 or<br>PC61. I don't recommend that you do either. DXSpider using<br>wpxloc.raw country numbers and CCCluster doesn't (and I don't know<br>what is uses). Similarly there are one or two other makes of<br>cluster software, e.g. ARC4 & ARC6, even one or two original<br>AK1A nodes, connected by AX25 that use (only) AD1C knows. Then<br>there is the issue of which version of wpxloc.raw any node (that<br>uses it) has installed. <br /><br /><br>One of the advantages of wpxloc.raw is that new countries, that<br>have existing country codes, but have split away/become<br>independent/otherwise been give a new prefix to differentiate them<br>from what ever country they were part of - any of which makes them<br>a new DXCC entity - gets a new wpxloc.raw country number. This<br>means that spots from 1997 will still have decodable country<br>numbers pointing to the prefix in use at the time (mostly). <br /><br /><br>On the occasions that I decode CC11 (and DXSpider itself does not<br>do this), I *always* ignore any of the country code/zones/US state<br>info. If I find it necessary, I take this information from the<br>generated prefix file that DXSpider used. <br /><br /><br>I think you are trying to compare apples and aubergines with this<br>program and I doubt you will ever be able to (100%) reliably get<br>the information you are after. <br /><br /><br>73 Dirk G1TLH<br /><br> <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 /><br>* My scenario for capturing information is as follows:<br /><br /><br>DXspider node build 439<br /><br>cty.dat, wpxloc.raw, usdbraw.gz to last update<br /><br>I get the data via CC11<br /><br /><br>* To process the information:<br /><br /><br>Routine that uses a copy of the cty.dat, wpxloc.raw,<br>usdbraw.gz identical to the one that the DXSpider node has.<br /><br /><br>* Procedure:<br /><br /><br>For each CC11 I receive:<br /><br /><br>1. I get the fields "call dx" and "spotted dxcc country".<br /><br>2. Externally I do a search for "call/country" in cty.dat.<br /><br>3. I compare the spotted entity number from CC11 with the one<br>I get, and if it is different I send it to a log.<br /><br /><br>I tried to generate a spot locally from my DXSpider, and I<br>found that the entity number returned by a CC11 is wrong.<br /><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<br>TEST<br /><br>RX: DX de EA4URE: 50000.0 <b>KH6M </b>TEST <br>0630Z<br /><br /><br /><br>Debug file:<br /><br>...<br /><br>1651818621^(chan) -> D EA4M DX de EA4URE: 50000.0 <b>KH6M </b><br>TEST 0630Z<br /><br>1651818621^(chan) -> D N5KD-4 CC11^50000.0^KH6M^<br>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 /><br /><br>The CC11 sent to me by my dxspider shows:<br /><br /><br>Entity: <b>112 </b>-> Hawaii<br /><br>State: <b>FL</b><br /><br>ITU: <b>61</b><br /><br>CQ: <b>31</b><br /><br /><br /><br>I consult the files wpxloc.raw, cty.dat and usdbraw.gz<br /><br /><br>wpxloc.raw:<br /><br>... <br /><br>KH6 Hawaii-KH6 <b>112<br>61 31</b> 10.00 21 7 0 N 157 29 0 W @<br /><br>...<br /><br>K United-States-K <b>226 <br>8 5</b> 5.00 37 36 0 N 91 52 0 W @<br /><br>AA,AB,AC,AD,AE,AF,AG,AI,AJ,AK,N,W United-States-K 226 8 <br>5 5.00 37 36 0 N 91 52 0 W<br /><br>...<br /><br /><br /><br>cty.dat:<br /><br /><br>United States: <b>05</b>: <b>08</b>: NA: <br>37.60: 91.87: 5.0: <b>K</b>:<br /><br>...<br /><br> =KH2TJ(3)[6],=KH6CT(5)[8],=KH6GK(3)[6],=<b>KH6M(5)[8]</b>,=KH6VM(3)[6],<br /><br>...<br /><br>Hawaii: 31: 61: OC: 21.12: 157.48: <br>10.0: <b>KH6</b>:<br /><br> AH6,AH7,<b>KH6</b>,KH7,NH6,NH7,WH6,WH7,=AA7DI,=AB7RT,=AE7QR,=AG6QD,=K2GT,=K2SHO,<br /><br>...<br /><br /><br>usdbraw.gz:<br /><br>...<br /><b>KH6M|</b>NAPLES<b>|FL</b><br /><br>...<br /><br /><br>One of the two data is wrong, and knowing that KH6M is really<br>in Florida, the entity should be: <b>226</b>, ITU: <b>08 </b>and<br>CQ: <b>05</b>, and not the current entity: <b>112</b>, ITU:<br><b>61</b> and CQ: <b>31</b>.<br /><br /><br>That's why I get the discrepancy:<br /><br /><br>2022-05-06-06T06:30:21 - <b>KH6M</b>: <b>112 </b>-> <b>226<br></b>| EA4URE-3 | DX | EA4URE<br /><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<br>escribió:<br /></p><blockquote><div>The problem with this is nothing<br>specific to do with DXSpider. All spots are prepared for<br>storage or processing by one routine (Spot::prepare). This<br>turns the fields of an incoming PC11 or PC61 into an array<br>with all the extra information like: country code, cq zone,<br>itu zone and any US State 2 letter code. It does not matter<br>where that spot comes from, whether it originates from a<br>PC11/PC61/RBN Spot line. That line is (one way or another)<br>split up into a set of fields that these spots contain and<br>then pushed through Spot::prepare. The result of that is a<br>new, extended, record and it is this record that is the used<br>for all processes in DXSpider (like filtering, spot formatting<br>and display). The Spot code does not recognise any country<br>code information because it is <u><b>not</b></u> provided by<br>an incoming spot (in PC protocol) from another node or the<br>RBN. <br /><br /><br>I don't understand where you are getting this "entity code"<br>from using standard data formats. <br /><br /><br>If you are trying to parse CC11 spot lines (a probably more<br>successful way of doing "passive mode" connections than AR-C4<br>nodes used) then you need to know that DXSpider CC11 lines are<br>subtly different from CCCluster ones in the area of "added<br>information". Basically Lee VE7CC continued to extend his<br>version of CC11 from the field order we agreed upon many years<br>ago. This is a relatively new situation that has only recently<br>come to light. Unfortunately, I don't believe that I can<br>change my version to his without causing people more (and<br>different) pain. So the solution is to just use the fields in<br>CC11 that provide the standard spot information and then, if<br>you need then, run that data through Spot::Prepare. This is<br>the only way of getting a self-consistent "prepared" spot<br>record. If that is not possible, then you will need to know<br>(or work out) what sort of node you are connecting to so that<br>you use the correct fields for the data that you are looking<br>for. <br /><br /><br>If you need to know more about CC11 formats, email me offline<br>and I'll dig out some emails on the subject from January this<br>year.<br /><br /><br>Dirk<br /><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,<br>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<br>DXSpider and CC nodes that are not pruning the correct<br>entity. Among these there is one that I can assure you<br>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<br>neue, arial, sans-serif" color="#4d5156"><div dir="auto"><br /></div><div dir="auto">2022-05-04T08:53:17 -<br>KG6DX: 226 -> 107 | DH1TW-2 | DX | SV9CVY</div><div dir="auto">2022-05-04T09:21:27 -<br>KG6DX: 226 -> 107 | SK3W-6 | DX | UN3GX</div><div dir="auto">2022-05-04T14:03:31 -<br>K5ZYO: 226 -> 112 | AE5E | DX | N5NOQ</div><div dir="auto">2022-05-04T18:50:33 - NP3K:<br>120 -> 226 | W3LPL | DX | W3LPL</div><div dir="auto">2022-05-05T04:11:47 - KH6M:<br>112 -> 226 | IZ3LSV-6 | DX | IV3JER</div><div dir="auto">2022-05-05T05:35:45 -<br>KC8JNV: 226 -> 112 | EA4URE-5 | DX | EA1US</div><div dir="auto">2022-05-05T08:44:58 -<br>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<br>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<br>neue, arial, sans-serif" color="#4d5156"><div dir="auto">2022-05-05T08:46:38 -<br>RP77U: 179 -> 182 | | RB | HA8TKS-#</div><div dir="auto">2022-05-05T08:46:54 -<br>RP77AB: 179 -> 182 | | RB | JH7CSU1-#</div><div dir="auto">2022-05-05T08:47:21 -<br>RP77V: 179 -> 182 | | RB | HA8TKS-#</div><div dir="auto">2022-05-05T08:47:21 -<br>RP77KM: 179 -> 182 | | RB | OE8TED-#</div><div dir="auto">2022-05-05T08:47:29 -<br>RP77TT: 179 -> 182 | | RB | HA8TKS-#</div><div dir="auto">2022-05-05T08:47:32 -<br>RP77GK: 179 -> 182 | | RB | MM0HVU-#</div><div dir="auto">2022-05-05T08:47:32 -<br>RP77TZ: 179 -> 182 | | RB | MM0HVU-#</div><div dir="auto">2022-05-05T08:47:32 -<br>RP77J: 179 -> 182 | | RB | DL9GTB-#</div><div dir="auto">2022-05-05T08:47:57 -<br>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<br>Dxspider-support <a href="mailto:dxspider-support@tobit.co.uk" target="_blank" rel="nofollow noopener noreferrer"><dxspider-support@tobit.co.uk></a><br>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,<br>Courier, monospace">Hi Dirk,<br /><br /><br>I've been seeing for a while that some<br>callsigns are shown with the wrong entity<br>number, although in the cty.dat they are<br>correctly assigned.<br /><br>I have looked at the code and I think you are<br>using the information from cty.dat to assign<br>the entity number. <br /><br /><br>Here is an example where you can see the<br>entity that arrives in the spot and the one<br>that should appear:</font></font></p><p><font face="Calibri"><font face="Courier New,<br>Courier, monospace">2022-05-02-02T08:27:33 -<br>KG6JDX: 226 -> 107<br /><br>2022-05-02-02T08:27:56 - RP77AB: 179 -> 182<br /><br>2022-05-02-02T11:12:22 - WB4JTT: 226 -> 112<br /><br>2022-05-02-02T13:04:04 - R9MA/1: 182 -> 179<br /><br>2022-05-02-02T17:11:28 - K2GT: 226 -> 112<br /><br>2022-05-02-02T17:43:19 - W5ERV: 226 -> 117</font></font></p><p><font face="Calibri"><font face="Courier New,<br>Courier, monospace">Could you tell me if it's<br>normal that it doesn't update them?<br /><br /><br>Regards,<br /><br /><br>Kin</font><br /></font><br /></p></div></blockquote></div><br /></div><br /><fieldset></fieldset><pre>Hi,<br>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) :<br></div><div><br></div><div>2022-05-04T08:53:17 - KG6DX: 226 -> 107 | DH1TW-2 | DX | SV9CVY<br>2022-05-04T09:21:27 - KG6DX: 226 -> 107 | SK3W-6 | DX | UN3GX<br>2022-05-04T14:03:31 - K5ZYO: 226 -> 112 | AE5E | DX | N5NOQ<br>2022-05-04T18:50:33 - NP3K: 120 -> 226 | W3LPL | DX | W3LPL<br>2022-05-05T04:11:47 - KH6M: 112 -> 226 | IZ3LSV-6 | DX | IV3JER<br>2022-05-05T05:35:45 - KC8JNV: 226 -> 112 | EA4URE-5 | DX | EA1US<br>2022-05-05T08:44:58 - RP77P: 179 -> 182 | VE7CC-1 | DX | R8LA<br></div><div><br></div><div>Most of the spots that arrive with the wrong entity belong to the RBN network:<br></div><div><br></div><div>2022-05-05T08:46:38 - RP77U: 179 -> 182 | | RB | HA8TKS-#<br>2022-05-05T08:46:54 - RP77AB: 179 -> 182 | | RB | JH7CSU1-#<br>2022-05-05T08:47:21 - RP77V: 179 -> 182 | | RB | HA8TKS-#<br>2022-05-05T08:47:21 - RP77KM: 179 -> 182 | | RB | OE8TED-#<br>2022-05-05T08:47:29 - RP77TT: 179 -> 182 | | RB | HA8TKS-#<br>2022-05-05T08:47:32 - RP77GK: 179 -> 182 | | RB | MM0HVU-#<br>2022-05-05T08:47:32 - RP77TZ: 179 -> 182 | | RB | MM0HVU-#<br>2022-05-05T08:47:32 - RP77J: 179 -> 182 | | RB | DL9GTB-#<br>2022-05-05T08:47:57 - RP77GB: 179 -> 182 | | RB | DL8LAS-#<br></div><div><br></div><div>Kin<br></div><div><br></div><div><br></div><div><br></div><div><br>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></pre><blockquote><pre>Hi Dirk,<br></div><div><br></div><div>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></div><div><br></div><div>Here is an example where you can see the entity that arrives in the spot and the one that should appear:<br></div><div><br></div><div>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<br></div><div><br></div><div>Could you tell me if it's normal that it doesn't update them?<br></div><div><br></div><div>Regards,<br></div><div><br></div><div>Kin<br></div><div><br></div><div></pre></blockquote></blockquote><br /><fieldset></fieldset><pre>_______________________________________________<br>Dxspider-support mailing list<br><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>_______________________________________________<br>Dxspider-support mailing list<br><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>_______________________________________________<br>Dxspider-support mailing list<br><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><br></div></body></html>