[aprssig] The Current Meaning of WIDEn-N

[Charles Bland]

Wow Steve..... good stuff.

Chuck


On Mon, May 19, 2014 at 7:10 AM, Stephen H. Smith <wa8lmf2 at aol.com> wrote:

> On 5/18/2014 7:51 PM, Kenneth Finnegan wrote:
>
>> Gentlemen,
>>
>>
>> What is the CURRENT meaning of the first n in WIDEn-N?
>>
>>
> Originally, the TOTAL number of digipeater hops requested, assuming a
> single WIDEn-N clause in the path setting.
>
> Today the main reason for retaining the N-n structure of the clauses
> (instead of something simpler like just "WIDE-n") is that the firmware of
> thousands of existing TNCs expect it, and won't function correctly
>  (especially for duplicate supression) if the virtual "callsign" is not
> structured as WIDEn-N.
>
> Today, effectively the first "n" of WIDEn-N now indicates whether or not a
> home fill-in digi can potentially be used for the first relay hop of a
> multi-hop path.
>
> (Note that I spell "wide" in lower-case when describing digipeater types
> (true wide vs low-level home fill-in) to distinguish from the path element
> "WIDE".)
>
>
> If the first "n" is a "1", then *EITHER* a home fill-in digi --OR-- a
> high-level true wide can handle the hop.
>
> If the first "n" is other than "1", then ONLY a true wide will respond to
> and handle the hop.
>
>
>
> Today the *total* number of digipeater relay hops requested by the user is
> the sum of the first N of the first clause (normally "1") and the first N
> of the second clause (typically "2"), minus any "pre-decrementing"
> indicated by the second "N" of a clause initially being smaller than the
> first.  I.e.
>
> WIDE1-1 = One hop  (*ANY* digi will respond to this)
> WIDE2-1 = One hop  (Only true wides respond to this)
> WIDE1-1,WIDE2-1 = Two hops  (Today's recommended universal mobile setting)
> WIDE1-1,WIDE2-2 = Three hops
>
> Not normally used but for example...
> WIDE3-3 = Three hops
> WIDE1-1,WIDE3-3 = Four hops (don't do this!!!)
> WIDE1-1,WIDE3-1 = Two hops   (i.e. same as WIDE1-1,WIDE2-1)
> WIDE2-2,WIDE2-2,WIDE2-2 = SIX hops!!!  (Network abuse, but I've actually
> seen clueless users trying to do this!!)
> WIDE1-1,WIDE2-2,WIDE7-7 = TEN HOPS (I actually saw this once - I think
> they were trying to reach Jupiter purely on RF....)
>
> WIDE2-1,WIDE1-1 = Two hops, but horrible since each mountain top that
> hears the first hop, can potentially trigger dozens or hundreds of home
> fill-ins in it's RF footprint "down below" on the second hop for absolutely
> no reason. (If the home fill-ins can hear the mountain top(s), so can every
> other user "down below" directly.)
>
> This is why WIDE1-1 is completely discouraged in the greater Los Angeles
> area. The basin is completely rimmed with mountain-top "super-wides" that
> can hear and digipeat everyone everywhere on a single hop, without the help
> of home stations. The recommended path is "WIDE2-2" only which the local
> digis completely consume in a single hop.  When you travel out of the
> greater LA area (i.e. over the Tejon or Cajon passes or beyond SBA on the
> 101), you "automagically" start getting two hops from mountain tops that
> process "WIDE2-2" normally; i.e. as two hops.
>
>
>
>
>  The solution was to dedicate the alias WIDE1-1 to replace RELAY, which
>> leaves us with the issue that there is no "proper" way to express a
>> single WIDE hop correctly.
>>
>
>
> Yes there is!
>
> Since home digis ONLY respond to WIDE1-1, but true wide-area ones respond
> to ANY WIDEn-N,   you can use a path of WIDE1-1,WIDE2-1  which will utilize
> ANY and all digipeaters, home or true wide, within earshot for the first
> hop, and then exclusively a wide one for the second hop.
>       --OR--
> You can can use a path of only "WIDE2-2" (two potential hops by true wides
> only) or "WIDE2-1" (a single hop by true wides only) to ensure that
> exclusively true high-level wide digis are used.
>
>
> This was solved by "pre-consuming" the
>
>> first hop in a two hop request and start packets with WIDE2-1. As far
>> as I can tell, this brings us to the present, where low level digis
>> respond to WIDE1-1 and high level routing paths start as either
>> WIDE2-1, WIDE2-2 or WIDE3-3.
>>
>
> Again, high-level digis (using current n-N decrementing firmware) respond
> to *ANY* values of WIDEn-N as long as the second digit is non-zero.
>
> It's not a matter of "high-level" vs "low-level" paths.   Digipeaters
> don't determine the path; they only respond to what the USER sets into
> their radio or TNC.
>
>
>
>
> > When I change my path to a single WIDE2-1 or WIDE1-1 (I don't know
> > which is correct), I can finally stay within my ALOHA circle but the
> > low level digis in places like San Luis Obispo county (tight hilly
> > areas with very deep valleys) consume my single hop and I'm never
> > repeated by the high level digis and heard beyond 3-5 miles.
>
> You are forgetting that you are hitting ALL digipeaters within earshot of
> your mobile SIMULTANEOUSLY and in parallel.   A home digi on the ground may
> be processing your WIDE1-1 hop,  but at the same time one or more
> mountain-top wides that also hear it at the same time are doing the same
> thing.   If the path is WIDE1-1,WIDE2-1, then a second ring of true wides
> on mountain tops hundreds of miles from the first true wide will process
> the second ("WIDE2-1") clause.
>
> If you use solely "WIDE1-1", then both the valley-floor fill-ins and the
> nearest mountaintop true wides will respond simultaneously.
>
> If instead, you use "WIDE2-1" alone, you will get a single hop from the
> nearest mountain top(s) with no response at all from the home fill-ins on
> the valley floor.
>
> [People seem to overlook (or not know) that hops in digipeater path
> settings are processed SEQUENTIALLY -- The first "clause" in the user path
> settings *MUST* be acted upon and fully "used up", before the second one
> will do anything.]
>
>
>
>
>
>> I found this very surprising, since that was not how I had originally
>> been explained the WIDEn-N concept several years ago by my Elmers.
>> They had explained it that WIDE1-N was requesting hops from "level 1"
>> or low level digis. WIDE2-N was then requesting "level 2" hops through
>> higher level digis, and so on.
>>
>
>
> NO....   Once again,  *ANY* digi will respond to "WIDE1-1", smart or not
> about decrementing n-N.    Only high-level true-wide digis respond to any
> other values of "WIDEn-N".
>
>
>
>> What bothers me is that using the first number as a "level" of the
>> alias makes more sense to me than as the originating number of hops,
>> since we have also deprecated TRACE at some point in the last nine
>> years, so the need for knowing how far a packet has already gone can
>> now be met by the fact that every well behaving digi should trace on
>> every packet (I think?). The "originally requested hop count" value is
>> redundant, and meaningless since we're promoting originating paths
>> like "WIDE1-1,WIDE2-1."
>>
>>
>
>> Even if the low level digis only responded to WIDE1-1 (a behavior
>> which I don't see),
>>
>
> If low-level (commonly referred to as "home fill-ins")digis are *NOT*
> responding to WIDE1-1 (and *EXCLUSIVELY* WIDE1-1) then they are
> misconfigured plain and simple!!
>
>
>  this leaves me with the dilemma of either
>> requesting WIDE1-1 and having my hops consumed by low-level digis,
>>
>
> Again wrong.    WIDE1-1 will be acted upon and digipeated by *ANY* digi
> within earshot, home-fill-in or true high-level wide. In the SLO area, you
> are likely to be firing off both local on-the-ground home fill-ins AND
> Tassajera Peak at the same time.  However, you may be unaware that
> Tassajera was triggered, since, when your radio unkeys, the receiver is
> captured by the much nearer (and presumably stronger) local fill-in keying
> up simultaneously with Tassajera.
>
>
>  WIDE2-1 and never get digipeated by low digis
>>
>
> That's the intent -- that a path clause of the "WIDE2-n" type or higher
> should NEVER be processed by a low-level home fill-in.
>
>
> so 80-90% of my traffic
>
>> is lost in valleys, or WIDE1-1,WIDE2-1 and intermittently show up 200
>> miles away.
>>
>
> This is not a function of WIDE1-1 vs WIDE2-n.  It's a function of the true
> wides in California being what I call "super-wides", by being located on
> mountain tops THOUSANDS of feet above the user base, rather on towers a few
> HUNDRED feet above ground level (as they are in most of the rest of the
> country).
>
> [From an RF coverage engineering standpoint, California is almost unique
> in having 4,000, 5,000, even 8-10,000 foot mountain tops directly
> overlooking heavily populated major urban areas, yielding minimum-loss
> line-of-sight radio horizons of a hundred miles or more.
>
> Of course, no radio user (with the exception of cellular networks)is going
> to settle for a mere 100-foot tower when 5,000-foot "towers" are so nearby!
> This is a chronic problem with RF spectrum management in California.  The
> FCC rules and formulas on co-channel and adjacent channel separation,
> protection ratios, etc were developed from empirical VHF and UHF
> measurements taken in the 1930s and early 1940s on the east coast.  They
> have NEVER taken into account the unique problems of major metro areas
> rimmed with multi-thousand foot "towers" as we do here on the west coast.
> Not to mention the low-loss long-range tropospheric ducting that
> California's famous (or infamous) temperature inversions cause.]
>
>
>
>
>> Furthermore, analysis of bulk APRS traffic from APRS-IS is showing
>> 850ppm of packets being Igated with paths containing hops such as
>> WIDE1-2 or WIDE2-3, which are complete non-sense according to any of
>> the official meanings for WIDEn-N.
>>
>
> They ARE complete nonsense and indicate confused, ignorant or clueless
> users......
>
>
>
>> Have I missed one of the new "new" paradigms with respect to WIDEn-N,
>> or am I seeing evidence of confusion on the part of users?
>>
>>
> There is only ONE "New paradigm":  IT's the "double" WIDEn-N path of
> "WIDE1-1,WIDEn-N".
>
> By thw way, it's not so new anymore, since it has been in widespread use
> for over a decade and a half now.
>
> For mobiles:   WIDE1-1,WIDE2-1  or for extremely remote areas
> WIDE1-1,WIDE2-2 .
>
> For fixed stations (that presumably have better-situated antennas than
> mobiles: "WIDE2-1" .
>
>
> ___________________________________________________________________
>
> I conceived the "double WIDEn-N" scheme over a decade and a half ago,
> during discussions on this mailing list about channel congestion due to
> unnecessary duplicate digipeats, to:
>
> a) work around the crippling limitations of duplicate-suppression firmware
> of Kantronics TNCs widely used as stand-alone digipeaters.
>
> b) Allow older TNCs without the APRS-aware WIDEn-N decrementing firmware
> to continue to be used by home stations as cheap  fill-in  first-hop  digis.
>
> The closest thing to an official history and "primary source" that you
> will find for these issues is the page on my website at:
>
> "APRS 101"  Explanation of APRS Path Selection & Digipeating
>   <http://wa8lmf.net/DigiPaths>
>
>
> ____________________________________________________________________
>
>
> --
>
> Stephen H. Smith    wa8lmf (at) aol.com
> Skype:        WA8LMF
> EchoLink:  Node #  14400  [Think bottom of the 2-meter band]
> Home Page:          http://wa8lmf.net
>
>
>  Long-Range APRS on 30 Meters HF
>     http://wa8lmf.net/aprs/HF_APRS_Notes.htm
>
> High Performance Sound Systems for Soundcard Apps
>    http://wa8lmf.net/ham/imic.htm
>    http://wa8lmf.net/ham/uca202.htm
>
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> http://www.tapr.org/mailman/listinfo/aprssig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20140519/a171a4d9/attachment.html>