<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 1/25/2017 11:40 AM, John Langner
      WB2OSZ wrote:<br>
    </div>
    <blockquote cite="mid:000001d27729$b05439c0$10fcad40$@net"
      type="cite">
      <pre wrap="">
</pre>
      <blockquote type="cite">
        <pre wrap="">Has anybody actually succeeded in putting two KISS TNC's "back to 
back" to form an independently operating (no computer between them) 
two-way "bridge" to pass traffic bi-directionally?
Lots of suggesting that this could work, but has it been done?
</pre>
      </blockquote>
      <pre wrap="">
In theory it should work but it's not a proper solution to the problem.
Here is why.

</pre>
    </blockquote>
    <SNIP><br>
    <blockquote cite="mid:000001d27729$b05439c0$10fcad40$@net"
      type="cite">
      <pre wrap="">
If you were to simply retransmit what you hear on one frequency onto some
other frequency, that would be OK if only one person was doing it.  However,
if you had two stations like this, that could hear each other, the same
packet could go bouncing back and forth forever.

</pre>
    </blockquote>
    <br>
    I have successfully done the back-to-back TNC approach in one very
    specific application where the looping issue will never occur.<br>
    <br>
    That is at a Mic-E-enabled voice repeater, where a APRS posit is
    transmitted each time you unkey from a voice transmission.    I
    placed two TNCs wired back-to-back at the voice repeater site. One
    had it's receive audio input connected to the repeater's receive
    audio.    The other TNC was connected to a transceiver on 144.39. 
    Only the TX audio, PTT and RX COR lines were connected - no RX audio
    connection.   <br>
    <br>
    The net result is a no-path-decrementing one-way digi.   When voice
    users would transmit tail-gate APRS bursts on the repeater uplink,
    they would get retransmitted on 144.39 without any loss in the path.
      The repeater-input TNC had it's carrier detect wired to the
    repeater controller to mute the repeat audio during the packet
    burst.   The squelch/COR connection on the 144.39 TNC would inhibit
    the retransmission until the APRS channel was clear.  Since the
    voice repeater had a clear line-of-site shot at an APRS digipeater 7
    miles away, I was able to use an Icom IC-02 handheld inside the
    building (no additional antennas on the tower) as the 144.39
    transmitter.    <br>
    <br>
    I could have done this with a single TNC set up as a digipeater,
    with the RX side tied to the repeater audio and the TX side
    connected to the 144.39 radio, but I wanted positive carrier detect
    on both sides (to mute the repeater repeat audio, and to hold off
    transmit on 144.39.  Further, I wanted the MIc-E setup to be
    transparent to any path the voice user had setup.   (A normal digi
    setup would have consumed one hop of the user's path.)<br>
    <br>
    <hr size="2" width="100%">Stephen H. Smith    wa8lmf (at) aol.com <br>
    Skype:        WA8LMF<br>
    EchoLink:  Node #  14400  [Think bottom of the 2-meter band]<br>
    Home Page:          <a class="moz-txt-link-freetext" href="http://wa8lmf.net">http://wa8lmf.net</a><br>
    <br>
     _______ Windows 10 Outrages! _______<br>
       <a class="moz-txt-link-rfc2396E" href="http://WA8LMF.net/Windows10_Info"><http://WA8LMF.net/Windows10_Info></a><br>
    <br>
    Live Off-The-Air APRS Activity Maps<br>
       <a class="moz-txt-link-rfc2396E" href="http://wa8lmf.net/map"><http://wa8lmf.net/map></a><br>
    <br>
    Long-Range APRS on 30 Meters HF <br>
       <a class="moz-txt-link-rfc2396E" href="http://wa8lmf.net/aprs/HF_APRS_Notes.htm"><http://wa8lmf.net/aprs/HF_APRS_Notes.htm></a><br>
    <br>
  </body>
</html>