[Dxspider-support] Incorrect User details

Wed Apr 8 18:35:57 BST 2015

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.tobit.co.uk/pipermail/dxspider-support/attachments/20150408/865b8491/attachment.html>