[aprssig] The Current Meaning of WIDEn-N
Stephen H. Smith
wa8lmf2 at aol.com
Mon May 19 10:10:03 EDT 2014
On 5/18/2014 7:51 PM, Kenneth Finnegan wrote:
> 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
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.
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
> 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")
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
[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
[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
> 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
> 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
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:
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
Stephen H. Smith wa8lmf (at) aol.com
EchoLink: Node # 14400 [Think bottom of the 2-meter band]
Home Page: http://wa8lmf.net
Long-Range APRS on 30 Meters HF
High Performance Sound Systems for Soundcard Apps
More information about the aprssig