<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    On 7/31/2010 12:45 PM, Matti Aarnio wrote:
    <blockquote cite="mid:20100731194539.GZ8563@mea-ext.zmailer.org"
      type="cite"><br>
      <pre wrap="">
What?  Is my APRS digipeater code wrong as it treats all  WIDEn-N
constructs the same and does dupe suppression on them all?
</pre>
    </blockquote>
    <br>
    Under the current "New Paradigm" standards, WIDE1-1   <u><b>IS</b></u>  
    treated differently from higher orders of N-N<br>
    <br>
    The whole WIDE1-1, WIDE2-1 construct was invented (it was my
    proposal years ago) to work around the "brain-dead" firmware
    limitations in Kantronics KPC3 TNCs. These TNCs are by far the most
    widely-used piece of hardware for stand-alone digis without a
    computer in the US.   [It's hard to beat the simplicity and low
    power consumption (15mA at 12 VDC) of a KPC3+radio digi at a remote
    site.]    The problem is that KPCs do dupe suppression on WIDEn-N
    paths but NOT on plain  RELAY or plain WIDE.     <br>
    <br>
    On the other hand, many home users operating first-tier low-level
    digipeaters (that in the past responded to "RELAY") use old TNCs
    (such as PK-232s, TAPR TNC-2s, MFJ 1270s, etc) that do not have
    APRS-aware firmware in them.  These older devices <u>CAN NOT</u>
    do   n-N   decremented SSIDs.     <br>
    <br>
    With rapid APRS growth in the early '2000s, the volume of
    unnecessary APRS traffic due to RELAY and plain WIDE not supporting
    dupe checking just exploded.    A lot of discussion followed on how
    one could migrate to an exclusively WIDEn-N network (with effective
    dupe control)  while still allowing  non-N-N-aware   home fill-in
    digis to remain part of the APRS infrastructure.  At the same time,
    one wanted to prevent home digis from acting on anything but the
    very first hop of a path.    <br>
    <br>
    The solution was the two-part  WIDE1-1,WIDE2-n path I proposed.   <br>
    <br>
    All home low-level digis set WIDE1-1 as a simple alias to be treated
    as an ordinary callsign of WIDE1 with an SSID of -1.   When a "dumb"
    home digi hears WIDE1-1 as the first hop in a path, it digipeats it
    just like any other fixed callsign, marks it as used, and passes the
    second WIDE2-1 or WIDE2-2 part onward to the next tier of "real" N-N
    digis.    (The home digis completely ignore WIDE2-anything or higher
    since only WIDE1-1 is set as an alias to digipeat on.)<br>
    <br>
    True high-level WIDEn-N will respond to any value of WIDEn.  If a
    high-level digi (that DOES have proper WIDEn-N support) happens to
    hear the initial transmission, it will process WIDE1-1 as a
    decremented n-N, mark it used up and hand the second half WIDE2-n to
    the next (high-level) digipeater(s).  <br>
    <br>
    <br>
    The difference when monitored off the air after the first hop is
    that a home fill-in digipeat of the first hop would yield<br>
    <br>
         WA8LMF to APRS via  WIDE1-1*,WIDE2-1<br>
    <br>
    while a first hop captured by a "real" decrementing WIDEn-N digi,
    would produce<br>
    <br>
         WA8LMF to APRS via WIDE1-0*,WIDE2-1   <br>
                  or possibly<br>
         WA8LMF to APRS via *WIDE1*,WIDE2-1<br>
    <br>
    if the monitoring TNC's firmware treats an SSID of "zero" as
    effectively no SSID at all for display purposes. <br>
    <br>
    <br>
    The low-level WIDE1-1 home digis far outnumber the WIDE2-n "true
    wides".   Beaconing WIDE1-1 as the first hop from aircraft (that
    have a range of hundreds of miles/km line-of-site) can potentially
    trigger hundreds of home WIDE1-1 digis simultaneously,  when then
    ALL retransmit to the nearest true WIDEn-N systems.  If the first
    hop from an airborne station is a WIDE2-n only (which the home digis
    just ignore) a few "true wides" rather than hundreds of home
    stations will be triggered.   <br>
    <br>
    <br>
    <br>
    Yes, the whole scheme is a kludge to work around the limitations of
    20-year-old "clunker" TNC hardware, but it does kinda' sorta'
    work.........<br>
    <br>
    <br>
    <hr size="2" width="100%"><br>
    --<br>
    <br>
    Stephen H. Smith    wa8lmf (at) aol.com <br>
    EchoLink Node:      WA8LMF  or 14400    [Think bottom of the 2M
    band]<br>
    Skype:        WA8LMF<br>
    Home Page:          <a class="moz-txt-link-freetext" href="http://wa8lmf.net">http://wa8lmf.net</a><br>
    <br>
    NEW!    *** HF APRS over PSK63 ***<br>
       <a class="moz-txt-link-freetext" href="http://wa8lmf.net/APRS_PSK63/index.htm">http://wa8lmf.net/APRS_PSK63/index.htm</a><br>
    <br>
    Universal HF/VHF/UHF Antenna Mounting System<br>
      <a class="moz-txt-link-freetext" href="http://wa8lmf.net/mobile/UniversalAntMountSystem.htm">http://wa8lmf.net/mobile/UniversalAntMountSystem.htm</a><br>
    <br>
    "APRS 101"  Explanation of APRS Path Selection & Digipeating <br>
      <a class="moz-txt-link-freetext" href="http://wa8lmf.net/DigiPaths">http://wa8lmf.net/DigiPaths</a> <br>
    <br>
    <br>
    <br>
  </body>
</html>