[Dxspider-support] Incorrect User details
Michael Carper
mike at wa9pie.net
Sat Apr 11 23:52:39 BST 2015
Hmm... well, that went over well.
Mike, WA9PIE
On Wed, Apr 8, 2015 at 9:18 PM, Michael Carper <mike at wa9pie.net> wrote:
> 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/20150411/e049585b/attachment-0001.html>
More information about the Dxspider-support
mailing list