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

1777Re: [V4Protocol] Re: V4 GUI improvement proposal

Expand Messages
  • Ron Werthman
    Sep 6, 2011
    • 0 Attachment
      Well it sounded good in my head.  I should have known better. With all the time you have invested in V4 you must have tried all the tricks.  Excellent explanation of the process, thanks for that.  I think I have a better understanding of v4 now.

      From: Rick Muething <rmuething@...>
      To: V4Protocol@yahoogroups.com
      Sent: Tuesday, September 6, 2011 9:54:45 AM
      Subject: Re: [V4Protocol] Re: V4 GUI improvement proposal

      You’re trying to circumvent the “no free lunch” theorem!....Everything has a cost.  If you send data back with the ACK you HALF the throughput (data takes time ~3+ seconds, ACK/NAK take very little time ~300 ms).   The ISS has to know how long to wait to repeat so if the IRS can optionally  send data the ISS must wait to see if that is happening or you get “doubles”.
      Now you CAN send more data in less time by: (the theory for this is well known and proven)
      1) Increasing the bandwidth (now 200 Hz, and can go into any spot on the band) You would have to increase the power proportionally to keep the same S/N ratio and bit error rate of course. And of course you get fewer QSO’s per KHz. (You can thank Claude Shannon for that channel capacity vs. S/N theory that is so often quoted!)
      2) Increasing the bits/symbol (now 2 including 1 FEC bit)  e.g. PSK can send more than 2 bits/symbol but requires a stronger signal to keep the bit error rate the same. 4FSK is near optimum in terms of bandwidth and robustness especially in multipath propagation.
      3) You can decrease the FEC coding (now at 50%) but that increases the bit error rate (and repeats) unless the signals are strong (The current V4 Viterbi encoding probably yields a coding gain of something >  than 3 dB so you would have to more than double the power to keep the same bit error rate)
      And then there is the real problem....How do you manage two data senders in a half duplex ARQ environment? ...virtually all half duplex HF protocols use an IRS ISS concept...and it is very difficult (under all missed frames, missed data and missed ACKs situations) to insure both stations don’t ever become the ISS or the IRS at the same time.
      Maybe I have missed something but I don’t know how to make it more straight forward:
      You can type and enter data at ANY Time.... You don’t have to wait for anything. You never HAVE to send over or break or anything but typed text.
      When the current sending station ISS runs out of data (all outbound data has been confirmed received) he Automatically sends IDLs
      If the Current Receiving station has data to send (queued) and sees an IDL from the ISS it automatically starts the IRS>ISS switchover sequence to become the new ISS.
      Rick KN6KB

    • Show all 30 messages in this topic