<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    On Randy's statement that "If the digipeater is correctly
    configured, it will TX *at the instant it sees the end of packet
    flag*" - a TNC should never be knowingly transmitting over another
    signal. How do you decide when a signal is present? Typically that's
    done one of three ways:<br>
    <br>
    1. SQL/COR signal from the receiver indicating a good carrier<br>
    2. Receiver squelch with energy detect (VOX)<br>
    3. Modem is locked and receiving valid data<br>
    <br>
    In none of those cases can the channel be assumed clear immediately
    after a flag. There's some variation in how #3 is implemented but
    for the OpenTracker series they all go by clock recovery status -
    each bit transition is expected to fall within a certain time
    window, and if a set number of transitions occur outside of the
    defined window, lock is considered lost and this is passed on to the
    carrier detect system which handles any configured delays.<br>
    <br>
    If you really think super-fast turnaround after the end of a packet
    is important, I think that's the way to do it. It's sufficient to
    wait just one or two byte times after the last flag. If you're still
    getting bits at the expected times, the sender is probably still
    sending. If it's all noise, it's probably safe to assume it's done.<br>
    <br>
    I'm pretty sure there are some implementations that don't do a
    contiguous Bell 202 signal between packets - they might have some
    dead time, or restart the modulator at a default phase value with
    each packet - but I think it's fair to impose some requirements on
    transmitters. If you want your back-to-back packets to go through,
    you make sure they're seamless. Anything else is just wasting half
    the benefit of the back-to-back packets anyway, because the
    receiving side has to go through clock sync again.<br>
    <br>
    APRS is terribly inefficient already. Let's not make inefficiency a
    requirement.<br>
    <br>
    Scott<br>
    N1VG<br>
    <br>
    <div class="moz-cite-prefix">On 11/21/2021 11:35 AM, Kenneth
      Finnegan wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAFS5k-h+3iWH79x_Bt-Y4K=pjXo=iW8RaAwNJVV07iVpDsQJsA@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div dir="ltr">
          <div dir="ltr" class="gmail_attr">On Thu, Sep 23, 2021 at 7:14
            AM Randy Love <<a href="mailto:rlove31@gmail.com"
              moz-do-not-send="true" class="moz-txt-link-freetext">rlove31@gmail.com</a>>
            wrote:<br>
          </div>
          <blockquote class="gmail_quote" style="margin:0px 0px 0px
            0.8ex;border-left:1px solid
            rgb(204,204,204);padding-left:1ex">
            <div dir="ltr">
              <div>Sadly tho, most digipeaters are not configured
                properly.</div>
            </div>
          </blockquote>
          <div><br>
          </div>
          <div>A slightly different take on this is that there's a large
            contingent of operators that think this fratricide theory is
            nonsense. I haven't seen any robust justification that this
            actually works other than "you know, FM capture effect is a
            thing so this should work in theory"</div>
          <div><br>
          </div>
          <div>There's just so many different scenarios where being able
            to transmit more than one packet at a time is desirable that
            regardless of fratricide actually working, I don't subscribe
            to it actually being helpful:</div>
          <div>1. Sharing the same TX delay for position and telemetry</div>
          <div>2. Sharing the same TX delay for ACK and reply message</div>
          <div>3. Sharing the same TX delay for multi-line messages or
            bulletins because the message length limit is so ungodly
            short because of the IBM PC screen width limits</div>
          <div>4. Sharing the same TX delay for several digipeated
            packets which have queued up while waiting for CSMA/CA to
            grab the channel</div>
          <div><br>
          </div>
          <div>The fact that Kenwood only shows the last posit on the
            display is a bad reason to try and get stations to transmit
            multiple packets with "slight breaks" between them. Fine, so
            now the Kenwood updates the display five times at.... some
            fast interval and you still can only read the last posit
            sent.</div>
          <div><br>
          </div>
          <div>The fact that we expect stations to transmit single
            packets at a time, but then don't actually document some
            lower limit on packet interval or required idle time between
            transmitting packets in the spec means it isn't actually
            going to happen. When a TNC receives five packets to send to
            RF, what is it supposed to do? Dump all five of them in a
            single data stream, or buffer up the additional packets and
            introduce one or several seconds of delay per packet in the
            transmit queue?</div>
          <div><br>
          </div>
          <div>The fact that some stations don't have enough buffer
            space to handle more than one packet at a time sounds like a
            problem we shouldn't still be accommodating in APRS routing
            behavior in 2021. Fine for deaf trackers, but if a
            digipeater can't handle more than one packet at a time, then
            it sounds like the digipeater needs better hardware. I
            suspect that many modems also don't handle two packets
            sharing the same flag byte between them because the receive
            state machine isn't implemented correctly to handle that,
            but that should also be something that is documented/tested
            so we can start improving the situation or at least be aware
            of it instead of just assuming multiple-packet transmissions
            shouldn't be happening.</div>
          <div> </div>
          <div>
            <div dir="ltr" class="gmail_signature"
              data-smartmail="gmail_signature">--<br>
              Kenneth Finnegan, W6KWF<br>
              <a href="http://blog.thelifeofkenneth.com/"
                target="_blank" moz-do-not-send="true"
                class="moz-txt-link-freetext">http://blog.thelifeofkenneth.com/</a></div>
          </div>
          <br>
        </div>
        <br>
        <div class="gmail_quote">
          <div dir="ltr" class="gmail_attr">On Thu, Sep 23, 2021 at 7:14
            AM Randy Love <<a href="mailto:rlove31@gmail.com"
              moz-do-not-send="true" class="moz-txt-link-freetext">rlove31@gmail.com</a>>
            wrote:<br>
          </div>
          <blockquote class="gmail_quote" style="margin:0px 0px 0px
            0.8ex;border-left:1px solid
            rgb(204,204,204);padding-left:1ex">
            <div dir="ltr">Define 'slight breaks', please.
              <div><br>
              </div>
              <div>If the digipeater is correctly configured, it will TX
                *at the instant it sees the end of packet flag*. </div>
              <div>There should be minimal tx delay, only enough to
                handle the time it takes the transmitter to come up and
                stabilize, before the digipeater sends the packet it is
                to digipeat. It is up to other stations on the channel
                to listen before transmitting, but the digipeaters are
                meant to clobber each other on the caveat that although
                they might hear each other, most uses will be close
                enough to one or the other digipeaters to have FM
                capture to cover the one farther away.</div>
              <div><br>
              </div>
              <div>Sadly tho, most digipeaters are not configured
                properly.</div>
              <div><br>
              </div>
              <div>Randy</div>
              <div>WF5X</div>
              <div><br>
              </div>
            </div>
            <br>
            <div class="gmail_quote">
              <div dir="ltr" class="gmail_attr">On Wed, Sep 22, 2021 at
                7:01 PM Eric H. Christensen <<a
                  href="mailto:eric@aehe.us" target="_blank"
                  moz-do-not-send="true" class="moz-txt-link-freetext">eric@aehe.us</a>>
                wrote:<br>
              </div>
              <blockquote class="gmail_quote" style="margin:0px 0px 0px
                0.8ex;border-left:1px solid
                rgb(204,204,204);padding-left:1ex">‐‐‐‐‐‐‐ Original
                Message ‐‐‐‐‐‐‐<br>
                On Monday, September 20th, 2021 at 1:07 PM, Randy Love
                <<a href="mailto:rlove31@gmail.com" target="_blank"
                  moz-do-not-send="true" class="moz-txt-link-freetext">rlove31@gmail.com</a>>
                wrote:<br>
                <br>
                > The burst method may not be compatible with local
                digipeaters... or some TNC's even.<br>
                ><br>
                > Some digipeaters transmit the split second they see
                an end-of-packet indicator under the assumption that the
                tx is done since the packet is completed. That would
                cause the digipeater to collide with the rest of your
                long packet that you are sending as a burst.<br>
                ><br>
                > This is done on purpose to induce the
                packet fratricide that is necessary for peak performance
                of APRS digipeating. (i.e. the digipeater will only be
                colliding with other digipeaters transmitting the same
                packet )<br>
                <br>
                So I understand this *but*...<br>
                <br>
                ...here's what I'm seeing in practice.  My i-gate sends
                out weather alerts for my local area to a path of
                WIDE2-1.  I just watched a thunderstorm warning go out
                that contained three packets.  These three packets went
                out with only slight breaks in between, hardly any time
                for the digipeater to retransmit before the next packet
                came out leading to a collision.  I've seen similar
                results when transmitting messages and telemetry
                parameters, too, meaning that at least half of the
                packets are being wasted and delayed.<br>
                <br>
                --Eric WG3K<br>
              </blockquote>
            </div>
            _______________________________________________<br>
            aprssig mailing list<br>
            <a href="mailto:aprssig@lists.tapr.org" target="_blank"
              moz-do-not-send="true" class="moz-txt-link-freetext">aprssig@lists.tapr.org</a><br>
            <a
              href="http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org"
              rel="noreferrer" target="_blank" moz-do-not-send="true"
              class="moz-txt-link-freetext">http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org</a><br>
          </blockquote>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
aprssig mailing list
<a class="moz-txt-link-abbreviated" href="mailto:aprssig@lists.tapr.org">aprssig@lists.tapr.org</a>
<a class="moz-txt-link-freetext" href="http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org">http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>