[aprssig] The New N-N paradigm CAN WORK

[Wes Johnston]

Bob, I'm starting to get confused... these things happen as threads evolve and
morph...

_IF_  I understand what you said yesterday about making wide2-2 work... we'll
take MYA, which can contain 4 aliases, and make MYA RELAY,wide2-2,wide2-1,wide
be the setting.  UIFLOOD and UITRACE would be available for LANn-n and LINKn-n.
 Ok.  Clunky, but OK.

LANn-n and LINKn-n will take a lot of coordinating... and we'll have to make
sure there are overlap areas.  As an example, Augusta GA and Aiken SC make up
an metro area where people live in one state and work in another.  The area is
locally known as the CSRA (central savannah river area), so in that area, some
digi's (heh heh) will respond to GAn-n and CSRAn-n, while the digi(s) in SC
will respond to SCn-n and CSRAn-n.  Locals will simply use CSRA2-2, or simply
wide,wide in their paths.

But now you are saying that the idea of firewalling packets based on distance is
a bad idea.  (again, _if_ I'm understanding your correctly).  I don't see how
limiting the "range" of a digipeater in software will restrict (in an
undesirable way) or cause confusion.  As a for-instance... if I were to program
my local digipeater to not digipeat any packets that started more than 120 miles
away that would do exactly what I'm looking for.... (assuming my digi's aloha
circle was 120 miles).   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.

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.
>