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

3700RE: [V4Protocol] H4 Protocol spec for FEC and ARQ posted to V4Protocol files section.

Expand Messages
  • Rick Muething
    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

       

       

    • Show all 6 messages in this topic