[aprssig] The New N-N paradigm CAN WORK

[Robert Bruninga]

>>> aprs at kd4rdb.com 10/28/04 10:26:09 AM >>>
>_IF_  I understand what you said ... about making wide2-2 work... 
>we'll take MYA, which can contain 4 aliases, and make 
>     MYA  be RELAY,WIDE,WIDE2-2,WIDE2-1,

In the KPC-3 that  command is UIDIGI.  But yes and no.
For areas that want to control WID7-7 out of area flooding
by replacing WIDEn-N with a LANn-N or a LINKn-N then
the Alias list should contain RELAY, WIDE, SS and WIDE2-2.
This way the universal mobile using a path of RELAY,WIDE2-2
would still get at least a 2 hop path in your area.  The WIDE2-2
would simply be another alias and the digi would callsign
substitute it...

>UIFLOOD and UITRACE would be available for LANn-n 
>and LINKn-n.

Yes...

>LANn-n and LINKn-n will take coordinating...[in] overlap 
>areas.  As an example, Augusta GA and Aiken SC make up
>a metro area ...known as CSRA, so...some GA digi's ... will 
>respond to GAn-n and CSRAn-n, while the SC [digis]
>will respond to SCn-n and CSRAn-n.  Locals will simply use 
>CSRA2-2, or simply wide,wide in their paths.

Or DIGI1,GAn-N to talk to GA or DIGI2,SCn-N to talk
into South Carolina.  We are long past the point where
one person should be flooding two states to talk to 
his one buddy in one of them.

>But now you are saying that the idea of firewalling packets 
>based on distance is a bad idea. 

You can never tell who's important commmunication may
at some time need a long path.  It must be there when
needed.  Everytime something is automatied (to me) it
is always the WRONG answer at the WRONG time...
and takes months or years to change...

>...  I don't see how limiting the "range" of a digipeater in 
>software will restrict (in an undesirable way) or cause confusion.

1) What digis?  90% of the digis are KPC-3's that
have NO WAY to add any software or intelligence
even if you could come up with an algorithm.  Yes
it is easy to say all kinds of things we COULD do,
but it just wont happen.  Dont waste your time trying
to dream one up.  It just wont happen...

Yes it can work where UIDIGI ROMS or DIGINED
or some of the other programmable digis are, but that
is a minority...

> if I were to program my local digi [to filter out anything 
>beyond] 120 miles..

Then I would hate to travel in your area if my mom lived
there and every year at XMAS you are denying me the
chance of letting her see me approach..

>  It would stop flooding my LOCAL network with packets
>that are here only because some egotistical operator 
>wanted to run wide7-7 400 miles away.

But it would be an arbitrary and capricious limit that would
prohibit ligitimate uses and needs for communications.

I wont comment on the remainder,  these are all  decent
ideas, but they just wont happen.  People rarely 
upgrade, and most wont take the trouble...  Bob

*------------------------------------------------
The problem is that we can't filter by distance in a KPC3... or can we?  John
Hansen's TNC-x is in dire need of a digipeater controller daughterboard.  There
is no reason that once that daughterboard is written, that a KPC3 couldn't be
put into kiss mode and use the same device.  The hamhud team has a board that
talks to a kpc3 and (will soon) talk in KISS mode, buffering 2k or so of
packets in RAM.  I can't remember the pic chip number, but it certainly doesn't
cost more that $10 each.  Add the required FRAM chip at another $8 (or so), anda
PCB, and we have the possibility for a controller that costs $30.  Another
option is the BasicATOM pro for $50, which could be built inside a db25 shell
and has 2k of RAM.

So you tell the digipeater operators that they can reclaim their local areas by
switchign their kpc3's to KISS mode and adding a controller that costs $30 to
$50.

Yes, someone has to write this software.  I may add it to my list of projects,
or someone might beat me to it.  This software would have to be able to decode
ALL aprs position formats (are there 4 or 5?).  And some packets (such as
messages) don't have a position attached, so we'll have to let them be
digipeated.  And we'll have to decode 3rd party packets too... but it's
do-able.

I just don't see the harm in filtering by distance - after all, APRS is supposed
to be a LOCAL thing, right?

Wes
Quoting Robert Bruninga <bruninga at usna.edu>:

> >If instead, you give each digi operator the capability to
> >define their own service area, and encourage them to
> >simply drop any packets originating outside that area,
> >you make obnoxious DXing on APRS impossible..
>
> Two comments:
>
> 1) t is my WORST NIGHTMARE!  That would killl APRS
> because it makes operation ambiguous, arbitrary, locally
> dependent, and impossible to use for emergent requirements.
> That is the disaster we have now with some areas disabling
> RELAY, others disabling WIDE, etc.    The only filtering
> I will support is one-on-one bud-listing of consistent
> individual abusers...
>
> 2) It is easy for you to say to just "drop" bad packets,
> but 90% of all digis are KPC-3's and there is no way to
> do that.  Your statement is like saying the way to make
> money is to buy low and sell high.  Easy to say, but
> can't happen for a dozen years until all KPC-3's are
> made obsolete.
>
> >the users can still use a 'mostly universal' RELAY, WIDE2-2
> >path, and we solve the problem without adversely imnpacting
> >anyone's daily operations.  Just a one-time investment of time,
> >and then only by the programmers and digi operators.
>
> Yes, I agree completely with the above paragraph because
> that is all a local DIGI owner has to do to:
> 1)  Change his WIDEn-N to a LOCALn-N or other LANn-N name.
> 2)  and consider the other options I outlined... if needed.
>


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