[Dxspider-support] Incorrect User details
Lee Sawkins
ve7cc at shaw.ca
Wed Apr 8 19:00:15 BST 2015
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
To: The DXSpider Support list
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
To: The DXSpider Support list
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.tobit.co.uk/pipermail/dxspider-support/attachments/20150408/528bcb4e/attachment-0001.html>
More information about the Dxspider-support
mailing list