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

ARQ protocols used over RF links

Expand Messages
  • Robin
    In all practical trials of V4Chat (1.0.4.0) I have performed, the protocol gets jammed owing to both stations continuously claiming ISS simultaneously! This
    Message 1 of 5 , Aug 15, 2012
    • 0 Attachment
      In all practical trials of V4Chat (1.0.4.0) I have performed, the protocol gets jammed owing to both stations continuously claiming ISS simultaneously! This should not be possible. I am having problems understanding how the mechanism used to swap IRS<=>ISS should work.
      Being a newcomer to this mode, can I put a beginners question to the group?
      There is a limit defined for the T>R latency, presumably to ensure the synchronisation of ACK/NAK responses after sending an ARQ frame. But what about the latency R>T of the partnering transmitter? This is not mentioned in the documentation.
      Suppose the answering transmitter (sending the ACK/NAK) takes a "long" time to initiate modulated RF after its PTT has been activated, surely this can also provoke problems? As far as I can see from the logs, the frames are not uniquely identified (un-numbered) so with extreme unbalanced latencies and timing, it could be possible to lose co-ordination between ARQ data frames and the related ACK/NAK.

      Appreciate any thoughts or comments from the experts.
      Robin, 9H1ZZ
    • Rick Muething
      Robin, Some good questions...the answers are technical but I will try and summarize here. 1) There is a limit on T R latency (
      Message 2 of 5 , Aug 15, 2012
      • 0 Attachment
        Robin,
        Some good questions...the answers are technical but I will try and summarize here.
        1) There is a limit on T>R latency (< 250 ms) to maintain some performance in the protocol. For example in Pactor this is typically on the order of 50 ms and is fixed by the hardware and radio.   Almost any computer and radio can make the 250 ms limit unless something incorrectly is set up ....like the PTT hold (DLY on the SignaLink) is set too high.
         
        2) The program measures upon the first ACK received (during the establishment of a connection) the nominal delay from the release of its PTT to the reception of the ACK. This include the R>T latency on the remote end and therefore this is automatically measured (again with a fairly generous limits) This is used (with some safety margin) to determine what delay the ISS uses before sending the next frame.
         
        3) There is a fairly reliable and usually bullet proof way of IRS<>ISS changeover. If you are experience problems with this I need to see the debug log files from EACH end to make any analysis. There is a lot of information in the debug log along with timing measurement to 10 ms but you have to be intimately familiar with the code (and have the source in front of you) to be able to accurately interpret it.  EVERY half duplex ARQ mode has this issue when transitioning from ISS to IRS.  The goal is to have a completely bulletproof exchange under ALL combinations of missed requests and ACKs...it it generally not possible to reach perfection especially in very poor channels. The exchange of the IRS and ISS in V4 has been tested down to S/N of – 5 dB in poor multipath channels but as I said perfection is generally not possible.
         
        If you have detailed questions on the change over mechanism and states I will try and answer but looking at the text and diagrams in the V4 Protocol spec should be the best help.
         
        73,
         
        Rick Muething, KN6KB
         
        From: Robin
        Sent: Wednesday, August 15, 2012 11:04 AM
        Subject: [V4Protocol] ARQ protocols used over RF links
         
         

        In all practical trials of V4Chat (1.0.4.0) I have performed, the protocol gets jammed owing to both stations continuously claiming ISS simultaneously! This should not be possible. I am having problems understanding how the mechanism used to swap IRS<=>ISS should work.
        Being a newcomer to this mode, can I put a beginners question to the group?
        There is a limit defined for the T>R latency, presumably to ensure the synchronisation of ACK/NAK responses after sending an ARQ frame. But what about the latency R>T of the partnering transmitter? This is not mentioned in the documentation.
        Suppose the answering transmitter (sending the ACK/NAK) takes a "long" time to initiate modulated RF after its PTT has been activated, surely this can also provoke problems? As far as I can see from the logs, the frames are not uniquely identified (un-numbered) so with extreme unbalanced latencies and timing, it could be possible to lose co-ordination between ARQ data frames and the related ACK/NAK.

        Appreciate any thoughts or comments from the experts.
        Robin, 9H1ZZ


        No virus found in this message.
        Checked by AVG - www.avg.com
        Version: 10.0.1424 / Virus Database: 2437/5202 - Release Date: 08/15/12

      • Robin Hodgson
        Rick, Thanks for the informative response. I have put a few of my comments into your text (in blue). 73 Robin To: V4Protocol@yahoogroups.com From:
        Message 3 of 5 , Aug 16, 2012
        • 0 Attachment
          Rick,

          Thanks for the informative response.   I have put a few of my comments into your text (in blue).

          73  Robin


          To: V4Protocol@yahoogroups.com
          From: rmuething@...
          Date: Wed, 15 Aug 2012 13:00:46 -0400
          Subject: Re: [V4Protocol] ARQ protocols used over RF links

           

          Robin,
          Some good questions...the answers are technical but I will try and summarize here.
          1) There is a limit on T>R latency (< 250 ms) to maintain some performance in the protocol. For example in Pactor this is typically on the order of 50 ms and is fixed by the hardware and radio.   Almost any computer and radio can make the 250 ms limit unless something incorrectly is set up ....like the PTT hold (DLY on the SignaLink) is set too high.
          Rick, I am sure you have done a thorough analysis on this.
          When PTT is released, all RF transmission ceases.  Practically no delay. Then the receiver recovers rapidly.
          But when PTT is activated, the carrier will be switched on and simultaneously the AFSK data modulation process is initiated. Although RF should stabilise rapidly, in practice, certain transceivers do seem take quite some time (personally, I suspect the problem lies with their ALC circuitry and a switch-on glitch). 
           
          2) The program measures upon the first ACK received (during the establishment of a connection) the nominal delay from the release of its PTT to the reception of the ACK. This include the R>T latency on the remote end and therefore this is automatically measured (again with a fairly generous limits) This is used (with some safety margin) to determine what delay the ISS uses before sending the next frame.
          So you keep on repeating the same frame (about every 5 seconds) until an ACK is received. But you don't know which frame it is acknowledging, and the roundtrip figure is based on the assumption that it IS the last sent frame?

           
          3) There is a fairly reliable and usually bullet proof way of IRS<>ISS changeover. If you are experience problems with this I need to see the debug log files from EACH end to make any analysis. There is a lot of information in the debug log along with timing measurement to 10 ms but you have to be intimately familiar with the code (and have the source in front of you) to be able to accurately interpret it.  EVERY half duplex ARQ mode has this issue when transitioning from ISS to IRS.  The goal is to have a completely bulletproof exchange under ALL combinations of missed requests and ACKs...it it generally not possible to reach perfection especially in very poor channels. The exchange of the IRS and ISS in V4 has been tested down to S/N of – 5 dB in poor multipath channels but as I said perfection is generally not possible.
           
          If you have detailed questions on the change over mechanism and states I will try and answer but looking at the text and diagrams in the V4 Protocol spec should be the best help.

          Thanks Rick,  I will prepare our logs and send you (off list) a more detailed description of our trials.

          S/N of > +30dB over a 3km path on 20 meters. The IRS<=>ISS switch-over hangup is reproducible. 


          73,
           
          Rick Muething, KN6KB
           
          From: Robin
          Sent: Wednesday, August 15, 2012 11:04 AM
          Subject: [V4Protocol] ARQ protocols used over RF links
           
           
          In all practical trials of V4Chat (1.0.4.0) I have performed, the protocol gets jammed owing to both stations continuously claiming ISS simultaneously! This should not be possible. I am having problems understanding how the mechanism used to swap IRS<=>ISS should work.
          Being a newcomer to this mode, can I put a beginners question to the group?
          There is a limit defined for the T>R latency, presumably to ensure the synchronisation of ACK/NAK responses after sending an ARQ frame. But what about the latency R>T of the partnering transmitter? This is not mentioned in the documentation.
          Suppose the answering transmitter (sending the ACK/NAK) takes a "long" time to initiate modulated RF after its PTT has been activated, surely this can also provoke problems? As far as I can see from the logs, the frames are not uniquely identified (un-numbered) so with extreme unbalanced latencies and timing, it could be possible to lose co-ordination between ARQ data frames and the related ACK/NAK.

          Appreciate any thoughts or comments from the experts.
          Robin, 9H1ZZ



          No virus found in this message.
          Checked by AVG - www.avg.com
          Version: 10.0.1424 / Virus Database: 2437/5202 - Release Date: 08/15/12


        • Rick Muething
          Robin, As simple as you make it sound the real world is a bit different! The PTT release is called for by the ending of the playing of the transmitted
          Message 4 of 5 , Aug 16, 2012
          • 0 Attachment
            Robin,
             
            As simple as you make it sound the real world is a bit different!
            The PTT release is called for by the ending of the playing of the transmitted audio...At the instant the audio quits being played by the sound card several things happen:
            1) The sound device notifies the OS of the buffer status (not playing)
            2) The polling algorithm detects a change in the buffer status which sends a PTT off command via TCPIP to the host program.
            3) The host program decodes the PTT OFF TCP command and determines (based on the setup) what to do. 
                a) Nothing for VOX (or audio keyed PTT like the SignaLink)
                b)  Change the Value of the DTR or RTS signal on a dedicated RS232 port if that keying option is used.
                c)   Send a “CAT” PTT OFF command if the setup is for a transceiver that supports PTT commands. (many but not all do).  This is usually via a serial port with some delay.
             
            So you see that the above must happen and in general none of this is instantaneous so they could be up to 100 ms or more delay and this adds to the T>R latency that is inherent to the radio (not trivial on some DSP based radios).  When the latency is measured (during a call) the time from 1) above to the reception of background receiver noise is measured. (which  also includes the Radio latency, inbound sound card latency and OS interrupt latency).  Those measurements are not super precise since the OS is not truly real-time but in general are repeatable to about 30 ms which is close enough.
             
            When the program measures the round trip time it uses a specific time windows (rather small...about 1500 ms) that it expects the ACK to be received this insures it measures from a specific PTT Release.  It will attempt a measurement on each connect request until it gets a good ACK decode and a time that fits into the expected window.  If the Round trip delay measurement is outside this window it won’t be used and a safe high value will be used (but the link will not run at optimum speed.  This works very well and as long as the user does not have substantial VOX delay set (or DLY on the SignaLink) it will work fine for almost all radios and sound card interfaces.
             
            The IRS<> ISS switchover is more complex.  It has to be interlocked so you don’t get two ISS or Two IRS at the same time....that will kill the link. Think of the ISS as the master...it always initiates the action and the IRS responds to the command.  In the changeover those roles have to be reversed. That can be very complex if the change over request, or ACK or both are missed (which happens fairly often on HF)  There is a mechanism which I described and is documented in the spec that usually is very reliable.  If both stations measure the latencies above it should be very solid. If one station is not calculating the latency or Round trip there could be issues with ISS<>IRS switchover.  But to analyze that I need the debug logs of both ends along with the information on your setup (how PTT keying is done etc). One important thing which is mentioned in the help is if using radio control (CAT PTT control) the baud rate should be 4800 or above...otherwise that can add substantial delay to the PTT key/release.
             
            I’ll be happy to take a look at the logs. (Send COMPLETE logs ...not snippets) as attachments.  I will be camping this weekend with my family so won’t have internet until Monday.
             
            73,
             
            Rick KN6KB
             
            Sent: Thursday, August 16, 2012 7:42 AM
            Subject: RE: [V4Protocol] ARQ protocols used over RF links
             
             

            Rick,

            Thanks for the informative response.   I have put a few of my comments into your text (in blue).

            73  Robin


            To: V4Protocol@yahoogroups.com
            From: rmuething@...
            Date: Wed, 15 Aug 2012 13:00:46 -0400
            Subject: Re: [V4Protocol] ARQ protocols used over RF links

             
             
            Robin,
            Some good questions...the answers are technical but I will try and summarize here.
            1) There is a limit on T>R latency (< 250 ms) to maintain some performance in the protocol. For example in Pactor this is typically on the order of 50 ms and is fixed by the hardware and radio.   Almost any computer and radio can make the 250 ms limit unless something incorrectly is set up ....like the PTT hold (DLY on the SignaLink) is set too high.
            Rick, I am sure you have done a thorough analysis on this.
            When PTT is released, all RF transmission ceases.  Practically no delay. Then the receiver recovers rapidly.
            But when PTT is activated, the carrier will be switched on and simultaneously the AFSK data modulation process is initiated. Although RF should stabilise rapidly, in practice, certain transceivers do seem take quite some time (personally, I suspect the problem lies with their ALC circuitry and a switch-on glitch). 
             
            2) The program measures upon the first ACK received (during the establishment of a connection) the nominal delay from the release of its PTT to the reception of the ACK. This include the R>T latency on the remote end and therefore this is automatically measured (again with a fairly generous limits) This is used (with some safety margin) to determine what delay the ISS uses before sending the next frame.
            So you keep on repeating the same frame (about every 5 seconds) until an ACK is received. But you don't know which frame it is acknowledging, and the roundtrip figure is based on the assumption that it IS the last sent frame?

             
            3) There is a fairly reliable and usually bullet proof way of IRS<>ISS changeover. If you are experience problems with this I need to see the debug log files from EACH end to make any analysis. There is a lot of information in the debug log along with timing measurement to 10 ms but you have to be intimately familiar with the code (and have the source in front of you) to be able to accurately interpret it.  EVERY half duplex ARQ mode has this issue when transitioning from ISS to IRS.  The goal is to have a completely bulletproof exchange under ALL combinations of missed requests and ACKs...it it generally not possible to reach perfection especially in very poor channels. The exchange of the IRS and ISS in V4 has been tested down to S/N of – 5 dB in poor multipath channels but as I said perfection is generally not possible.
             
            If you have detailed questions on the change over mechanism and states I will try and answer but looking at the text and diagrams in the V4 Protocol spec should be the best help.

            Thanks Rick,  I will prepare our logs and send you (off list) a more detailed description of our trials.

            S/N of > +30dB over a 3km path on 20 meters. The IRS<=>ISS switch-over hangup is reproducible. 


            73,
             
            Rick Muething, KN6KB
             
            From: Robin
            Sent: Wednesday, August 15, 2012 11:04 AM
            Subject: [V4Protocol] ARQ protocols used over RF links
             
             
            In all practical trials of V4Chat (1.0.4.0) I have performed, the protocol gets jammed owing to both stations continuously claiming ISS simultaneously! This should not be possible. I am having problems understanding how the mechanism used to swap IRS<=>ISS should work.
            Being a newcomer to this mode, can I put a beginners question to the group?
            There is a limit defined for the T>R latency, presumably to ensure the synchronisation of ACK/NAK responses after sending an ARQ frame. But what about the latency R>T of the partnering transmitter? This is not mentioned in the documentation.
            Suppose the answering transmitter (sending the ACK/NAK) takes a "long" time to initiate modulated RF after its PTT has been activated, surely this can also provoke problems? As far as I can see from the logs, the frames are not uniquely identified (un-numbered) so with extreme unbalanced latencies and timing, it could be possible to lose co-ordination between ARQ data frames and the related ACK/NAK.

            Appreciate any thoughts or comments from the experts.
            Robin, 9H1ZZ



            No virus found in this message.
            Checked by AVG - www.avg.com
            Version: 10.0.1424 / Virus Database: 2437/5202 - Release Date: 08/15/12

             

            No virus found in this message.
            Checked by AVG - www.avg.com
            Version: 10.0.1424 / Virus Database: 2437/5203 - Release Date: 08/15/12

          • William Calderwood
            Rick -        I had a V4 Chat QSO with David WB6JFHon 14.073 MHz today and noticed what appeared to be malformed data packets (i.e. not ACK/NAK s) from
            Message 5 of 5 , Sep 2, 2012
            • 0 Attachment
              Rick -

                     I had a V4 Chat QSO with David WB6JFHon 14.073 MHz today and noticed what appeared to be malformed data packets (i.e. not ACK/NAK's) from him.  The "malformed" phenomena I speak of is most of the energy was concentrated into the lowest tone frequency (though there was a slight amount in the higher tone frequencies).  No data was decoded from these packets.  I noticed it both in ARQ and FEC mode.  I've attached a screen shot of the phenomena.  I've attached a debug log.  One of the times I saw this occur was late in the minute of 1:40 pm PDT. 

                  I have not seen this reported before.  Sorry if this is old news.

                                                                                                                              73, Bill K1CT
               
            Your message has been successfully submitted and would be delivered to recipients shortly.