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

H4 Protocol spec for FEC and ARQ posted to V4Protocol files section.

Expand Messages
  • Rick Muething
    All, Many of us have heard the famous Abe Lincoln quote: Give me 6 hours to chop down a tree and I will spend the first 4 sharpening the axe. The same still
    Message 1 of 6 , Nov 27, 2013
    • 0 Attachment

      All,

       

      Many of us have heard the famous Abe Lincoln quote:

       

      “Give me 6 hours to chop down a tree and I will spend the first 4 sharpening the axe.”

       

       

      The same still holds pretty well for developing a protocol!

       

      I have made good progress on the H4 ARQ mode  …initially mostly in the protocol spec. I have uploaded this to the files section (pdf) for anyone interested or having trouble getting to sleep.  I have found that time spent  “sharpening the spec” is well spent and makes the coding faster and with fewer iterations.

       

      I am running  special (I don’t want to post these yet) Chat and H4FSK TNC test versions here that is sending both an FEC beacon and a new ARQ ID frame.  You should be able to see a clean (no funny characters caused by the CRC check) ARQ ID after my FEC beacon.  It is on 10123.0 USB dial and sends the short ARQ ID frame (“ARQ ID < KN6KB”)  a few seconds after the FEC beacon. Of course monitoring with FEC will not provide error checking or correction but it should be visible.  I have gone to some effort to insure that monitoring of ARQ sessions can be done in both ARQ and FEC modes with clean printouts.  This is all described in the “very interesting” spec.

       

      I suspect it will be at least a couple of weeks before a fully functions (with a few bugs of course!) ARQ version is ready for testing. This includes the provisions (as you can see in the spec)  for a second Reed-Solomon layer FEC on top of the Hamming encoding.  This is used on the Robust Text and BINARY frame types…it reduces the frame payload some but should improve the net throughput (after repeats) in poor conditions.  

       

      I’ll leave the beacon running today. I’m interested in how the ARQ ID frame “prints”.  

       

      Have a good Thanksgiving…

       

      73,


      Rick KN6KB

    • Kirk
      Rick, Thanks. Will read the H4 Protocol Spec and with regard to your 10.123 beacon, will report later. By the way, I have no problem sleeping but I do get up
      Message 2 of 6 , Nov 27, 2013
      • 0 Attachment

        Rick,

         

        Thanks.  Will read the H4 Protocol Spec and with regard to your 10.123 beacon, will report later.  By the way, I have no problem sleeping but I do get up early (0200) to get my 1.5 hour regiment of exercise out of the way.

         

        Have a super day and Happy Thanksgiving!

         

        Kirk, K6KAR

        Niceville, FL

         

        From: V4Protocol@yahoogroups.com [mailto:V4Protocol@yahoogroups.com] On Behalf Of Rick Muething
        Sent: Wednesday, November 27, 2013 6:05 AM
        To: V4Protocol@yahoogroups.com
        Subject: [V4Protocol] H4 Protocol spec for FEC and ARQ posted to V4Protocol files section.

         

         

        All,

         

        Many of us have heard the famous Abe Lincoln quote:

         

        “Give me 6 hours to chop down a tree and I will spend the first 4 sharpening the axe.”

         

         

        The same still holds pretty well for developing a protocol!

         

        I have made good progress on the H4 ARQ mode  …initially mostly in the protocol spec. I have uploaded this to the files section (pdf) for anyone interested or having trouble getting to sleep.  I have found that time spent  “sharpening the spec” is well spent and makes the coding faster and with fewer iterations.

         

        I am running  special (I don’t want to post these yet) Chat and H4FSK TNC test versions here that is sending both an FEC beacon and a new ARQ ID frame.  You should be able to see a clean (no funny characters caused by the CRC check) ARQ ID after my FEC beacon.  It is on 10123.0 USB dial and sends the short ARQ ID frame (“ARQ ID < KN6KB”)  a few seconds after the FEC beacon. Of course monitoring with FEC will not provide error checking or correction but it should be visible.  I have gone to some effort to insure that monitoring of ARQ sessions can be done in both ARQ and FEC modes with clean printouts.  This is all described in the “very interesting” spec.

         

        I suspect it will be at least a couple of weeks before a fully functions (with a few bugs of course!) ARQ version is ready for testing. This includes the provisions (as you can see in the spec)  for a second Reed-Solomon layer FEC on top of the Hamming encoding.  This is used on the Robust Text and BINARY frame types…it reduces the frame payload some but should improve the net throughput (after repeats) in poor conditions.  

         

        I’ll leave the beacon running today. I’m interested in how the ARQ ID frame “prints”.  

         

        Have a good Thanksgiving…

         

        73,


        Rick KN6KB

      • Ron Wenig
        Rick, here s a screen shot of 2 of your beacons. The stuff before your beacon is just noise that got through. I was wondering why the start of beacon
        Message 3 of 6 , Nov 27, 2013
        • 0 Attachment
          Rick,  here's a screen shot of 2 of your beacons.  The stuff before your beacon is just noise that got through.  I was wondering why the start of beacon doesn't start on a new line.  Also, what is the 1/4 at the end of the beacon.

          73, Ron ny3j




          On 11/27/2013 6:04 AM, Rick Muething wrote:
           

          All,

           

          Many of us have heard the famous Abe Lincoln quote:

           

          “Give me 6 hours to chop down a tree and I will spend the first 4 sharpening the axe.”

           

           

          The same still holds pretty well for developing a protocol!

           

          I have made good progress on the H4 ARQ mode  …initially mostly in the protocol spec. I have uploaded this to the files section (pdf) for anyone interested or having trouble getting to sleep.  I have found that time spent  “sharpening the spec” is well spent and makes the coding faster and with fewer iterations.

           

          I am running  special (I don’t want to post these yet) Chat and H4FSK TNC test versions here that is sending both an FEC beacon and a new ARQ ID frame.  You should be able to see a clean (no funny characters caused by the CRC check) ARQ ID after my FEC beacon.  It is on 10123.0 USB dial and sends the short ARQ ID frame (“ARQ ID < KN6KB”)  a few seconds after the FEC beacon. Of course monitoring with FEC will not provide error checking or correction but it should be visible.  I have gone to some effort to insure that monitoring of ARQ sessions can be done in both ARQ and FEC modes with clean printouts.  This is all described in the “very interesting” spec.

           

          I suspect it will be at least a couple of weeks before a fully functions (with a few bugs of course!) ARQ version is ready for testing. This includes the provisions (as you can see in the spec)  for a second Reed-Solomon layer FEC on top of the Hamming encoding.  This is used on the Robust Text and BINARY frame types…it reduces the frame payload some but should improve the net throughput (after repeats) in poor conditions.  

           

          I’ll leave the beacon running today. I’m interested in how the ARQ ID frame “prints”.  

           

          Have a good Thanksgiving…

           

          73,


          Rick KN6KB



        • Rick Muething
          Ron, There are two things that are interesting. 1) The ╝ at the end of the ARQ ID is due to the CRC byte which actually should be suppressed since it is
          Message 4 of 6 , Nov 27, 2013
          • 0 Attachment

            Ron,

             

            There are two things that are interesting. 

             

            1)      The ¼ at the end of the ARQ ID is due to the CRC byte which actually should be suppressed since it is preceded by an End of Transmission…I’ll have to check that out.  Of course in ARQ mode everything will be hidden unless it passes the CRC check sum.

             

            2)      The scalloping on your  decode quality graph indicates possible large error in your sample rate.  On the H4 TNC (after it has been running for several minutes) click  Help and note the SR number at the bottom of the drop down. It should be fairly close ( +/12 or better) to 12000. If it is far off your sound card has some significant error.  It will still decode but can’t be fully compensated.  Let me know what you read for the SR value….(be sure and let it run…the longer it runs the more accurate the reading)

             

            3)      The receive level looks low.  With the receiver AGC on (medium to fast) it should be at least 50% of full scale.  It looks like it is only half way on the blue scale which means you are using something like 8-9 bits of your sound cards A/D.  That hurts the decoding accuracy and sensitivity.  Shoot for at least mid scale or better  and “in the green”).  You set this with:

             

            a.       The radio aux or speaker/phone output level (sometimes this is adjustable)

            b.      The pot and/or jumpers in the sound card interface. (e.g. the SignaLink has both an internal jumper and a RX pot.)

            c.       The windows mixer record level (if the sound card  driver uses the windows Mixer. ) You can check this with  Start, Control panel, Sounds and selecting the card and record level that you are using for the radio.

             

             

            Thanks for the feedback….It shows the ARQ ID is working but that ¼ should be suppressed.  I’ll find that this afternoon.

             

            73,

             

            Rick

             

            From: V4Protocol@yahoogroups.com [mailto:V4Protocol@yahoogroups.com] On Behalf Of Ron Wenig
            Sent: Wednesday, November 27, 2013 7:09 AM
            To: V4Protocol@yahoogroups.com
            Subject: Re: [V4Protocol] H4 Protocol spec for FEC and ARQ posted to V4Protocol files section.

             

            Rick,  here's a screen shot of 2 of your beacons.  The stuff before your beacon is just noise that got through.  I was wondering why the start of beacon doesn't start on a new line.  Also, what is the 1/4 at the end of the beacon.

            73, Ron ny3j


            On 11/27/2013 6:04 AM, Rick Muething wrote:

             

            All,

             

            Many of us have heard the famous Abe Lincoln quote:

             

            “Give me 6 hours to chop down a tree and I will spend the first 4 sharpening the axe.”

             

             

            The same still holds pretty well for developing a protocol!

             

            I have made good progress on the H4 ARQ mode  …initially mostly in the protocol spec. I have uploaded this to the files section (pdf) for anyone interested or having trouble getting to sleep.  I have found that time spent  “sharpening the spec” is well spent and makes the coding faster and with fewer iterations.

             

            I am running  special (I don’t want to post these yet) Chat and H4FSK TNC test versions here that is sending both an FEC beacon and a new ARQ ID frame.  You should be able to see a clean (no funny characters caused by the CRC check) ARQ ID after my FEC beacon.  It is on 10123.0 USB dial and sends the short ARQ ID frame (“ARQ ID < KN6KB”)  a few seconds after the FEC beacon. Of course monitoring with FEC will not provide error checking or correction but it should be visible.  I have gone to some effort to insure that monitoring of ARQ sessions can be done in both ARQ and FEC modes with clean printouts.  This is all described in the “very interesting” spec.

             

            I suspect it will be at least a couple of weeks before a fully functions (with a few bugs of course!) ARQ version is ready for testing. This includes the provisions (as you can see in the spec)  for a second Reed-Solomon layer FEC on top of the Hamming encoding.  This is used on the Robust Text and BINARY frame types…it reduces the frame payload some but should improve the net throughput (after repeats) in poor conditions.  

             

            I’ll leave the beacon running today. I’m interested in how the ARQ ID frame “prints”.  

             

            Have a good Thanksgiving…

             

            73,


            Rick KN6KB

             

             

          • Rick Muething
            Ron, All, Thanks to Ron s feedback I found the bug that was not blanking out the CRC check byte from displaying in the ARQ ID frame.A simple fix which I have
            Message 5 of 6 , Nov 27, 2013
            • 0 Attachment

              Ron, All,

               

              Thanks to Ron’s feedback I found the bug that was not blanking out the CRC check byte from displaying in the ARQ ID frame…A simple fix which I have operating now.   The concept is fairly simple …only adds one byte (128 ms) to these frame:   A End of Transmission (Hex 04) is inserted just before the CRC check sum…  The Check sum byte (which can be any 8 bit value based on the data) is then “hidden” since the station in FEC mode sees a EndOfTransmission character directly in front of the CRC byte.  That EOT forces a monitor in FEC mode to stop processing characters so the CRC character  is not shown.  This should all work OK now.   Stations using ARQ have a more complex capture, decode and display mechanism so can decode and compute the CRC check and basically ignore the EOT in the ARQ ID frame.

               

              The only frame that this won’t work for is the ARQ BINARY frame since by definition the Binary frame can include any of the 8 bit values and these may “print” in strange ways on a station monitoring in FEC mode.  But pure BINARY data will always print funny since it contains all available 8 bit values.

               

              73,

               

              Rick KN6KB

            • Ron Wenig
              Rick, I increased the USB output on the TS-590 and now the Rcv level is 1/2 way. The average SR reads 11999.90 so it s pretty close to 12000 and the Decode
              Message 6 of 6 , Nov 27, 2013
              • 0 Attachment

                Rick, I increased the USB output on the TS-590 and now the Rcv level is 1/2 way.  The average SR reads 11999.90 so it's pretty close to 12000 and the Decode Quality line is almost a straight line.  The CRC check sum (1/4) is not showing up now with your fix.  That was an interesting bug.

                Ron ny3j

                On 11/27/2013 11:49 AM, Rick Muething wrote:
                 

                Ron,

                 

                There are two things that are interesting. 

                 

                1)      The ¼ at the end of the ARQ ID is due to the CRC byte which actually should be suppressed since it is preceded by an End of Transmission…I’ll have to check that out.  Of course in ARQ mode everything will be hidden unless it passes the CRC check sum.

                 

                2)      The scalloping on your  decode quality graph indicates possible large error in your sample rate.  On the H4 TNC (after it has been running for several minutes) click  Help and note the SR number at the bottom of the drop down. It should be fairly close ( +/12 or better) to 12000. If it is far off your sound card has some significant error.  It will still decode but can’t be fully compensated.  Let me know what you read for the SR value….(be sure and let it run…the longer it runs the more accurate the reading)

                 

                3)      The receive level looks low.  With the receiver AGC on (medium to fast) it should be at least 50% of full scale.  It looks like it is only half way on the blue scale which means you are using something like 8-9 bits of your sound cards A/D.  That hurts the decoding accuracy and sensitivity.  Shoot for at least mid scale or better  and “in the green”).  You set this with:

                 

                a.       The radio aux or speaker/phone output level (sometimes this is adjustable)

                b.      The pot and/or jumpers in the sound card interface. (e.g. the SignaLink has both an internal jumper and a RX pot.)

                c.       The windows mixer record level (if the sound card  driver uses the windows Mixer. ) You can check this with  Start, Control panel, Sounds and selecting the card and record level that you are using for the radio.

                 

                 

                Thanks for the feedback….It shows the ARQ ID is working but that ¼ should be suppressed.  I’ll find that this afternoon.

                 

                73,

                 

                Rick

                 



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