| |
ZL3AI > APRDIG 15.10.03 17:00l 268 Lines 11288 Bytes #999 (0) @ WW
BID : 2151-ZL3AI
Read: GUEST
Subj: TAPR Digest, Oct 13, 1/2
Path: DB0FHN<DB0THA<DB0ERF<DB0SHL<DB0FP<DB0CWS<DB0SIF<DB0EA<DB0RES<ON0AR<
WB0TAX<ZL2TZE<ZL3VML
Sent: 031015/1231Z @:ZL3VML.#80.NZL.OC #:10505 [Chch-NZ] FBB7.00i $:2151-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
TAPR APRS Special Interest Group Digest for Monday, October 13, 2003.
1. APRS Regions
2. Re: APRS Regions
3. Re: APRS Regions
4. RE: TExt messaging to Sprint Phones
5. RE: TExt messaging to Sprint Phones
6. RE: TExt messaging to Sprint Phones
7. PMAP30.OCX
----------------------------------------------------------------------
Subject: APRS Regions
From: Bob Bruninga <bruninga@usna.edu>
Date: Mon, 13 Oct 2003 10:00:34 -0400 (EDT)
X-Message-Number: 1
The population density of the USA is roughtly broken up into clusters. I
took the liberty of studying the map and trying to bound these regions
into areas of interest. Making sure the boundries passed through
hinterlands.
Under the new APRS paradigm, it should be easy to solve the BIG APRS
FLOODING and QRM problems by focusing on these regions individually.
Make LANn-N's or firewalled WIDEn-N's within them, and then make LINKn-N's
between them and/or through them. In some areas making other city
LANn-N's within them may be needed. But all of this can be done NOW using
existing DIGI's with proper design of UIDIGI, UIFLOOD, UITRACE commands.
I began making this list as a Center point Plus/Minus a range. That is
why some of the lines are wierd. Look at your area and let me know if
there is a better location to draw the lines. One use of this table is to
then do FINDU searches of the statistics of use and see how we should
optimize traffic for each region. Let me know if I left out any place.
APRS Region LATITUDE LONGITUDE
---------------- ---------- ------------
Portland/Seattle 44 52 118 126
NOCAL 39.5 44 117.5 122.5
CA-CEN 35.5 39.5 118 124
SOCAL 33.5 35.5 115.5 121.5
San Diego 32.5 33.5 114.5 118
Idaho/Montanna 42 50 104 118
Utah 37 45 108 116
Colorado 37 43 101 109
Arizona 30 38 108 116
New Mexico 31 37 102 110
Dakotas/Neb 39 49 96 104
Minneapolis 43 47 89 97
Iowa 40 44 90 96
Kansas City 37 41 92 98
St Louis 36 42 87 93
Oklahoma City 34 38 94 100
N. Texas 30 38 99 105
Dallas 31 35 93 101
S. Texas 27 31 93 101
Memphis/Arkansas 33 37 88 94
Louisanna 29 33 87 93
Wisconsin 42.5 46 87 91
Chicago 40.2 42.8 86 90
Indianna 39 41 85 87
Michigan 42 46 81.5 86.5
Ohio 38 42 81 85
Kentucky 36.8 39.2 82 88
Knoxville 35 37 82 86
Nashville 35 37 86 89
Alabama 31 35 85 89
Ontario 42.5 49.5 75.5 82.5
Pittsburg 38.8 42.2 78 82
Virginia 36.5 38.5 75 82.5
North Carolina 35 37 74 82.5
Georgia 33 35 82 86
South Carolina 31 35.5 78 83.5
N. Florida 29 31 80 88
Central Florida 27.2 29 80 84
S. Florida 24 27.2 79 83
Baltimore/WashDC 38 40 75 78
NYC/NJ 39.5 42.5 72 76
New England 41.5 45.5 67 73
Quebec 42 49 70 76
----------------------------------------------------------------------
Subject: Re: APRS Regions
From: Bob Bruninga <bruninga@usna.edu>
Date: Mon, 13 Oct 2003 14:38:59 -0400 (EDT)
X-Message-Number: 2
Overnight SYSOPS can create these LANS with NO IMPACT on current
usage, while providing a seamless transition to the new Paradigm.
SImply make the following settings in all DIGIs in the area:
UIFLOOD WIDE,28,NOID
UITRACE LANNAME,28 <==LAN name goes here
The result is that users can immediately begin using the new LAN
NAME for all local n-N traffic and the WIDEn-N will continue to
work. Once you have the majority of users shifted over and beginning to
use the LANNAME and the PATHS within the LANn-N are well known, then you
can SWAP the parameters in the digis to:
UIFLOOD LANAME,28,NOID
UITRACE WIDE,28
Then all the LANn-N is VERY efficient and you dont need PATH data on it,
and the WIDEn-N paths will trace so that you can then begin to trace out
where the problems are coming from. and decide to approach abusive users
or to put a FIREWALL digi where the most WIDEn-N QRM is coming from.
Here is the revised list with some improvements on the borders and
an estimated NAME for the LANs. Where these REGIONS are too big, and have
more than 50 to 100 users, you will need to define smaller sub-LANn-N's.
APRS Region LANn-N LATITUDE LONGITUDE
----------------- -------- ---------- ------------
Oregon/Washington ORWAn-N 42 52 118 126
NOCAL NOCALn-N 39.5 42 118 126
CA-CEN CCALn-N 36 39.5 118 126
SOCAL SOCALn-N 33.5 36 115.5 121.5
San Diego SDn-N 32 33.5 114.5 118
Idaho/Montanna IDMTn-N 42 50 104 118
Nevada NVDA-N 35.5 42 114 118
Utah SLCn-N 37 42 109 114
Colorado COLn-N 37 41 102 109
Arizona AZn-N 30 38 109 114
New Mexico NMn-N 31 37 102 109
Dakotas/Neb DKTNEn-N 40 49 96 104
Minneapolis MNSPn-N 43 49 89 96
Iowa IAn-N 40 43 90 96
Kansas City/MO KCMOn-N 37 40 92 102
St Louis STLMOn-N 36 42 88 92
Oklahoma City OKCn-N 34 37 94 100
N. Texas NTEXn-N 29 37 100 103
Dallas DALSn-N 31 35 93 100
S. Texas STEXn-N 26 31 93 100
W.Texas WTEXn-N 29 32 100 107
Memphis/Arkansa s WTNAKn-N 33 37 88 94
Miss/Louisanna MSLA 29 33 87 93
Wisconsin WIn-N 42.5 46 87 91
Chicago CHGOn-N 40.2 42.8 86 90
Indianna INn-N 39 41 85 87
Michigan MIn-N 42 46 81.5 86.5
Ohio OHn-N 38 42 81 85
Kentucky KYn-N 36.8 39.2 82 88
Knoxville ETN 35 37 82 86
Nashville NASHn-N 35 37 86 89
Alabama ALAn-N 31 35 85 89
Ontario ONn-N 42.5 49.5 75.5 82.5
Pittsburg WPAn-N 38.8 42.2 78 82
Virginia VAn-N 36.5 38.5 75 82.5
North Carolina NCn-N 35 37 74 82.5
Georgia GAn-N 33 35 82 86
South Carolina SCn-N 31 35.5 78 83.5
N. Florida NFLn-N 29 31 80 88
Central Florida CFLn-N 27.2 29 80 84
S. Florida SFLn-N 24 27.2 79 83
Baltimore/WashDC MDCn-N 38 40 75 78
NYC/NJ NYCNJn-N 39.5 42.5 72 76
New England NENGn-N 41.5 46 68 73
Quebec QEn-N 45 50 70 76
NewBruns/NovaSco NBNSn-N 43 50 60 68
de WB4APR@amsat.org, Bob
----------------------------------------------------------------------
Subject: Re: APRS Regions
From: Wes Johnston <wes@johnston.net>
Date: 13 Oct 2003 16:40:49 -0400
X-Message-Number: 3
On Mon, 2003-10-13 at 14:38, Bob Bruninga wrote:
>APRS Region LANn-N LATITUDE LONGITUDE
>----------------- -------- ---------- ------------
>Oregon/Washington ORWAn-N 42 52 118 126
>NOCAL NOCALn-N 39.5 42 118 126
I thought NOCAL was at lat/long 0/0 ? I seem to see alot of NOCALLs
there.... or is that n0call ? <ducking>
Wes
----------------------------------------------------------------------
Subject: RE: TExt messaging to Sprint Phones
From: "Ken Brown" <W2KB@comcast.net>
Date: Mon, 13 Oct 2003 20:05:12 -0400
X-Message-Number: 4
My AT&T service also includes free receiving of short ( APRS size <g> )
text messages. One simply addresses an ordinary email to the phone
number at mobile.att.net e.g., 9085551212@mobile.att.net and then type in
the text and send. So for APRS one could do likewise using the Sproul
server. Perhaps there is a similar addressing scheme to AT&T's for the
Virgin phone?
---Ken
----------------------------------------------------------------------
Subject: RE: TExt messaging to Sprint Phones
From: "David Thege" <dthege@conpoint.com>
Date: Mon, 13 Oct 2003 21:10:19 -0500
X-Message-Number: 5
Alltel gives you a regular e-mail address when you sign up for their "web
un-wired" service. I get a regular in-box fro e-mail on my phone.
Dave N0XBN
----------------------------------------------------------------------
Subject: RE: TExt messaging to Sprint Phones
From: "Gregg G. Wonderly" <gregg@skymaster.cytetech.com>
Date: Mon, 13 Oct 2003 22:45:12 -0500
X-Message-Number: 6
The root term for this service is Short Message Service or SMS. All phones
with text messaging understand SMS between phones where you just designate
a phone number to send the message to. Each carrier, on the other hand,
also has an email domain that can be used to send email from a non SMS
device to an SMS device. The primary issue is that this service, in
general, doesn't mix with the phone software programming... But, the Java
programmable phones can, in general, just connect directly to the internet
and go to an APRS-IS server. I did this on my nextel phone, a Motorola
I-85s. It worked just fine.
One of the main issues with my phone, and many others, running java, is
that you run an application that is exclusive to the use of the phone. If
you get a call, the java application stops. If you want to lookup a
number, you exit the application, and go to your directory.
The vendors have still not figured out that they need a completely
multitasking OS design with java at the core so that they could more
trivially allow anything you wanted to run in the background, to stay
running. There is, an example of a 100% java core phone built by the folks
at aJile, using there aJ-100 java byte code executing processor. At
100mhz, it executes java as fast as a 1-GHz pc running an OS such as
windows/linux with the same Java app on it.
The aJ-100 an context switch between threads at ~700ns (yes, nanoseconds).
There is a Mars rover design with this processor on it competing to fly on
a 2006 (I think, might be 2009) mission.
Send email to the phone vendors and tell them what you want a phone to be
able to do. Even if you don't think you need Java. Don't tell them you
want Java, tell them what you want to be able to do at the same time,
separately or in concert with some other application etc.
They can only go as fast as we tell them to!
>My AT&T service also includes free receiving of short ( APRS size <g> )
>text messages. One simply addresses an ordinary email to the phone
>number at mobile.att.net e.g., 9085551212@mobile.att.net and then type in
>the text and send. So for APRS one could do likewise using the Sproul
>server. Perhaps there is a similar addressing scheme to AT&T's for the
>Virgin phone?
-----
gregg@cytetech.com (Cyte Technologies Inc)
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
