<div dir="ltr">I believe that the biggest problem with the current path system is education. As Jeff N5TEV points out, there are lots of online resources that provide information on paths. The problem is that they are poorly organized and poorly designed. <a href="http://www.aprs.org" target="_blank">www.aprs.org</a> ranks high in the Google index and no slight to Bob but it's a mess, having seen decades of append-only editing. There's no basic I'm-brand-new-to-APRS tutorial front and center on the site. Instead, you have a 1990's-WWW-style mass of links without any categorization and with little indication of what's important to the new user and what's not. The balloon page is a great example of this: <a href="http://www.aprs.org/balloons.html">http://www.aprs.org/balloons.html</a> It's 23 years of W3ADO launch information and when you finally scroll to the very bottom, you find the balloon-specific path and packet rate information that every new balloon flier needs.<div>
<br></div><div>The wiki is a great start but needs some work. There's a page with suggested path settings but no explanation of how a path works that answers basic new user questions like, "what does WIDE2-1 mean?" </div>
<div><br></div><div>I think this could all be fixed by giving the wiki some much-needed love and by promoting good newbie practices on <a href="http://www.aprs.org">www.aprs.org</a> by providing a prominent link (front and center) to a new user tutorial on the wiki.</div>
<div><br></div><div>Chris NW5W</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jul 13, 2014 at 9:20 AM, Jeff Dugas (Mobile) <span dir="ltr"><<a href="mailto:N5TEV@compuserve.com" target="_blank">N5TEV@compuserve.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I must agree with Bob.<br><br>The sender of the packet should control where it goes. There is already basic guidance out there, specifically on the APRS web site (<a href="http://www.aprs.org" target="_blank">http://www.aprs.org</a>).<br>
<br>Specific guidance on paths is provided ( <a href="http://www.aprs.org/fix14439.html" target="_blank">http://www.aprs.org/fix14439.html</a>) as well as for balloons/aircraft (<a href="http://www.aprs.org/balloon" target="_blank">http://www.aprs.org/balloon</a>).<br>
<br>Depending on the purpose of the communication, The sender may have a bona fide need for a specific path, or no path at all.<br><br>If I want to send a letter to Aunt Annie, I address it specifically to her. If I am a congressman who wants to send a something to everyone in my in my district, I address it accordingly. And any situation in between.<br>
<br>The aforementioned analogy is not perfect, but suffice it to say, when communicating, it is up to the sender to determine the proper audience.<br><br>Jeff<br>N5TEV<br><br>- - - - - - - - - - - - - - - - - - - - -<div class="HOEnZb">
<div class="h5"><br><br>Robert Bruninga <<a href="mailto:bruninga@usna.edu" target="_blank">bruninga@usna.edu</a>> wrote:<br><br><div>I'm sorry to have to offer this rebuttal. The problem with this scheme is that it assumes every packet is of equal value, and its goal is to maintain a constant level of loading on the network independent of any "value" to the users or the situation. This is an anathma of human communication and can be considered almost as a classic definition of maintaining noise level rather than information throughput...</div>
<div> </div>
<div>Only the sender of a packet knows its immediate value, and only the sender knows where he wants it to go. The digipeaters are stupid, or a better way to say it is that they should do what they are told by the sender.</div>
<div> </div>
<div>Bob, WB4APR<br><br></div>
<div class="gmail_quote">On Sun, Jul 13, 2014 at 7:53 AM, Mark Cheavens <span dir="ltr"><<a href="mailto:mcheavens@usa.net" target="_blank">mcheavens@usa.net</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote">With the most common thread on the APRS sig over the last few months being paths I thought it time to remind everyone of why we have the current problem and what we should work together to first come up with a needs list and to secondly work to solve the issue.<br>
<br>While I have brought this up on the list many years ago, there are many new users and it might be time for a reminder.<br><br>The current system (Digi backbone) was built with the currently available (and surplus) old TNC's. Many at the time were TNC-2's or clones, as well as the then "modern" KPC-3 and 3+'s.<br>
<br>The KPC-3+ have suffered from the delayed packet problem, and the TNC-2's have been implemented in many cases without UiDigi firmware.<br><br>As a result we have been fighting for years to try and educate end users (the best of which are on this list) of what their path should be in many different operating environments and parts of the country.<br>
<br>Solution:<br>Take "paths" and throw them out the window.<br>- (During the transition having a path will work with the "old" digi's)<br><br>The number of times a packet is digipeated is network specific based upon the current load of the network.<br>
<br>The Digipeater should decide whether to throw out the packet, delay it to see if it was heard by another digi, or digipeat it immediately.<br><br>The digipeater will have to know:<br>It's location<br>It's PHG (coverage area)<br>
How many hops it is to a reliable I-Gate<br>It's altitude (both average ground elevation for the area and antenna elevation above that terrain).<br>List of stations it has heard (MHeard)<br>- That list will also keep track of the packet location<br>
Current channel loading<br><br>We need the digi to decide!<br><br>Examples:<br>If a digi hears a packet from one mile away (It knows it's location and the location of the packet), and it has not heard a packet from this station in X minutes the packet should be repeated!<br>
(x is variable based upon the number of unique "direct" stations it has heard, and has the station moved more than Y distance).<br><br>- If the station did not move (horizontally or vertically), and a packet was heard from the same station 10 seconds prior should the packet be digipeated?<br>
- Normally most of us would say "no", but if the channel loading is zero, then why not! (Private or test network)<br><br>If a digi hears a packet from a station 100 miles away, should the packet be digipeated?<br>
- Was it heard directly?<br>- Was it digipeated by another digi?<br>- What is the channel loading?<br>- Is the station moving or fixed?<br>- How long has it been since THIS digi repeated the packet?<br><br>----------------------------<br>
With modern TNC's available there is no reason not to start working on a modern solution.<br>- Existing TNC's could be used if put into KISS mode and using small single board computers such as a Raspberry Pi.<br>
- An ideal solution would be a dedicated solution (Tracker3, TNC-X, etc)<br>
<br>The idea of this email was not to list "all" of the needs, but simply to point out that until (WE) begin to think of what is needed and begin to think of the algorithms needed, we will continue to have "path" problems.<br>
<br>Respectfully,<br>Mark Cheavens<br>KC5EVE<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>
</blockquote></div><br>
</div></div><br>_______________________________________________<br>
aprssig mailing list<br>
<a href="mailto:aprssig@tapr.org">aprssig@tapr.org</a><br>
<a href="http://www.tapr.org/mailman/listinfo/aprssig" target="_blank">http://www.tapr.org/mailman/listinfo/aprssig</a><br>
<br></blockquote></div><br></div>