[aprssig] New WIDEn-N Paradigm (MAJOR MOD)

[Robert Bruninga]

Yes, because I too realize that some digis will never change
is why I realized that the Interstate concept is a dead-end
Its useless without a coordinate length of digis.  Also
when the first Paradigm came out, we didnt realize we 
could trap Large N's in existing TNC's.

Once we realize that ANY TNC out there now can help
TRAP large values of N, then WIDEn-N trapped down
in each area to what the network can handle is the smartest
approach.    It will work.  AND we can keep the SSn-N
system too as a way to work special needs.  Bob

>>> "Rich Mazzeo" <forummail at richmazz.com> 2/6/05 11:44:42 AM >>>

    I agree.  I was the first person in the area to get some of the
digis
running under the original new paradigm, but turning WIDEn-n back on
is
going to put things right back where we started.  I'm sure in LA this
works
fine, but in PA/NJ about only about 20% of the digi owners I've
contacted
even respond to emails and APRS messages, let alone change anything. 
There
needs to be a plan similar to the original new paradigm (Jan 11th) that
at
least tries to make up for both the users AND the digi owners lack of
education about the system.  At this point I'm fairly certain that all
of
the digis in NJ will be running RELAY,WIDE,TRACE,WIDEn-n,TRACEn-n until
the
transmitter dies or the end of the world, whichever comes first.  That
means
if theres a WIDE6-2 that came in from somewhere, it's going to bounce
around
at least twice in NJ. (or worse, digipeat once, hop over the wall of
new
paradigm digis, and digipeat again in PA.)

--
Rich
N3XKU

----- Original Message ----- 
From: "Wes Johnston" <aprs at kd4rdb.com>
To: "TAPR APRS Mailing List" <aprssig at lists.tapr.org>; "Robert
Bruninga"
<bruninga at usna.edu>
Cc: <aprssig at lists.tapr.org>
Sent: Sunday, February 06, 2005 8:28 AM
Subject: Re: [aprssig] New WIDEn-N Paradigm (MAJOR MOD)


> Bob...
>
> I know your recommendations are always grounded in pracitcality. 
But
until the
> TNC manu's come out with firmware that lets us limit UIFLOOD or
UITRACE
hop
> count (ie only digipeat UIFLOOD < 2-2), this solution is hokey at
best.
>
> The 3rd recommendation below defies belief... (the others too, but
I'm
going to
> pick on number 3)
>
> 1- RELAY, WIDE5-5, WIDE6-6, WIDE7-7 in wilderness areas
> 2- RELAY, WIDE4-4, WIDE5-5, WIDE6-6 in rural areas more than 3 hops
from
Metro
> Areas
> 3- RELAY, WIDE3-3, WIDE4-4, WIDE5-5 in populated areas where even 3-3
is
too
> much
> 4- RELAY, WIDE2-2, WIDE2-1, WIDE3-3 with UIFLOOD and UITRACE OFF in
Very
High
> Density local area
>
> I understand that UIDIGI settings take precedence over UIFLOOD
settings.
So you
> can put a callsign in there with the SSID such as WIDE5-5... and when
a
WIDE5-5
> is heard he'd be digipeated using the UIDIGI setting and get one hop
and
no
> more.  But this still does nothing to stop the WIDE5-4 that my
neighbor's
digi
> just repeated.  Or the WIDE7-3 that my neighbor just digipeated that
originated
> 350 miles away.  I still end up with my local lan flooded with the
lids
from
> >200 miles away!  In order for this plan to work, every digi has to
catch
the
> WIDE7-7 or WIDE5-5 on the first hop.  And if the first digi to hear
WIDE7-7
> doesn't "gobble it up" with a digipeat under the UIDIGI rules (ie
doesn't
> decrement N and does set the HID flag), then that packet becomes
WIDE7-6
which
> I can't filter out.  There are too many permutations - we're limited
to
FOUR in
> the UIDIGI setting.
>
> The whole point for me to switching away from WIDEn-n was to segment
the
network
> becuase we _didn't_ have a way to filter packets based on the value
of
"n".  I
> realize that the SSn-n is still recommended, but I just can't see
supporting
> WIDEn-n anymore.  My network is working better than ever since the
switch
to
> SCn-n here.
>
> If we start digipeating WIDEn-n here, even with the suggested
settings,
we'll
> end up seeing as much traffic as we used to as the WIDE7-7's and
WIDE5-5's
come
> rolling in at various stages of 7-6,7-5,7-4,7-3,7-2 or
5-4,5-3,5-2,5-1.  I
never
> saw any WIDE7-7's locally.  I never saw any WIDE5-5's locally... they
were
all
> WIDE7-1 or 7-3... how would I stop them?  Ideally, the digipeaters in
VA
would
> catch these packets under the UIDIGI setting, but practically
speaking,
they
> will not have setup their digipeaters to catch them, and will allow
these
> network cluttering packets to propagate outward as WIDEn-n's.
>
> FWIW, the local digi for me is KC4PL and he runs javaaprs which
supports
count
> limits. It counts all hops in a packet (ie RELAY,WIDE counts as 2
hops,
> RELAY,WIDE5-5 counts as 6 hops) and will not digipeat any packet with
>x
> hops(here, x is set for 3 hops).  They don't even get one hop....
They do
get
> IGATED, but do not propagate on RF.  So a trucker passing thru
running
WIDE7-7
> gets to the internet as he obviously is trying to do, but does not
damage
our
> RF network.
>
> I do really like the idea of giving the WIDE7-7's one hop... so they
emirge from
> the digi as WIDE7-7*.  This is so much better than budlisting the
guy
because
> when he isn't digipeated, he'll get angry and up his RF power and get
very
> creative with his paths.
>
> Wes
> --


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