<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Consider the purpose of APRS,
      especially RF APRS and Digipeaters.  Which of the following is
      it?  a) to get packets to an IGate or b) to get packets propagated
      for local RF reception?  IMHO, the purpose of a digipeater is
      both, but a) shouldn't trump b).<br>
      <br>
      I have a personal issue with the concept of a digipeater not
      repeating a packet just because it heard some other digipeater
      repeating it.  Unless, of course, the coverage of the viscous
      digipeater is fully covered by the other digipeater.  Otherwise,
      the viscous suppression may be depriving RF users that are covered
      by that digi from hearing packets just because another digipeater
      acted on them, possibly on the far side of the viscous digipeater.<br>
      <br>
      As with all networks, you need to consider the topology and
      compare coverage areas before deciding not to act on any given
      packet under whatever conditions are being considered.<br>
      <br>
      But, IMNSHO, the presence of a packet on the APRS-IS is not just
      cause for not repeating it on the local RF if the digipeater
      making that decision provides some unique patch of coverage area.<br>
      <br>
      Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and
      Win32<br>
      <br>
      On 3/19/2013 7:22 PM, Samúel Úlfr Þór Guðjónsson wrote:<br>
    </div>
    <blockquote
cite="mid:CAKkFkxGuXx4dCGeZ=RhLDeafrDhYm2hT=Kda4GmeYpSCpTnsZg@mail.gmail.com"
      type="cite">Oh yeah, and actually to be more accurate, it'd have
      to check APRS IS and see if the packet *really* went from RF to
      IS.<br>
      Maybe that's an idea? But that would require that digipeater to
      have IGate functionality, or at least be able to listen to APRS
      IS. That could perhaps, improve the QRM even more? And it wouldn't
      stop NOGATE or RFONLY from digipeating again...<br>
      <br>
      I do however think that this problem can be improved, so to speak,
      with tactical positions of digipeaters. So that every fillin would
      be able to hear at least one high level digipeater (actually, why
      set up a fillin if you can't reach a high level digipeater?) but
      wont be able to throw the packet to too many high levels (decrease
      TX power perhaps if necessary?)<br>
      <br>
      This may need some thinking, hi hi.<br>
      <div><br>
        73 de TF2SUT - Samúel<br>
      </div>
      <br>
      <br>
      <div class="gmail_quote">On 19 March 2013 21:13, Lynn W.
        Deffenbaugh (Mr) <span dir="ltr"><<a moz-do-not-send="true"
            href="mailto:ldeffenb@homeside.to" target="_blank">ldeffenb@homeside.to</a>></span>
        wrote:<br>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">
          On 3/19/2013 4:01 PM, Samúel Úlfr Þór Guðjónsson wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <br>
            That way, the digipeater will only digipeat if no other digi
            hears the packet, but does not add extra traffic to RF if
            the packet is received by another digi. TX IGate would also
            be good within that setup, with or without the digipeater
            functions.<br>
          </blockquote>
          <br>
          Well, at least that's the hope of viscous digipeating.  It
          would be more accurate to say:<br>
          <br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            A viscous digipeater will only digipeat a packet if it
            doesn't decode another digipeat of the packet within the
            delay period.<br>
          </blockquote>
          <br>
          It is completely based on receiving and decoding the remote
          digipeater's packets as there is no way to truly know that "no
          other digi" heard and/or digipeated the packet.<br>
          <br>
          Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and
          Win32<br>
          <br>
          _______________________________________________<br>
          aprssig mailing list<br>
          <a moz-do-not-send="true" href="mailto:aprssig@tapr.org"
            target="_blank">aprssig@tapr.org</a><br>
          <a moz-do-not-send="true"
            href="http://www.tapr.org/mailman/listinfo/aprssig"
            target="_blank">http://www.tapr.org/mailman/listinfo/aprssig</a><br>
        </blockquote>
      </div>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
aprssig mailing list
<a class="moz-txt-link-abbreviated" href="mailto:aprssig@tapr.org">aprssig@tapr.org</a>
<a class="moz-txt-link-freetext" href="http://www.tapr.org/mailman/listinfo/aprssig">http://www.tapr.org/mailman/listinfo/aprssig</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>