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

Re: [V4Protocol] ARQ & FEC

Expand Messages
  • Jack Swift
    my off the cuff opinion is that in FEC you get good packets , bad packets, and half-whatever packets.... that s why you get the red stuff . AND when you re
    Message 1 of 8 , Nov 3, 2011
    • 0 Attachment
      my 'off the cuff' opinion is that in FEC you get good packets , bad
      packets, and half-whatever packets....
      that's why you get the 'red stuff'. AND when you're monitoring someone
      else, you are, in effect, using/viewing FEC because you are not a
      'connected' part of the conversation.

      BUT when you are one of the 2 (no more, no less) connected stations in
      ARQ, mode there is no such thing as a bad packet -- your partner will
      keep resending the offending packet until you acknowledge it as being
      'perfect' - and you will do the same for him..

      that wonderful feature of ARQ is why someone monitoring might see
      duplicate sentence fragments.

      On Thu, Nov 3, 2011 at 7:11 PM, Paul Whitaker <dromana@...> wrote:
      >
      >
      >
      > Hi all,
      > I am observing an interesting situation - I leave my system running on
      > 14073 overnight ARQ, and it usually shows a number of CQ's or actual connects.
      > The CQ's are ALWAYS well formed - no errors etc.
      > But when a connect between two other stations happens, there is usually a
      > LOT of crossed out red text, with some decoded correctly.
      > I would think that the CQ is a FEC mode - and when connected, it is ARQ
      > 'Chat' with error correction. My station is not synchronized
      > in that case, so I thought it would only be as good as FEC - but FEC is far
      > better.
      > Further, I have tried on a number of occasions to conduct a FEC 'Net', but
      > very poor results. (usually on noisy 80 mtr)
      >
      > Just observing. I would have thought the monitoring would have been as good
      > as the FEC CQ call !
      >
      > Anyone notice this ?
      >
      > Paul Whitaker.
      > VK3DPW
      >
      >
      >
      > ------------------------------------
      >
      > Yahoo! Groups Links
      >
      >
      >
      >



      --
      vvvvvvvvvvvvvvvvvvvvvvvv
      Jack Swift, N8WAV
      Houghton County ARES/RACES EC/RO
      105 E. Douglass Ave.
      Houghton, MI 49931
      906-281-5300
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    • John Elliott
      I m currentlyn listening on 14073mhz if anybody is around (01:25gmt) Regards John Elliott
      Message 2 of 8 , Nov 3, 2011
      • 0 Attachment
        I'm currentlyn  listening on 14073mhz if anybody is around (01:25gmt)

        Regards
        John Elliott

      • Ian Branch
        ... Yes. I thought it was just me. Ian. VK3YEA ___________________________________
        Message 3 of 8 , Nov 3, 2011
        • 0 Attachment
          >> Anyone notice this ?

          Yes. I thought it was just me.

          Ian.
          VK3YEA



          ___________________________________
        • Paul Whitaker
          Hi Jack, Yes, I understand that. Its just that I would expect to see repeats, as you mention, but apart from the CQ call or Connect, its mostly red. And yes, I
          Message 4 of 8 , Nov 3, 2011
          • 0 Attachment
            Hi Jack,
            Yes, I understand that.
            Its just that I would expect to see repeats, as you mention, but apart from
            the CQ call or Connect, its mostly red.
            And yes, I agree about mistakes without the ability to ask for repeat - but
            it would seem that there is something more
            stable about the FEC CQ or Connect, to my system, compared to the ARQ Chat,
            or even the FEC Nets we have tried to run.

            Just an observation - donent make sense !

            The Auto update is working perfectly, and we have had quite a few ARQ chats
            with great success.
            Thanks for the work Rick - My Hat off to you and others that can work magic
            with the keyboard !

            '73
            Paul Whitaker.
            VK3DPW






            From: "Jack Swift" <n8wavjack@...>
            At 11:20 AM 04/11/2011, you wrote:
            >
            >
            >my 'off the cuff' opinion is that in FEC you get good packets , bad
            >packets, and half-whatever packets....
            >that's why you get the 'red stuff'. AND when you're monitoring someone
            >else, you are, in effect, using/viewing FEC because you are not a
            >'connected' part of the conversation.
            >
            >BUT when you are one of the 2 (no more, no less) connected stations in
            >ARQ, mode there is no such thing as a bad packet -- your partner will
            >keep resending the offending packet until you acknowledge it as being
            >'perfect' - and you will do the same for him..
            >
            >that wonderful feature of ARQ is why someone monitoring might see
            >duplicate sentence fragments.
          • John Hirth
            I ve noticed marginal copy at times too, when monitoring other ARQ QSOs. One thing I ve noticed is that V4Chat often starts to decode the frames that are ACKs
            Message 5 of 8 , Nov 4, 2011
            • 0 Attachment
              I've noticed marginal copy at times too, when monitoring other ARQ QSOs.

              One thing I've noticed is that V4Chat often starts to decode the frames that are ACKs or NAKs (the short frames) but doesn't seem to get back into the "ready" mode in time to catch the leader of the other station's data frame. So some of the data frames are lost, even if the station sounds "good". Now my computer is just a rather old 1.4GHz Pentium M with 2GB or memory, so I'm sure that it's now slower than most and probably explains what I'm seeing.

              I'm not sure if this goes to the heart of your comment, but I just thought I'd drop it in as food for thought.

              73, John W2KI
              -----------
              On 11/3/2011 7:11 PM, Paul Whitaker wrote:
               



              Hi all,
              I am observing an interesting situation - I leave my system running on
              14073 overnight ARQ, and it usually shows a number of CQ's or actual connects.
              The CQ's are ALWAYS well formed - no errors etc.
              But when a connect between two other stations happens, there is usually a
              LOT of crossed out red text, with some decoded correctly.
              I would think that the CQ is a FEC mode - and when connected, it is ARQ
              'Chat' with error correction. My station is not synchronized
              in that case, so I thought it would only be as good as FEC - but FEC is far
              better.
              Further, I have tried on a number of occasions to conduct a FEC 'Net', but
              very poor results. (usually on noisy 80 mtr)

              Just observing. I would have thought the monitoring would have been as good
              as the FEC CQ call !

              Anyone notice this ?

              Paul Whitaker.
              VK3DPW


            • Rick Muething
              John, There is a mechanism that has been in V4Chat and V4 TNC since the beginning called the debug log. If you enable it very accurate time tags (to 10 ms) are
              Message 6 of 8 , Nov 4, 2011
              • 0 Attachment
                John,
                 
                There is a mechanism that has been in V4Chat and V4 TNC since the beginning called the debug log. If you enable it very accurate time tags (to 10 ms) are logged at key points in the V4 TNC program. This all was and is  there to aid in debugging and optimization and has been invaluable in tracking down real problems and also in finding “setup” or “cockpit” problems in the protocol. 
                 
                I seriously doubt there is any timing problem with a 1.4 GHz computer and 2 G of memory...V4 is successfully running on much slower machines than that and there is considerable decoding margin built into the timing.  But in any case the REAL mechanism for locating if it is a problem and where it might be always comes down to the following:
                1) Enable the debug log
                2) Describe as best as possible the problem observed and the exact time (UTC as close as possible) it was observed.
                3) Include the log as an attachment to and send to me...in some cases both ends of the session may be required which is a bit more difficult but possible.
                 
                This is practically the ONLY way improvement can be made and has resulted in continual and dramatic improvements in the V4 Protocol and V4 Chat over the past 11 months or so.  Debugging or optimizing the performance of a protocol is not some thing than can be done by guess work or casual observations.
                 
                73,

                Rick KN6KB
                 
                 
                Sent: Friday, November 04, 2011 4:02 PM
                Subject: Re: [V4Protocol] ARQ & FEC
                 
                 

                I've noticed marginal copy at times too, when monitoring other ARQ QSOs.

                One thing I've noticed is that V4Chat often starts to decode the frames that are ACKs or NAKs (the short frames) but doesn't seem to get back into the "ready" mode in time to catch the leader of the other station's data frame. So some of the data frames are lost, even if the station sounds "good". Now my computer is just a rather old 1.4GHz Pentium M with 2GB or memory, so I'm sure that it's now slower than most and probably explains what I'm seeing.

                I'm not sure if this goes to the heart of your comment, but I just thought I'd drop it in as food for thought.

                73, John W2KI
                -----------
                On 11/3/2011 7:11 PM, Paul Whitaker wrote:

                 



                Hi all,
                I am observing an interesting situation - I leave my system running on
                14073 overnight ARQ, and it usually shows a number of CQ's or actual connects.
                The CQ's are ALWAYS well formed - no errors etc.
                But when a connect between two other stations happens, there is usually a
                LOT of crossed out red text, with some decoded correctly.
                I would think that the CQ is a FEC mode - and when connected, it is ARQ
                'Chat' with error correction. My station is not synchronized
                in that case, so I thought it would only be as good as FEC - but FEC is far
                better.
                Further, I have tried on a number of occasions to conduct a FEC 'Net', but
                very poor results. (usually on noisy 80 mtr)

                Just observing. I would have thought the monitoring would have been as good
                as the FEC CQ call !

                Anyone notice this ?

                Paul Whitaker.
                VK3DPW


              • John Hirth
                Hi Rick, Thanks for the reminder of how to send you information of use to you in debugging a situation .  I ve used it to send several sets of logs to you as
                Message 7 of 8 , Nov 4, 2011
                • 0 Attachment
                  Hi Rick,

                  Thanks for the reminder of how to send you information of use to you in debugging a "situation".  I've used it to send several sets of logs to you as I've encountered past problems. Monitoring established ARQ QSOs, while interesting and I do use it, is not of high value in my type of operating. I've never thought this was anywhere near enough of an issue to warrant reporting, as V4Chat works very well for me in ARQ QSOs.

                  Thanks again for all your work!
                  73, John W2KI
                  -----
                  On 11/4/2011 4:23 PM, Rick Muething wrote:
                   

                  John,
                   
                  There is a mechanism that has been in V4Chat and V4 TNC since the beginning called the debug log. If you enable it very accurate time tags (to 10 ms) are logged at key points in the V4 TNC program. This all was and is  there to aid in debugging and optimization and has been invaluable in tracking down real problems and also in finding “setup” or “cockpit” problems in the protocol. 
                   
                  I seriously doubt there is any timing problem with a 1.4 GHz computer and 2 G of memory...V4 is successfully running on much slower machines than that and there is considerable decoding margin built into the timing.  But in any case the REAL mechanism for locating if it is a problem and where it might be always comes down to the following:
                  1) Enable the debug log
                  2) Describe as best as possible the problem observed and the exact time (UTC as close as possible) it was observed.
                  3) Include the log as an attachment to and send to me...in some cases both ends of the session may be required which is a bit more difficult but possible.
                   
                  This is practically the ONLY way improvement can be made and has resulted in continual and dramatic improvements in the V4 Protocol and V4 Chat over the past 11 months or so.  Debugging or optimizing the performance of a protocol is not some thing than can be done by guess work or casual observations.
                   
                  73,

                  Rick KN6KB


                Your message has been successfully submitted and would be delivered to recipients shortly.