Loading ...
Sorry, an error occurred while loading the content.

Failed V4 ARQ connection info

Expand Messages
  • Robert
    Hi Rick, I was calling CQ tonight with V4 Chat version 0.3.0.1 (TNC also 0.3.0.1) on 14.073 and got a connection from NR5G. Seemed like a good clean signal
    Message 1 of 16 , Jul 7, 2011
    • 0 Attachment
      Hi Rick,

      I was calling CQ tonight with V4 Chat version 0.3.0.1 (TNC also 0.3.0.1) on 14.073 and got a connection from NR5G. Seemed like a good clean signal with a clear constellation. The receive window indicated a connection but I never got any received data from him and my xmit window would not transmit anything.

      I have emailed the debug log and receive window. Hope this helps.

      Robert Wright, N7ZO
    • W6IDS
      Did you reverse the positions and observe that transaction also? Howard W6IDS Richmond, IN EM79NV ... From: Robert To:
      Message 2 of 16 , Jul 7, 2011
      • 0 Attachment
        Did you reverse the positions and observe that transaction also?

        Howard W6IDS
        Richmond, IN EM79NV


        ----- Original Message -----
        From: "Robert" <rwright@...>
        To: <V4Protocol@yahoogroups.com>
        Sent: Thursday, July 07, 2011 10:16 PM
        Subject: [V4Protocol] Failed V4 ARQ connection info


        > Hi Rick,
        >
        > I was calling CQ tonight with V4 Chat version 0.3.0.1 (TNC also 0.3.0.1)
        > on 14.073 and got a connection from NR5G. Seemed like a good clean signal
        > with a clear constellation. The receive window indicated a connection but
        > I never got any received data from him and my xmit window would not
        > transmit anything.
        >
        > I have emailed the debug log and receive window. Hope this helps.
        >
        > Robert Wright, N7ZO
        >
      • Robert
        No. NR5G connected twice but we were never able to communicate. After that, I did not hear him calling CQ. Next time this happens I will drop back to FEC
        Message 3 of 16 , Jul 7, 2011
        • 0 Attachment
          No. NR5G connected twice but we were never able to communicate. After that, I did not hear him calling CQ.

          Next time this happens I will drop back to FEC mode and try to coordinate a reverse CQ call.

          I have never been able to get ARQ mode to work. I thought it was about time to pass some debug info to Rick.


          --- In V4Protocol@yahoogroups.com, "W6IDS" <w6ids@...> wrote:
          >
          > Did you reverse the positions and observe that transaction also?
          >
          > Howard W6IDS
          > Richmond, IN EM79NV
          >
          >
          > ----- Original Message -----
          > From: "Robert" <rwright@...>
          > To: <V4Protocol@yahoogroups.com>
          > Sent: Thursday, July 07, 2011 10:16 PM
          > Subject: [V4Protocol] Failed V4 ARQ connection info
          >
          >
          > > Hi Rick,
          > >
          > > I was calling CQ tonight with V4 Chat version 0.3.0.1 (TNC also 0.3.0.1)
          > > on 14.073 and got a connection from NR5G. Seemed like a good clean signal
          > > with a clear constellation. The receive window indicated a connection but
          > > I never got any received data from him and my xmit window would not
          > > transmit anything.
          > >
          > > I have emailed the debug log and receive window. Hope this helps.
          > >
          > > Robert Wright, N7ZO
          > >
          >
        • Robert
          Correction to my last post: No. NR5G connected twice but we were never able to communicate. After that, I did not hear him calling, CQ or otherwise. Next time
          Message 4 of 16 , Jul 7, 2011
          • 0 Attachment
            Correction to my last post:

            No. NR5G connected twice but we were never able to communicate. After that, I did not hear him calling, CQ or otherwise.

            Next time this happens I will drop back to FEC mode and try to coordinate a reverse call. Using a CQ call for this would be ideal, but a targeted callsign call might show the same problem after connection.

            --- In V4Protocol@yahoogroups.com, "Robert" <rwright@...> wrote:
            >
            > No. NR5G connected twice but we were never able to communicate. After that, I did not hear him calling CQ.
            >
            > Next time this happens I will drop back to FEC mode and try to coordinate a reverse CQ call.
            >
            > I have never been able to get ARQ mode to work. I thought it was about time to pass some debug info to Rick.
            >
            >
            > --- In V4Protocol@yahoogroups.com, "W6IDS" <w6ids@> wrote:
            > >
            > > Did you reverse the positions and observe that transaction also?
            > >
            > > Howard W6IDS
            > > Richmond, IN EM79NV
            > >
            > >
            > > ----- Original Message -----
            > > From: "Robert" <rwright@>
            > > To: <V4Protocol@yahoogroups.com>
            > > Sent: Thursday, July 07, 2011 10:16 PM
            > > Subject: [V4Protocol] Failed V4 ARQ connection info
            > >
            > >
            > > > Hi Rick,
            > > >
            > > > I was calling CQ tonight with V4 Chat version 0.3.0.1 (TNC also 0.3.0.1)
            > > > on 14.073 and got a connection from NR5G. Seemed like a good clean signal
            > > > with a clear constellation. The receive window indicated a connection but
            > > > I never got any received data from him and my xmit window would not
            > > > transmit anything.
            > > >
            > > > I have emailed the debug log and receive window. Hope this helps.
            > > >
            > > > Robert Wright, N7ZO
            > > >
            > >
            >
          • Rick Muething
            All, I have just about got all the lost source code recovered and repaired... Damn Virus! I also am working on a new major release that will address several
            Message 5 of 16 , Jul 9, 2011
            • 0 Attachment
              All,
              I have just about got all the lost source code recovered and repaired... Damn Virus! I also am working on a new major release that will address several observed problems:
               
              1) Excessive PTT hold ....a critical problem for ARQ modes. Many say “but it works on PSK, Olivia etc” but those are not ARQ Modes. I have a plan to implement a detection of this with the software that will warn users of this excessive PTT hold which has the effect of blocking off the ACKs from the other end. (for example if using a SignaLink or VOX with the Delay set too large). I can’t reduce the PTT hold in software but I can warn of it so you can correct it by settings or by selecting a different PTT keying method.
               
              2) Automatic Round Trip delay (from end of transmit frame to received ACK/NAK sync) calculation and adjustment. There are many factors that affect the timing of the round trip: e.g.
              Transmitter Receive to Transmit delay
              Sound card latency
              RF Transit time
              Receiver sound card latency (can be a significant issue on SDR Radios)
              OS Latency (Windows was never designed as a true “real time” OS!)
              Demodulation/decode time (a function of CPU Speed)
              Leader length or VOX delay
              The new code will start off each new ARQ session with very generous ARQ timing limits (which of course will reduce throughput) and then based on the actual measured (to within about 20 ms) round trip delay put in a more aggressive (faster throughput) limit for each connection. It will have to have some “pad” to accommodate variances but this should work much better and result in reliable and faster operation without having to have users tweak values.
               
              3) Session Keying of FEC Data, ACK, NAK and IDLs. Currently if there is any other V4 activity (even weak) on or near the frequency it disrupts the protocol by cross contamination of the sessions. This new code creates a fairly unique (8 bit) key that is a function (hash) of the two connected call signs. Unless your ARQ Session has the exact same key (about 1/256 chance) it will ignore those other frames. This keyed sync will slow down the throughput but only by about 2%. Of course since this is not spread spectrum you really can’t expect to have a good QSO with significant interference by other stations but it will drastically reduce the effect casual weak interference will have on the protocol. A  larger key could be used but it starts affecting throughput with only very marginal improvement in protection so I picked 8 bits
              .
              It will probably be a week or two until I get this update finished and enough for beta release.
               
              I have received some useful debug logs from some that point to another problem which I will have to track down. If you happen to have a session with fairly good signals that get hung in some IDL loop when data is queued please send your debug log to me with the approximate UTC time noted (PLEASE, I DON’T HAVE TIME TO WADE THROUGH 1 MByte DEBUG LOGS WITHOUT SOME CLUE AS TO WHERE THE PROBLEM IS!)
                Send the logs directly to me as attachments (rmuethingATcfl.rr.com)
               
              Thanks for your continued support and feedback.
               
              73,
              Rick KN6KB

            • W6IDS
              You ve got one incredible work ethic, not to mention endurance. It just takes one s breath away watching how you keep on truckin , Rick. Howard W6IDS
              Message 6 of 16 , Jul 9, 2011
              • 0 Attachment
                
                 
                You've got one incredible work ethic, not to mention
                endurance.  It just takes one's breath away watching 
                how you keep on truckin', Rick.
                 
                Howard W6IDS
                Richmond, IN EM79NV
                 
                ----- Original Message -----
                Sent: Saturday, July 09, 2011 9:28 AM
                Subject: [V4Protocol] New Planned Updates

                All,
                I have just about got all the lost source code recovered and repaired... Damn Virus! I also am working on a new major release that will address several observed problems:
                 
                 <SNIP> <SNIP>
              • Ian Wade G3NRW
                From: Rick Muething Date: Sat, 9 Jul 2011 Time: 09:28:19 ... This is why I asked here on 24 June:
                Message 7 of 16 , Jul 9, 2011
                • 0 Attachment
                  From: Rick Muething <rmuething@...>
                  Date: Sat, 9 Jul 2011 Time: 09:28:19

                  >3) Session Keying of FEC Data, ACK, NAK and IDLs. Currently if there is
                  >any other V4 activity (even weak) on or near the frequency it disrupts the
                  >protocol by cross contamination of the sessions.

                  This is why I asked here on 24 June:
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                  I don't think I ever expected V4 to handle more than one ARQ connection
                  at a time. But can V4 handle multiple ACKs on a busy frequency arising
                  from many different (unrelated) connections, ignoring all ACKs other
                  than the one it expects to hear at any given time?

                  Or is it possible for V4 to erroneously respond to an ACK belonging to
                  another (unrelated) connection?
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


                  >This new code creates a
                  >fairly unique (8 bit) key that is a function (hash) of the two connected call
                  >signs. Unless your ARQ Session has the exact same key (about 1/256
                  >chance) it will ignore those other frames. This keyed sync will slow down
                  >the throughput but only by about 2%. Of course since this is not spread
                  >spectrum you really can’t expect to have a good QSO with significant
                  >interference by other stations but it will drastically reduce the effect casual
                  >weak interference will have on the protocol. A  larger key could be used
                  >but it starts affecting throughput with only very marginal improvement in
                  >protection so I picked 8 bits

                  This is a good step in the right direction, but another question: how
                  does/will V4 handle missing/duplicate frames?

                  --
                  73
                  Ian, G3NRW
                • Rick Muething
                  Ian, The Session Keying of the Syncs just reduces the susceptibility to non connected ARQ or FEC session. The trick is to insure the sync key is ignored in
                  Message 8 of 16 , Jul 10, 2011
                  • 0 Attachment
                    Ian,
                    The Session Keying of the Syncs just reduces the susceptibility to non connected ARQ or FEC session.  The trick is to insure the sync key is ignored in decoding the first connect request since the target station doesn’t yet know the sync key. I have a scheme for that because the sync key is contain in the CRC of the connect request frame which is only decoded if you are not already connected.
                     
                    Not sure I follow your question on missing or duplicate frames. Maybe this answers your question.
                     
                    1) If the ISS sends a frame and it is not ACKed (actually if the ISS does not receive and decode the ACK from the IRS confirming reception by the IRS) it simple repeats the frame until it is ACKed or the link times out.  So you can’t get a missing frame unless of course the link drops out (typically 90 seconds of no ACKs).  Any ACKs received by the ISS that don’t match the session ID key are ignored.
                     
                    2) If the ISS sends a frame and it is received and ACKed by the IRS but the ISS misses the ACK it repeats the frame. But since the IRS keeps an exact copy of the last frame ACKed and passed to the application it compares every received frame to the last ACKed frame. If it is a duplicate frame the IRS will ACK again but NOT pass the duplicate data to the application.  This isn’t quite bulletproof (what if you really wanted to send to exactly the same 16 character frames sequentially?) but this is very unlikely under normal text conditions unless you are sending say a very long string of the same characters.  In WINMOR where you are transmitting exact binary data using multiple carriers each packet carries an 8 bit packet sequence number but that would be more overhead in V4 which is probably not really needed. If it turns out in testing we really feel each frame needs a sequence number it could be added at some expense of throughput.
                     
                    The real challenge is incorporating some of these features without loading up the overhead which kills the throughput.  The keyed sync system I came up with only added 2 symbols per frame (~42 ms)... less than  2%. It will be interesting to see how that works in practice.
                     
                    Rick KN6KB
                     
                     
                    Sent: Saturday, July 09, 2011 10:47 AM
                    Subject: Re: [V4Protocol] New Planned Updates
                     
                     

                    From: Rick Muething <mailto:rmuething%40cfl.rr.com>
                    Date: Sat, 9 Jul 2011 Time: 09:28:19

                    >3) Session Keying of FEC Data, ACK,
                    NAK and IDLs. Currently if there is
                    >any other V4 activity (even weak) on
                    or near the frequency it disrupts the
                    >protocol by cross contamination of
                    the sessions.

                    This is why I asked here on 24 June:
                    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                    I don't think I ever expected V4 to handle more than one ARQ connection
                    at a time. But can V4 handle multiple ACKs on a busy frequency arising
                    from many different (unrelated) connections, ignoring all ACKs other
                    than the one it expects to hear at any given time?

                    Or is it possible for V4 to erroneously respond to an ACK belonging to
                    another (unrelated) connection?
                    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

                    >This
                    new code creates a
                    >fairly unique (8 bit) key that is a function (hash) of
                    the two connected call
                    >signs. Unless your ARQ Session has the exact same
                    key (about 1/256
                    >chance) it will ignore those other frames. This keyed
                    sync will slow down
                    >the throughput but only by about 2%. Of course since
                    this is not spread
                    >spectrum you really can’t expect to have a good QSO
                    with significant
                    >interference by other stations but it will drastically
                    reduce the effect casual
                    >weak interference will have on the protocol.
                    A  larger key could be used
                    >but it starts affecting throughput with
                    only very marginal improvement in
                    >protection so I picked 8
                    bits

                    This is a good step in the right direction, but another question: how
                    does/will V4 handle missing/duplicate frames?

                    --
                    73
                    Ian, G3NRW


                    No virus found in this message.
                    Checked by AVG - www.avg.com
                    Version: 10.0.1388 / Virus Database: 1516/3754 - Release Date: 07/09/11

                  • Ian Wade G3NRW
                    From: Rick Muething Date: Sun, 10 Jul 2011 Time: 07:35:31 ... Sounds good. ... [Snip Rick s answer] That also sounds good. My main
                    Message 9 of 16 , Jul 10, 2011
                    • 0 Attachment
                      From: Rick Muething <rmuething@...>
                      Date: Sun, 10 Jul 2011 Time: 07:35:31

                      >Ian,
                      >The Session Keying of the Syncs just reduces the susceptibility to non
                      >connected ARQ or FEC session. The trick is to insure the sync key is
                      >ignored in decoding the first connect request since the target station
                      >doesn’t yet know the sync key. I have a scheme for that because the
                      >sync key is contain in the CRC of the connect request frame which is
                      >only decoded if you are not already connected.

                      Sounds good.


                      >Not sure I follow your question on missing or duplicate frames. Maybe
                      >this answers your question.

                      [Snip Rick's answer]

                      That also sounds good. My main concern was what happens if the original
                      data was indeed repeated in more than one frame, and how would the
                      receiving end recognize this without frame sequence numbering. In binary
                      transfers this is a real possibility, but in a keyboard chat situation
                      this is unlikely to be an issue.

                      However, it is my understanding that you will be offering the modem as a
                      candidate for inclusion in other people's packages. I think you will
                      need to make it clear that the modem will be unsuitable for reliable
                      binary transfer, because of the lack of frame sequence numbering.


                      >
                      >The real challenge is incorporating some of these features without
                      >loading up the overhead which kills the throughput.

                      Agreed.


                      >It will be interesting to see how that works in practice.

                      I'm looking forward to trying it!

                      --
                      73
                      Ian, G3NRW
                    • karel Fassotte
                      Hello rick, althoug I cant participate in the US, european testing. I am testing the software overhere in ecuador in a 1 hop mode at about 500km. I would like
                      Message 10 of 16 , Jul 10, 2011
                      • 0 Attachment
                        Hello rick, althoug I cant participate in the US, european testing. I am testing the software overhere in ecuador in a 1 hop mode at about 500km. I would like to ask, you adressed already, if it is possible to delay the TX/TX timing by software, so radios with a slow AGC will have a possibility to synchronize. I have several radios with a fixed ACG. Te other way would be changing the hardware to make the AGC faster. 
                        Greetings 
                        Karel 

                      • Rick Muething
                        Ian, V4 is not intended for binary transfer. There is already a good and much faster sound card protocol called WINMOR (500 Hz or 1600 Hz BW) that is designed
                        Message 11 of 16 , Jul 10, 2011
                        • 0 Attachment
                          Ian,
                           
                          V4 is not intended for binary transfer.  There is already a good and much faster sound card protocol called WINMOR (500 Hz or 1600 Hz BW) that is designed and optimized for binary transfer (including compressed text).  V4 is designed and optimized for fairly quick turnaround keyboard sessions using plain text (ASCII or UTF-8 encoding).  The only reason one would use V4 for binary transfer is to force the connection into a 200 Hz bandwidth.  Better throughput would almost always be achieved using WINMOR and WINMOR has a gear (modulation) shifting mode that dynamically adapts to the channel conditions.
                           
                          Rick KN6KB
                           
                        • Rick Muething
                          The next beta release will have a mechanism in that automatically measures what I call T R Latency. That is the delay from the programs release of the PTT line
                          Message 12 of 16 , Jul 10, 2011
                          • 0 Attachment
                            The next beta release will have a mechanism in that automatically measures what I call T>R Latency. That is the delay from the programs release of the PTT line to the first detection of received audio.  I am testing this now and for example with my SignaLink USB and TS480 (The SignaLInk releases the PTT when there is no audio being “played” similar to VOX) The measured T>R Latency is about 120 ms with the SignaLink delay set to minimum.  That 120 ms is the sum of several components including some latency in the OS and sound card.  This really should not have anything to do with AGC timing as most receives come back to receive rapidly regardless of AGC speed. (The AGC speed will of course slow down the response to an over load signal but that should  occur only if you are actually monitoring your own transmitter.   On my setup I get virtually the same T>R Latency measurement with AGC set to Fast or Slow.
                             
                            The new release will also include an automatic measurement and auto adjustment of the round trip time (Release of PTT until ACK sync detected). This permits optimizing the timing (including necessary guardbands) based on actual measured values ...which could be unique for each session. This will help with operation using VOX or with SDR Radios.
                             
                            However if you want to universally be able to operate with very large T>R Latency (say > 300 ms) you would have to impose a large guard band on EVERY connection as this cannot be removed or compensated automatically by the software.  Keep in mind most modern transceivers have T>R switching times of < 50 ms.  Pactor for example requires T>R switching times < 50 ms.
                             
                            Rick KN6KB
                             
                          • la7um
                            Rick. The research you are doing now, could that be archived for some later thinking IF, I say IF, an FM and FM Repeater optimized version of Winmor appears?
                            Message 13 of 16 , Jul 12, 2011
                            • 0 Attachment
                              Rick. The research you are doing now, could that be archived for some later thinking IF, I say IF, an FM and FM Repeater optimized version of Winmor appears?

                              73. Finn/LA7UM

                              --- In V4Protocol@yahoogroups.com, "Rick Muething" <rmuething@...> wrote:
                              >
                              > The next beta release will have a mechanism in that automatically measures what I call T>R Latency. That is the delay from the programs release of the PTT line to the first detection of received audio. I am testing this now and for example with my SignaLink USB and TS480 (The SignaLInk releases the PTT when there is no audio being “played” similar to VOX) The measured T>R Latency is about 120 ms with the SignaLink delay set to minimum. That 120 ms is the sum of several components including some latency in the OS and sound card. This really should not have anything to do with AGC timing as most receives come back to receive rapidly regardless of AGC speed. (The AGC speed will of course slow down the response to an over load signal but that should occur only if you are actually monitoring your own transmitter. On my setup I get virtually the same T>R Latency measurement with AGC set to Fast or Slow.
                              >
                              > The new release will also include an automatic measurement and auto adjustment of the round trip time (Release of PTT until ACK sync detected). This permits optimizing the timing (including necessary guardbands) based on actual measured values ...which could be unique for each session. This will help with operation using VOX or with SDR Radios.
                              >
                              > However if you want to universally be able to operate with very large T>R Latency (say > 300 ms) you would have to impose a large guard band on EVERY connection as this cannot be removed or compensated automatically by the software. Keep in mind most modern transceivers have T>R switching times of < 50 ms. Pactor for example requires T>R switching times < 50 ms.
                              >
                              > Rick KN6KB
                              >
                            • Rick Muething
                              Finn, I am making good headway on the round trip correction in V4 and also in measuring the Transmit Receive switchover time. Those two things can be applied
                              Message 14 of 16 , Jul 12, 2011
                              • 0 Attachment
                                Finn,
                                 
                                I am making good headway on the round trip correction in V4 and also in measuring the Transmit>Receive switchover time.  Those two things can be applied fairly easily to WINMOR.
                                 
                                Here is the problem with trying to automatically handle WINMOR via a repeater.
                                 
                                1) Without a repeater the typical round trip delay (from release of PTT until the returned ACK is detected) is on the order of maybe 400-600 ms.   So you could fairly safely put the initial repeat interval (the interval between repeats if an ACK or NAK is mised) at say 1000 ms.   Then you could safely adjust that down to something just above (say 100 ms or so above) the actual MEASURED round trip delay.  That adjustment optimizes the throughput as a function of the connected station timing.
                                 
                                BUT
                                 
                                2) If you are using a repeater the round trip delay may be say 2-3 seconds.  So your initial connection has to start off with a repeat interval of at least that amount (Otherwise you’ll be repeating during the received ACK so you would miss it).  That adds a lot of time to a connect request which is already slow enough.
                                 
                                The only practical thing you could do is put a flag in the INI file that would set the initial repeat interval very long and live with the slow connect sequence and resulting lower throughput. After the initial ACK is received the repeat interval could be reduced but it would probably have to have some substantial margin over the measured round trip since there is some additional uncertainty going through each repeater.

                                But the basic problem is operating an ARQ mode through a repeater is VERY inefficient and begs to use very long data cycles to try and recover the throughput.   The issue I have is it is just not good engineering trying to spend lots of time and energy trying to fit the square peg in the round hole. In the end the best solution is to engineer the solution correctly from the beginning. 
                                 
                                Rick
                              • Lyle Johnson
                                When we developed the TAPR TNC, we added two timing parameters: AXDELAY and AXHANG as I recall. AXDELAY would add a specified delay time to keyup
                                Message 15 of 16 , Jul 12, 2011
                                • 0 Attachment
                                  When we developed the TAPR TNC, we added two timing parameters: AXDELAY and AXHANG as I recall.  AXDELAY would add a specified delay time to keyup flags-before-data to allow a voice repeater to key up and settle.

                                  As long as subsequent exchanges never exceeded AXHANG from the tail of one to the head of the next, AXDELAY would not be inserted.  This way, the additional delay to bring up the repeater was not used unless the repeater had timed out (exceeded AXHANG).

                                  Of course, in those days, we didn't use CTCSS and other delaying things...

                                  73,

                                  Lyle KK7P

                                  Here is the problem with trying to automatically handle WINMOR via a repeater....

                                • la7um
                                  Hi Rick and Lyle. I absolutely see your point of view Rick. You earlier mentioned some asyncron mode with strong fec...I wonder some future RPR alike.... RPR
                                  Message 16 of 16 , Jul 13, 2011
                                  • 0 Attachment
                                    Hi Rick and Lyle. I absolutely see your point of view Rick. You earlier mentioned some asyncron mode with strong fec...I wonder some future RPR alike....

                                    RPR is only 500Hz, asyncron, but maybe not "fec enough" as WINMOR 1600Hz and uneccessary narrow. but the way RPR changes to "extremely long bursts" when first running make my mind twist my brain like the Apollo 13 way of connecting a circular tube into a square hole (according to the movie only).

                                    Winmor, as you know I have proved and posted, works very well running through a NFM Voice repeater. And off course, by longer bursts, the loss of throughput by all the switchings is partly compensated by the longer bursts. Throughput for now falling to abt 6 KB/Min when good signals and one repeater. 2-3 KB/min when addedd a 6m to 70cm Xband repeater in the chain without CTCSS. It stumbles from time to time off course because of non proportional timeouts and not intended to, but still works.

                                    Response delay 1000 (default 100) and leader extension 10, default 0 on server and client through only ONE repeater.

                                    Client ALONE needed increasing leader extension to 23 for also stumbling through the x-band addon into the repeater set in carrier inn = carrier out mode.

                                    That WINMOR 1600Hz mode 2-3 KB/Min still might be pretty much quicker than through a congested multipath 80m during night time. And other more distant stations might need the HF frequences as well.

                                    In areas where infrastructure is devastated, I would think that the very first of priority would be rebuilding a VOICE repeater, and maybe suitable for chaining a X band rpt CTCSS may be a tool, before doing any Packet extra installations.

                                    And only from time to time some digital mail might be needed.

                                    Since you at various occations have mentioned some "philosofical thoughts about a mode more optimized for FM (NFM) then WINMOR OF TODAY is, a new mode maybe might work with longer bursts.

                                    Maybe by integrating results from switching measurements in V4 development and achievements from various fields, developing of V4 slowly may create a spinn off into some future new useful animal for everybody.

                                    Sorry for being Off Topic here, but getting inspired.

                                    Finn/LA7UM

                                    --- In V4Protocol@yahoogroups.com, Lyle Johnson <kk7p@...> wrote:
                                    >
                                    > When we developed the TAPR TNC, we added two timing parameters: AXDELAY
                                    > and AXHANG as I recall. AXDELAY would add a specified delay time to
                                    > keyup flags-before-data to allow a voice repeater to key up and settle.
                                    >
                                    > As long as subsequent exchanges never exceeded AXHANG from the tail of
                                    > one to the head of the next, AXDELAY would not be inserted. This way,
                                    > the additional delay to bring up the repeater was not used unless the
                                    > repeater had timed out (exceeded AXHANG).
                                    >
                                    > Of course, in those days, we didn't use CTCSS and other delaying things...
                                    >
                                    > 73,
                                    >
                                    > Lyle KK7P
                                    >
                                    > > Here is the problem with trying to automatically handle WINMOR via a
                                    > > repeater....
                                    >
                                  Your message has been successfully submitted and would be delivered to recipients shortly.