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

Re: [V4Protocol] ARQ & FEC

Expand Messages
  • 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 1 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 2 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.