Order Tray | Contact Us | Home | SIG Lists

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

Wes Johnston aprs at kd4rdb.com
Sun Feb 6 13:28:10 UTC 2005


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
3- RELAY, WIDE3-3, WIDE4-4, WIDE5-5 in populated areas where even 3-3 is too
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.


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

More information about the aprssig mailing list