[aprssig] The Current Meaning of WIDEn-N

Mon May 19 10:10:03 EDT 2014

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