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

Mon Feb 7 08:47:02 EST 2005

>>> Wes Johnston <aprs at kd4rdb.com> 2/6/05 3:06:58 PM >>>
>You are correct in that _if_ every digi used these same 
>filters (44,55,66,77) then we'd have a decent fix... but...
>Now on the other hand, let's consider ...supporting WIDE2-2 
>universally...  By placing WIDE2-2 and WIDE2-1 and WIDE3-1
>specific callsigns in the UIDIGI list and removing WIDEn-N

Actually, this will work, and thanks for pointing it out!
In fact it is a great cold turkey way of cutting out the DX QRM 
instantly untill all users get the message that nothing above 
WIDE2-2 is "guaranteed everywhere but that larger N's can 
be used in areas that can afford it...

>This makes it an OPT-IN system, the digi owners would 
>choose the WIDE packet which were not harmful - and 
>there's a lot fewer of them...

Great thinking!  Thanks
I'll weave that back into the web pages...

Bob, WB4APR--

Quoting Robert Bruninga <bruninga at usna.edu>:

> Wes,
> What you are missing is that we want ALL digipeaters to
> capture and stop at least WIDE5-5, 6-6, 7-7, and then
> there is no where that the packets can get into the system,
> therefore you wont get any 7-3's into your area either.
> Its a big plan.  But each digi that switches over, helps out
> ALL digis around it...  And eventually the network is better.
>
> Bob
>
> >>> Wes Johnston <aprs at kd4rdb.com> 2/6/05 8:28:10 AM >>>
> 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
> --
>
>
>
> Quoting Robert Bruninga <bruninga at usna.edu>:
>
> > After a lot of debate over the last 2 months we have again
> > modified the plan for the New n-N Paradigm to an even better
> > and simpler design.  See the web page:
> >
> > http://web.usna.navy.mil/~bruninga/aprs/fix14439.html 
> >
> > Summary:
> >
> > WIDEn-N    works everywhere,  but large N's are traped
> >                    depending on the area.
> > WIDE2-2     is guaranteed to work everywhere
> > SSn-N         is also supported for area use
> > ##LNKn-N  interstate idea is abandoned
> >
> > Secondary effects:
> >
> > TRACE and TRACEn-N are not supported
> > WIDEn-N replaces it and is Traceable everywhere
> > RELAY,WIDE and WIDE,WIDE are no longer desired
> > WIDE may eventually be dropped if this all works.
> >
> > All digis will include a list of what they support
> > in a consistent manner in the Position Text that
> > will show up well on mobiles.
> >
> > This plan even works in the highest density system
> > in the USA in the Los Angeles Basin and a test of it
> > was initiated there last week.
> >
> > I have not completely re-editied all of my old WEB
> > pages to reflect all thse changes, so if you find
> > conflicts, then point me to them so I can fix them.  But
> > in general, the above plan is what is currently on the
> > table.
> >
> > Thanks
> > Bob, Wb4APR
> >
> > _______________________________________________
> > aprssig mailing list
> > aprssig at lists.tapr.org 
> > https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig 
> >
>
>