| |
ZL3AI > APRDIG 24.09.03 10:37l 321 Lines 15442 Bytes #999 (0) @ WW
BID : 1969-ZL3AI
Read: GUEST
Subj: TAPR Digest, Sep 21, 1/2
Path: DB0FHN<DB0RGB<OK0PPL<DB0RES<ON0AR<VK6HGR<ZL2BAU<ZL3VML
Sent: 030923/1338Z @:ZL3VML.#80.NZL.OC #:8898 [Chch-NZ] FBB7.00i $:1969-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
TAPR APRS Special Interest Group Digest for Sunday, September 21, 2003.
1. Re: Path limiting by digis
2. Re: Path limiting by digis
3. Re: Path limiting by digis
4. Take Control of your DIGI
5. APRS at DCC
6. Re: Path limiting by digis
7. Re: Path limiting by digis
8. RE: APRS at DCC
9. RE: Take Control of your DIGI
----------------------------------------------------------------------
Subject: Re: Path limiting by digis
From: Tim Schall <grover@fortgirlfriend.com>
Date: Sat, 20 Sep 2003 22:27:41 -0700
X-Message-Number: 1
Destination digipeating is another way to do it. Digi_Ned, for instance, can
be programmed to act on the destination of a packet. A packet sent from my
Xastir v1.2.1 station would normally be something like 'KA7PBi -> APX121 via
RELAY,WIDE3-3' and subject to the normal digipeater rules. A packet send
like 'KA7PBI -> EMGNCY via RELAY,WIDE7-7' could snake its way through the
digi unmolested. I don't do this at SEA currently but I could.
Currently SEA trims the path of all packets it hears to be wide3-3 compliant.
This will, most likely, change to wide2-2 on or before next tuesday. At any
rate packets that are at wide3-3 or less are left unmolested. A packet
bigger than that will get trimmed at the appropriate number of hops.
For instance a packet that arrives at SEA like this, 'KA7PBI -> APX121 via
RELAY*,WIDE7-7' has already been through a relay system of some sort and has
requested 7 hops and none are used. That packet will leave SEA as 'KA7PBI ->
APX121,RELAY*,WAS7-7*,SEA*,WIDE3-2' This shows what the packet was
(WIDE7-7), who trimmed it (In case there's an issue of some sort that needs
addressing, so far there hasn't been.), and what it left as. If it had
arrived as WIDE7-6 it would have left WIDE3-1, etc.... If it arrives as
WIDE7-2, for instance, it would not be digi'd by SEA at all as there are
already five hops gone and I'm only allowing three hops.
As far as a UHF frequency goes, great idea! I'm in the process of adding a
UHF radio to my digi system. That side will allow packets to run around as
they see fit. It will also grab any packets it hears 'first' on either port
and route them to the other. In this case a packet arriving on UHF as
WIDE7-7 would leave on UHF as WIDE7-6 and on VHF as WIDE3-2.
If you're still reading and all of this makes sense, you're light years ahead
of a lot of people. I'd be more than happy to answer any questions that
anyone might have.
On Saturday 20 September 2003 18:12, Robbie wrote:
>I personally think this isn't the approach digi operators should be
>taking..
>
>The reason I do, is thinking the next step will be limiting the beacon
>rates by digipeater sysops for what ever reason they feel is appropriate.
>
>Now, when a situation arises where the rates need increased for some
>event, (emrgency), how could this restriction be lifted?
>
>I guess the special event, (emergency), could change frequency
----------------------------------------------------------------------
Subject: Re: Path limiting by digis
From: "Dick Stanich" <dick@kb7zva.com>
Date: Sun, 21 Sep 2003 6:54:11
X-Message-Number: 2
Tim,
Has anyone in your group thought about running a probe to analyze traffic
patterns to determine load conditions? It may be something as simple as
pulling the plug on a few digipeaters. I noticed about 10 digis of all
types within a circle of 25 miles. A lot more within 50 miles. Probably a
few more home RELAY stations adding to the load that we don't see. I don't
see how reducing packet paths will make much difference at one digi unless
all digi owners agree to do what you are doing. Does that sound reasonable?
Frankly, if someone told me that my paths were being altered, I'd be upset,
and ask questions about the architectural network design and why it is
defective.
Dick, KB7ZVA
APRSWest
----------------------------------------------------------------------
Subject: Re: Path limiting by digis
From: "Germino" <mgermino@sbcglobal.net>
Date: Sun, 21 Sep 2003 06:47:37 -0700
X-Message-Number: 3
For instance a packet that arrives at SEA like this, 'KA7PBI -> APX121 via
RELAY*,WIDE7-7' has already been through a relay system of some sort and has
requested 7 hops and none are used. That packet will leave SEA as
'KA7PBI ->
APX121,RELAY*,WAS7-7*,SEA*,WIDE3-2' This shows what the packet was
(WIDE7-7), who trimmed it (In case there's an issue of some sort that needs
addressing, so far there hasn't been.), and what it left as. If it had
arrived as WIDE7-6 it would have left WIDE3-1, etc.... If it arrives as
WIDE7-2, for instance, it would not be digi'd by SEA at all as there are
already five hops gone and I'm only allowing three hops.
----------------------------------------------------------------------------
Tim: When you change the Path, does the Digis that already sent it to you
still recognize the packet as one they have already repeated and not send it
again?
Mike
AD6AA
----------------------------------------------------------------------
Subject: Take Control of your DIGI
From: Bob Bruninga <bruninga@usna.edu>
Date: Sun, 21 Sep 2003 12:19:42 -0400 (EDT)
X-Message-Number: 4
Please, Everyone, save this proposal and come back and read it when you
have time to digest it. Keep an open mind.
*** Take Control of your Network: 144.39
* PROPOSAL: If your local APRS LAN is overloaded, *
* turn off WIDEn-N on that digi. *
There is nothing wrong with WIDEn-N, unless it is bringing in distant QRM
that is preventing your LAN from serving its primary local purpose. This
is a radical concept, but on close inspection, it has far, far more
positives than negatives.
I am impressed with many areas where the local sysops are trying their
best to build a network to serve their local needs. But in most cases the
problems are external and beyond their control. The big problem is very
long paths from out of area stations over which they have no control.
Sometimes the result is that they make local hacks to the fundamentals of
APRS which may do more damage than good to APRS overall.
In most of these areas, disabling WIDEn-N on the high density middle-of-
the-city digis will drastically cut distant QRM, while still permitting
the fundamental LOCAL area communications via RELAY,WIDE or WIDE,WIDE.
Notice that outlying areas may still use WIDEn-N for the vast stretches of
low density territority.
LOCAL CONTROL: Advantage #1 is that it gives sysops some control over
incoming DX packets without disabling local operation and without hacking
up the standardized fundamentals of APRS. (RELAY,WIDE or WIDE,WIDE should
work everywhere) (and for DX, WIDEn-N should still work)
UNIVERSAL: Advantage #2 is that it can be applied to ANY existing
digipeater. It doesnt require special ROMS or new hardware AND Draconian
filtering. Disabling WIDEn-N in selected digis is something that can be
done now, today, on ANY digi and it can even be done remotely! AND it
puts the solution to the LOCAL problem Local.
NO MORE FLOODING: There is a reason we named the WIDEn-N parameter in the
digis as UIFLOOD. The intent of a WIDEn-N packet is to FLOOD the network.
We can no longer afford that kind or RF polution.
SIMPLIFIES USER EDUCATION: We all know "user education" is the solution,
but our current situation is THE PROBLEM that makes user education
impossible! With every area of the country making thier own local HACKs
to APRS digis, there is no single recommendation that works everywhere.
And it is not a "soft" failure. It is a HARD failure. If I have a
tracker going via RELAY,WIDE and drive into an area that doesnt support
RELAY at all digis, then I am totally cut off.
The new user gets his info from the WEB. But the WEB is global, and so
the answer he gets could be from the other side of the world and be
totally wrong for his area. We MUST get back to the original, standard
and WORKABLE universal path for mobiles of RELAY,WIDE so that APRS works
as intended.
THREE TIER NETWORK: What this does in effect is give SYSOPS more
flexibiilty in the design of their network with now three compatible
options for digis:
WIDES: The local area network. The basis of APRS.
RELAYS: Fill in digis for blind spots
WIDEn-N: Long haul in sparse areas
The basis of the LOCAL area APRS is to serve the LOCAL need. These local
needs are fulfilled by WIDES -and- a local IGate. Then if there are some
local holes, then these shadow areas can be filled with a home station of
other RELAY digipeater. Then the long haul, low population areas can
remain as the RELAY/WIDE/WIDEn-N digipeaters.
HUB-and-SPOKE: I have no problem with WIDEn-N packets. In fact, this
concept will actually IMPROVE WIDEn-N:
1) it will remove the stigma that all long path N-N packets are bad.
2) it will limit the high density city packets (which now will not
use WIDEn-N) from flooding all surrounding area long-haul digis.
3) WIDEn-N digis will carry the WIDEn-N traffic to the EDGE of
the high density areas where it can find an IGate, but no further.
4) Removing WIDEn-N digipeating in the cental city, CUTS the long chains
that FLOOD everywhere.
5) this naturally restricts WIDEn-N into its most powerful advantage
of long linear propogation instead of FLOODING QRM...
BACKGROUND: I first proposed WIDEn-N in 1994 just after APRS began to
rise in popularity and we needed a propagation mechanism that would go
beyond 2 hops without folding back on itself. In 1996 or so, Paccomm came
out with its CALLSIGN SUBSTITUTION mechanism which we called TRACE. Then
in 1998 Kantronics finally produced the WIDEn-N algorithm in their
products and that gave us what we needed. But TWO things had changed:
1) APRS was growing so fast that it was saturated in most areas.
2) In 1997, Steve Dimse with the Sprouls introduced the APRS-IS
and IGate concept which gave global connectivity without the need
for flooding paths!
NOW: But we made NO changes in APRS to accomodate these factors and
continued to use the 1994 model! Now, as a result, we have APRS
disintegration as a national commmon system for tactical real-time local
data communications because it is drowing under the load of FLOODED
packets and worse, local areas are hacking up the original universal
concepts to try to stem the tide. The result is a loss of commonality and
sometimes damage to the network by these well-meaning, but incorrect local
hacks. And we CANNOT educate users, because we have no common rules!
The solution has been staring us in the face for years and I am amazed it
never occurred to me until this week. Turn off WIDEn-N FLOODING algorithm
in areas that need to limit Distant QRM. But protect it in areas where it
is needed by giving it a place (IGate) where it can dump the traffic on
the edge of town. Here is the plan:
NORTH AMERICAN APRS PLAN:
ALOHA CIRCLE: GIVEN that any RF lan of any geographical size operating at
1200 baud on 144.39 can support no more than about 50 typical APRS users
reliably, we must inculcate into the entire community the mind-set of
BIGGER KILLS and smaller WORKS. Everyone can easily determine the radius
of 50 or so users whether it is in the center of LA or the middle of
Nebraska. Once that is determined, than EACH individual can look at that
ALOHA circle and see the number of digipeaters that he must use in order
to serve HIS area.
THAT is the fundamental rule of APRS. Get your data to your 50 nearest
neighbors reliably. It wont work beyond that reliably, so dont try. I
like to see a few hundred users on my maps as does everyone else, but that
is just like "reading the mail", it is nice to have, but it should not
DRIVE the system and it cannot be done reliably. So concentrate on you
local 50. Then take what you get. To see more, put up UHF backbones or
go to the internet.
DUPES AREN'T BAD: Not ALL DUPES are bad. APRS needs some redundancy in
order to improve the probablity of receipt. No dupes means some packets
are probably being lost. 3 dupes is too many. So judge the network on
these realistic expectations. Silence is also good.
PATH INJECTION: For network management, we want all packets to self
identify their point of entry into the system. This means we want
all packets to begin with either RELAY or WIDE so that the first digi
can do callsign substitution and the packet will arrive everywhere
with that knowledge intact. (We can turn off TRACEn-N too!) We dont
need to Trace DX, where we dont want DX anyway)...
HOME RELAY's OFF: In 1994, the model was ALL aprs stations can serve
as a RELAY to help others. Now we must cut that back to make sure
that RELAY is OFF except where needed. And RELAY-only digis should
be doing callsign substitution. The rule is simple. If a mobile
in the vicinity of your home station can also hit the local digi,
then your RELAY should be off.
TWO-HOPS NORMAL: At DCC I asked this question: "If you were able to get
your local club or area to fully use APRS to support its activities and
events as you have always dreamed, could all of your objectives be met
MOST OF THE TIME with only the path of RELAY,WIDE or WIDE,WIDE?" The
answer was a resounding YES! This is not to say that you cannot use
WIDE,WIDE,WIDE in your area if it works..
MULTI-HOPS: Remember, at any time and even by remote-sysop control in
local WIDEn-N can be re-enabled to support any special needs. Also there
is NOTHING wrong with using WIDE,DIGI2,DIGI3,DIGI4 if you need a packet to
go beyond your LAN to DIGI4 area for example. This cuts APRS back to
LOCAL FLOODing (WIDE,WIDE) which is what it was designed to do, and
limiting DX FLOODING in busy areas. And it forces long hop needs into
linear paths that reduce QRM by the SQUARE of the number of hops.
ABUSE: Users can still try to use W,W,W,W,W,W, But the fix is easy,
because now whe have a universal rule that works everywhere. THus we
can now HARD filter only W,W,W,W,W,W type packts where the number of W's
is greater thatn X and X is now a LOCALLY determined limit. People who
still need long paths can use N-N paths becasue now we have designed our
system to handle them where they can be supported! Again, simple rules
that work EVERYWHERE, and simple fixes.
PROPOSAL: Again, I am not saying that -you- should turn off WIDEn-N in
-your- area. I am saying, however, that I can fully support this as a
LOCAL option at your discretion if you see the advantages to your area.
Conversly, I do expect and will continue to fight to restore full function
of RELAY,WIDE and WIDE,WIDE as the universal user paths in APRS for
mobiles and fixed stations. For review, how to use RELAY in APRS was
posted last week in this message:
Date: Wed, 17 Sep 2003
From: Bob Bruninga <bruninga@usna.edu>
Subject: [aprssig] How To use RELAY in APRS
BOTTOM LINE. We must get APRS back to some fundamental rules that work
locally everywhere so that:
1) We can publish those rules and educate users
2) APRS will work locally EVERYWHERE
3) SYSOPS will have a GUIDING objective to build to
4) We wont have local hacks that destroy the system
5) Long haul on RF will still work where needed
6) There are no draconian arbitrary rules being imposed locally
Think about it. "Take control of your digi" but make APRS work as it was
designed to.
de WB4APR, Bob
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
