[aprssig] The new N-N paradigm summary (fwd)

[Robert Bruninga]

>>> greg at clubnet.net 1/5/05 11:10:50 AM >>>
>  Also, if everyone suddenly got rid of WIDEn-N, what do 
>you think these DX digis would do to their paths?  
>Back to long WIDE paths, like was the case before?  

That is why this has to be a complete upheaval and it all goes
together.  We cannot peacemeal it...  ALl things must
be thought of as a whole new way of doing APRS.

To the user it is simply:

1) SSn-N will work in any state
2) RELAY and WIDE (2 hops MAX) will work anywhere
3) Long haul paths along major national arteries use ##LNKn-N
4) WIDEn-N will work in vast wilderness areas

And the guidance to stations is simple:

1) In most population areas keep your path to 2 hops
2) Use SS2-2 as the best path fixed or mobile.
3) If you have to wander anywhere across state lines or
    need flexibility, then use RELAY,WIDE
4) In WIDEn-N wilderness areas, WIDE3-3 is OK

Any other long paths in most high density areas are
inconsiderate and bad practice...

Wont this universal guidance work everywehre?
Then we hammer home the education factor, becuse
now we have one set of rules that works everywhre
and one set of rules as a standard to use for policing
the channel...

Bob

And with this, the packets get REALLY 
long and can chew up a lot of bandwidth.

>  If you really think it's necessary to leave a WIDEn-N digi or two 
> down low in the basin, that's fine, but RELAY should be supported for

> mobiles passing through.

As said above, the network of low-level home stations should provide 
the RELAY hop option.  If you monitor local traffic, you will see this

often works (granted, not always).

> I'll never forget when I first went mobile APRS back in 2000 and I 
> read on Bob's page that mobiles should be set to RELAY,WIDE.  I 
> wondered for days why I couldn't get any packets out, and I still get

> questions from new mobile operators.  There needs to be a
standardized 
> mobile path.

This was right during the massive transition to WIDEn-N.  The proposed

"standard path" was in a state of flux.  As WIDEn-N was taking hold, 
new proposed "standard paths" were being considered.   First WIDE2-2, 
then RELAY, WIDE2-2.  I know Bob always wanted RELAY, WIDE to work 
everywhere, but the shortcomings in the Kantronics dupe checking 
algorithm for UIDIGI callsign entries vs. UIFLOOD and UITRACE make the

use of paths such as RELAY, WIDE or RELAY,WIDE,WIDE with SoCal's 
digipeater system a disaster.  Reread the quote from Bob regarding dupe

possibilities without WIDEn-N (2b in my original message) or, if you 
have a KPC-3 Plus manual, look at pages 149 and 150 to get an idea of 
the difference in duplications that can be created between the two 
options.  Granted these are worst case situations and don't frequently

happen.  But believe me Phil, before WIDEn-N, we were getting many, 
many dupes that were really chewing up bandwidth.  If this dupe 
checking shortcoming was eliminated we would have a completely 
different situation.  Maybe version 9.0 fixes this, but the manual 
doesn't seem to indicate this.

> San Diego and Yuma are on the new system and things are working great

> so far.
>
> 73
> Phil - AD6NH
> http://www.aprsca.net 


_______________________________________________
aprssig mailing list
aprssig at lists.tapr.org 
https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig