<div dir="ltr">Wow Steve..... good stuff.<br><br>Chuck<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, May 19, 2014 at 7:10 AM, Stephen H. Smith <span dir="ltr"><<a href="mailto:wa8lmf2@aol.com" target="_blank">wa8lmf2@aol.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 5/18/2014 7:51 PM, Kenneth Finnegan wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Gentlemen,<div class=""><br>
<br>
What is the CURRENT meaning of the first n in WIDEn-N?<br>
<br>
</div></blockquote>
<br>
Originally, the TOTAL number of digipeater hops requested, assuming a single WIDEn-N clause in the path setting.<br>
<br>
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.<br>
<br>
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.<br>
<br>
(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".)<br>
<br>
<br>
If the first "n" is a "1", then *EITHER* a home fill-in digi --OR-- a high-level true wide can handle the hop.<br>
<br>
If the first "n" is other than "1", then ONLY a true wide will respond to and handle the hop.<br>
<br>
<br>
<br>
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.<br>
<br>
WIDE1-1 = One hop (*ANY* digi will respond to this)<br>
WIDE2-1 = One hop (Only true wides respond to this)<br>
WIDE1-1,WIDE2-1 = Two hops (Today's recommended universal mobile setting)<br>
WIDE1-1,WIDE2-2 = Three hops<br>
<br>
Not normally used but for example...<br>
WIDE3-3 = Three hops<br>
WIDE1-1,WIDE3-3 = Four hops (don't do this!!!)<br>
WIDE1-1,WIDE3-1 = Two hops (i.e. same as WIDE1-1,WIDE2-1)<br>
WIDE2-2,WIDE2-2,WIDE2-2 = SIX hops!!! (Network abuse, but I've actually seen clueless users trying to do this!!)<br>
WIDE1-1,WIDE2-2,WIDE7-7 = TEN HOPS (I actually saw this once - I think they were trying to reach Jupiter purely on RF....)<br>
<br>
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.)<br>
<br>
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.<div class="">
<br>
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The solution was to dedicate the alias WIDE1-1 to replace RELAY, which<br>
leaves us with the issue that there is no "proper" way to express a<br>
single WIDE hop correctly.<br>
</blockquote>
<br>
<br></div>
Yes there is!<br>
<br>
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.<br>
--OR--<br>
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.<div class="">
<br>
<br>
This was solved by "pre-consuming" the<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
first hop in a two hop request and start packets with WIDE2-1. As far<br>
as I can tell, this brings us to the present, where low level digis<br>
respond to WIDE1-1 and high level routing paths start as either<br>
WIDE2-1, WIDE2-2 or WIDE3-3.<br>
</blockquote>
<br></div>
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.<br>
<br>
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.<div class=""><br>
<br>
<br>
<br>
> When I change my path to a single WIDE2-1 or WIDE1-1 (I don't know<br>
> which is correct), I can finally stay within my ALOHA circle but the<br>
> low level digis in places like San Luis Obispo county (tight hilly<br>
> areas with very deep valleys) consume my single hop and I'm never<br>
> repeated by the high level digis and heard beyond 3-5 miles.<br>
<br></div>
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.<br>
<br>
If you use solely "WIDE1-1", then both the valley-floor fill-ins and the nearest mountaintop true wides will respond simultaneously.<br>
<br>
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.<br>
<br>
[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.]<div class="">
<br>
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I found this very surprising, since that was not how I had originally<br>
been explained the WIDEn-N concept several years ago by my Elmers.<br>
They had explained it that WIDE1-N was requesting hops from "level 1"<br>
or low level digis. WIDE2-N was then requesting "level 2" hops through<br>
higher level digis, and so on.<br>
</blockquote>
<br>
<br></div>
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".<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
What bothers me is that using the first number as a "level" of the<br>
alias makes more sense to me than as the originating number of hops,<br>
since we have also deprecated TRACE at some point in the last nine<br>
years, so the need for knowing how far a packet has already gone can<br>
now be met by the fact that every well behaving digi should trace on<br>
every packet (I think?). The "originally requested hop count" value is<br>
redundant, and meaningless since we're promoting originating paths<br>
like "WIDE1-1,WIDE2-1."<br>
<br>
</blockquote>
<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><div class="">
Even if the low level digis only responded to WIDE1-1 (a behavior<br>
which I don't see),<br>
</div></blockquote>
<br>
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!!<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
this leaves me with the dilemma of either<br>
requesting WIDE1-1 and having my hops consumed by low-level digis,<br>
</blockquote>
<br></div>
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.<div class="">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
WIDE2-1 and never get digipeated by low digis<br>
</blockquote>
<br></div>
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.<div class=""><br>
<br>
so 80-90% of my traffic<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
is lost in valleys, or WIDE1-1,WIDE2-1 and intermittently show up 200<br>
miles away.<br>
</blockquote>
<br></div>
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).<br>
<br>
[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.<br>
<br>
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.]<div class="">
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Furthermore, analysis of bulk APRS traffic from APRS-IS is showing<br>
850ppm of packets being Igated with paths containing hops such as<br>
WIDE1-2 or WIDE2-3, which are complete non-sense according to any of<br>
the official meanings for WIDEn-N.<br>
</blockquote>
<br></div>
They ARE complete nonsense and indicate confused, ignorant or clueless users......<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Have I missed one of the new "new" paradigms with respect to WIDEn-N,<br>
or am I seeing evidence of confusion on the part of users?<br>
<br>
</blockquote>
<br></div>
There is only ONE "New paradigm": IT's the "double" WIDEn-N path of "WIDE1-1,WIDEn-N".<br>
<br>
By thw way, it's not so new anymore, since it has been in widespread use for over a decade and a half now.<br>
<br>
For mobiles: WIDE1-1,WIDE2-1 or for extremely remote areas WIDE1-1,WIDE2-2 .<br>
<br>
For fixed stations (that presumably have better-situated antennas than mobiles: "WIDE2-1" .<br>
<br>
<br>
______________________________<u></u>______________________________<u></u>_______<br>
<br>
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:<br>
<br>
a) work around the crippling limitations of duplicate-suppression firmware of Kantronics TNCs widely used as stand-alone digipeaters.<br>
<br>
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.<br>
<br>
The closest thing to an official history and "primary source" that you will find for these issues is the page on my website at:<br>
<br>
"APRS 101" Explanation of APRS Path Selection & Digipeating<br>
<<a href="http://wa8lmf.net/DigiPaths" target="_blank">http://wa8lmf.net/DigiPaths</a>><br>
<br>
<br>
______________________________<u></u>______________________________<u></u>________<br>
<br>
<br>
--<br>
<br>
Stephen H. Smith wa8lmf (at) <a href="http://aol.com" target="_blank">aol.com</a><br>
Skype: WA8LMF<br>
EchoLink: Node # 14400 [Think bottom of the 2-meter band]<br>
Home Page: <a href="http://wa8lmf.net" target="_blank">http://wa8lmf.net</a><br>
<br>
<br>
Long-Range APRS on 30 Meters HF<br>
<a href="http://wa8lmf.net/aprs/HF_APRS_Notes.htm" target="_blank">http://wa8lmf.net/aprs/HF_<u></u>APRS_Notes.htm</a><br>
<br>
High Performance Sound Systems for Soundcard Apps<br>
<a href="http://wa8lmf.net/ham/imic.htm" target="_blank">http://wa8lmf.net/ham/imic.htm</a><br>
<a href="http://wa8lmf.net/ham/uca202.htm" target="_blank">http://wa8lmf.net/ham/uca202.<u></u>htm</a><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
______________________________<u></u>_________________<br>
aprssig mailing list<br>
<a href="mailto:aprssig@tapr.org" target="_blank">aprssig@tapr.org</a><br>
<a href="http://www.tapr.org/mailman/listinfo/aprssig" target="_blank">http://www.tapr.org/mailman/<u></u>listinfo/aprssig</a><br>
</div></div></blockquote></div><br></div>