[Dxspider-support] Incorrect User details

Michael Carper mike at wa9pie.net
Thu Apr 9 03:18:29 BST 2015


Right... but I don't think the question was related to the "State" field.
The question was related to the COUNTRY field... which in DX Spider (not CC
Cluster) displays a "State" (actually, the "Primary Administrative
Subdivision" which is not based on the USDB.

So the real question is... "Why does the Country field show "Illinois" for
a station that the USDB shows CA?"

CC11^14262.0^W9TVX^
5-Apr-2015^2332Z^TEST^W9TVX^226^226^GB7MBC^8^4^8^4^CA^CA^
Illinois-K^Illinois-K^CM87^CM87

Mike, WA9PIE

On Wed, Apr 8, 2015 at 1:00 PM, Lee Sawkins <ve7cc at shaw.ca> wrote:

>  Oops a correction to my correction.  I should have said a KH6 in TX will
> give a string of TX for the state, not CA.
>
> ----- Original Message -----
> *From:* Lee Sawkins <ve7cc at shaw.ca>
> *To:* The DXSpider Support list <dxspider-support at dxcluster.org>
> *Sent:* Wednesday, April 08, 2015 10:57 AM
> *Subject:* Re: [Dxspider-support] Incorrect User details
>
> The cluster does a USDB lookup for all US and VE calls.  The spotter and
> dx state fields for W9TVX are both shown as CA, which is correct.  The
> problem is the CQ and ITU zones appear to derived from the call prefix.
> The zone fields are all wrong.  They should be 6 and 3, not 8 and 4 as
> shown.  The country is also determined by the call prefix.  A KH6 in TX
> will give a CC11 string of CA for the state and Hawaii for the country and
> wrong zones.  Spots for W4s in FL also give the wrong CQ zone as Spider
> thinks all W4s are in CQ zone 4.  There are many more US prefixes where the
> wrong zones are given.
>
> CC11^18074.1^KH6MB^ 7-Apr-2015^1637Z^^IK6SNR^112^85^IZ8BRI-2^61^31^28^15^
> TX^^Hawaii-KH6^Abruzzo-Marche-I^BL11^JN62
>
> Lee VE7CC
>
> ----- Original Message -----
> *From:* Michael Carper <mike at wa9pie.net>
> *To:* The DXSpider Support list <dxspider-support at dxcluster.org>
> *Sent:* Wednesday, April 08, 2015 10:35 AM
> *Subject:* Re: [Dxspider-support] Incorrect User details
>
> To be clear... the UCDB 'may be' where the stand-alone STATE fields in the
> CC11 string are populated.  But the STATE in the COUNTRY field is certainly
> not populated that way.  I think the information in the COUNTRY field were
> at the core of Ian's question.
>
> The problem with populating the STATE in the COUNTRY field with USDB data
> is that it's US specific.  In other words - that field contains the
> "Primary Administrative Subdivision" (see www.adif.org) information for
> ALL countries - not just the United States.  So correcting this problem
> with regards to the COUNTRY field in the CC11 string may cause problems
> with the way the "Primary Administrative Subdivision" is populated for
> 'other countries'.
>
> If I were to make a suggestion...
>
> I'd (a) remove the "Primary Administrative Subdivision" from the COUNTRY
> field in the CC11 string, have it show only country or country prefix, and
> (b) populate the "STATE" fields with the "code" for the "Primary
> Administrative Subdivisions" for all countries.
>
> Mike, WA9PIE
>
> On Mon, Apr 6, 2015 at 6:50 PM, Mike McCarthy, W1NR <lists at w1nr.net>
> wrote:
>
>> Actually, USDB is used for both spotter and spotted callsigns but I
>> don't think it goes along in the normal PC11 messages between clusters
>> and is looked up each time from each clusters database.
>>
>> The issue is where the CC11 comes from. I am no expert on the protocols,
>> but I think CC11 is from a user application. It is possible that it was
>> derived from an outdated buckmaster database on some spotters computer.
>>
>> Mike, W1NR
>>
>> On 04/06/2015 06:40 PM, Steve Carroll - AA4U wrote:
>> > Michael - If what you speak is true, then I have a suggestion for
>> Dirk...
>> >
>> > Both of my DXSpider nodes have the US Database loaded, which shows the
>> > logged in user (almost instantaneously) the EXACT state of the spot
>> > originator. Here's an example [last column]:
>> >
>> > DX de W3LPL:     10107.0  VU2GSM       Heard in MA
>> > 2225Z MD
>> > DX de KD2FLY:    28120.7  LU2DO        PSK31
>> > 2225Z NY
>> > DX de K0GU:      50101.9  CE2AWW       DN70MQ<>FF47FA in/out
>> > 2226Z CO
>> > DX de K6ND:      24910.0  ZL7E         QSX 24912.1 559 in MA
>> > 2226Z MA
>> > DX de KD2JA:     24910.0  ZL7E         Tnx new one
>> > 2226Z FL
>> > DX de AD4Z:      50072.0  LU4FM/B      599 in EL95tu
>> > 2226Z FL
>> > DX de WD4AB:     50110.0  LU5VV        EL95UO<>FE48HI 57
>> > 2227Z FL
>> >
>> > The USDB file comes directly from the FCC database, which shows the
>> > current 'home address on record' for each US amateur. In your example,
>> > the following data is from the USDB file:
>> >
>> > sh/usdb w9tvx
>> > W9TVX   -> Mountain View, CA
>> >>
>> > sh/usdb wa9pie
>> > WA9PIE  -> Prosper, TX
>> >
>> > Why couldn't this same lookup process be used to correctly propagate the
>> > CC11 line in the example?
>> >
>> > Just a thought...
>> >
>> > 73, Steve - AA4U
>> >
>> >
>> >
>> > On 4/6/2015 9:24 AM, Michael Carper wrote:
>> >> DX Spider doesn't do a "callsign lookup" when it sends out spots.  For
>> >> my friends outside the US, this topic requires a bit of detail.
>> >>
>> >> In the US, there are 10 call areas.  Many many years ago, the
>> >> governing body here in the US (the FCC) forced people to change their
>> >> callsign when they moved to another call area.  But this became an
>> >> administrative problem for the FCC as the volume of people relocating
>> >> in this country increased.
>> >>
>> >> SO... here's the current significance of the NUMBER in a US ham's
>> >> callsign.
>> >> - the number is assigned from the call area that the person lived when
>> >> they were issued their first license
>> >> - if they move to another call area, they are not required to change
>> >> their call.
>> >>
>> >> A nice map of this is
>> >> at
>> http://en.wikipedia.org/wiki/Amateur_radio_licensing_in_the_United_States
>> >>
>> >> SO... what this means for DX Spider...
>> >>
>> >> The "COUNTRY" field in the CC11 string for DX Spider is composed of a
>> >> "US State" followed by the "Country Prefix".  So in this example, we
>> >> know that W9TVX is in the United States... so the prefix "K" makes
>> >> sense.  But here is what I've figured out about why it shows as
>> >> "Illinois".
>> >>
>> >> The US Call areas and associated States are as follows:
>> >> US Call Area 1 - CT,MA,ME,NH,RI,VT
>> >> US Call Area 2 - NJ,NY
>> >> US Call Area 3 - DC,DE,MD,PA
>> >> US Call Area 4 - AL,FL,GA,KY,NC,SC,TN,VA
>> >> US Call Area 5 - AR,LA,MS,NM,OK,TX
>> >> US Call Area 6 - CA
>> >> US Call Area 7 - AZ,ID,MT,NV,OR,UT,WA,WY
>> >> US Call Area 8 - MI,OH,WV
>> >> US Call Area 9 - IL,IN,WI
>> >> US Call Area 10 - CO,IA,KS,MN,MO,ND,NE,SD
>> >>
>> >> Because clusters do not do a callsign lookup when sending a spot to
>> >> connected users, the cluster has no idea which US State the spotted
>> >> station or spotting station are in.
>> >>
>> >> So... what DX Spider does is use the FIRST US State in alphabetical
>> >> order for a given callarea and sends the full name of the state.
>> >>
>> >> For example...
>> >>
>> >> W9TVX... it's got a "9" in it... the first US State (alphabetically)
>> >> in the list of States in call area 9 is "IL"... and that's
>> >> "Illinois"... so let's send that one!  That's why you
>> >> get ^Illinois-K^, even though he's in California.
>> >>
>> >> If you spotted me (WA9PIE), you would also get ^Illinois-K^, even
>> >> though I live in Texas now.
>> >>
>> >> In reality, the only States that ever get used are the first ones
>> >> alphabetically - Connecticut, New Jersey, District-of-Columbia,
>> >> Alabama, Arkansas, California, Arizona, Michigan, Illinois, and
>> >> Colorado.  Regardless of where the station is actually located, DX
>> >> Spider looks at the number in the call and grabs from these.
>> >>
>> >> Most of the time, the US State in this field will be incorrect.
>> >> Within Ham Radio Deluxe, we offer the display of a field that strips
>> >> off the US State (because people complained about it being wrong).
>> >>
>> >> The only fix for this is to re-code DX Spider so that the Country
>> >> field no longer has the US State in it.  However...
>> >>
>> >> If you look at spots for other countries, you'll see that it also
>> >> populates "Secondary Administrative Districts" for other countries
>> >> too... in Canada, you'll see Provinces and Territories that are
>> >> incorrect for the same reasons.
>> >>
>> >> But anyway... a long-winded answer.  But very complete.
>> >>
>> >> Bottom line is - the inclusion of this information into the Country
>> >> field is an "estimation" and is not related to any valid callsign
>> >> lookup information.
>> >>
>> >> Mike, WA9PIE
>> >>
>> >> On Mon, Apr 6, 2015 at 3:29 AM, Ian Maude <maudeij at gmail.com
>> >> <mailto:maudeij at gmail.com>> wrote:
>> >>
>> >>     Hi all,
>> >>     I have a user who is not being shown correctly in the cluster.  He
>> >>     sent me the output from a test spot he sent..
>> >>
>> >>     CC11^14262.0^W9TVX^
>> >>
>>  5-Apr-2015^2332Z^TEST^W9TVX^226^226^GB7MBC^8^4^8^4^CA^CA^Illinois-K^Illinois-K^CM87^CM87
>> >>
>> >>     W9TVX is in Mountain View CA and sh/usdb puts him in the right
>> place.
>> >>     This is happening for him even with a direct telnet to the cluster
>> so
>> >>     it would appear to not be a logging program issue.  Any thoughts
>> would
>> >>     be appreciated.
>> >>
>> >>     73 Ian
>> >>
>> >>     _______________________________________________
>> >>     Dxspider-support mailing list
>> >>     Dxspider-support at dxcluster.org <mailto:
>> Dxspider-support at dxcluster.org>
>>  >>     http://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
>> >>
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> Dxspider-support mailing list
>> >> Dxspider-support at dxcluster.org
>> >> http://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
>> >
>> >
>> >
>> > _______________________________________________
>> > Dxspider-support mailing list
>> > Dxspider-support at dxcluster.org
>> > http://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
>> >
>>
>> _______________________________________________
>> Dxspider-support mailing list
>> Dxspider-support at dxcluster.org
>> http://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
>>
>
>  ------------------------------
>
> _______________________________________________
> Dxspider-support mailing list
> Dxspider-support at dxcluster.org
> http://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
>
>  ------------------------------
>
> _______________________________________________
> Dxspider-support mailing list
> Dxspider-support at dxcluster.org
> http://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
>
>
> _______________________________________________
> Dxspider-support mailing list
> Dxspider-support at dxcluster.org
> http://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.tobit.co.uk/pipermail/dxspider-support/attachments/20150408/2edc86ca/attachment-0001.html>


More information about the Dxspider-support mailing list