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

Re: [linuxham] Re: New jpskmail client for windows and linux adds HF APRS and ARQ capability to Fldigi.

Expand Messages
  • Brian Lloyd
    ... Therefore the error detection needs to be *very* robust. Simple parity checking schemes aren t good enough. That may be more important than ARQ. If the
    Message 1 of 7 , Mar 25 9:12 AM
    • 0 Attachment
      On Mar 24, 2009, at 12:38 PM, Rick W wrote:

      > Brian,
      >
      > You are right on target as I have been pointing this out for some
      > time. HI.
      >
      > For BBS or messaging systems it has to be ARQ. Even when I used Amtor
      > many years ago, the ARQ was not that good when conditions got
      > difficult
      > and would start to false data. This really messed things up when
      > trying
      > to connect and send commands to a BBS such as the Aplink System since
      > sometimes it would receive incorrect commands, etc.

      Therefore the error detection needs to be *very* robust. Simple parity
      checking schemes aren't good enough. That may be more important than
      ARQ. If the command frame has an error, toss it. If you don't get an
      acknowledgement from the server you need to resubmit your request.

      > The optimum balance of baud rate, data rate, robustness, etc. of
      > course
      > changes a great deal on HF, therefore the only possible solution for
      > the
      > best systems approach is one that operates adaptively. Certain kinds
      > of
      > technology has shown that there does not have to be a major hit on
      > throughput when using ARQ modes that have pipelined ARQ where the
      > calculations are kept one packet behind the incoming data. There is
      > increased latency, but that may not matter too much with good
      > throughput.

      In many cases that is true. Problems arise in stop-and-wait protocols
      at any layer.

      > It is interesting that some of your suggestions are exactly what
      > WINMOR
      > appears to be using. It will have several levels of adaptive PSK and
      > QAM
      > modulation at 62.5 baud, and also a slower 31.25 baud rate using 4FSK
      > modulation. At least one additional modulation is being considered
      > that
      > may use training pulses.

      That would be very interesting. We could certainly use better
      qualification of the HF medium. I suspect that the military has a lot
      of good info in this area. And it may be out there but I just don't
      know about it.

      > Depending upon the conditions, it may be possible that WINMOR, while
      > slower than Pactor 3, in most cases, might actually work better if ISI
      > and Doppler exceed the capabilities of Pactor modes. Since Pactor 2
      > and
      > 3 are at a fixed 100 baud rate, and do not use training pulses, I
      > suspect there are times that it just will not work but the users don't
      > even realize it since they can not make a connection.

      I have used PACTOR extensively. (I lived on a boat at sea for quite
      some time. Winlink and SailMail were how I did email.) I was aware of
      how PACTOR did or did not work. It does extraordinarily well near the
      MUF where multipath is minimized. I found the trick to be to pick the
      server that was one hop away when near the MUF. Regardless, so far I
      haven't seen anything better.

      > Since WINMOR is an open source protocol, maybe it will eventually be
      > used in other programs.

      That would be interesting.

      73 de Brian, WB6RQN/J79BPL

      Brian Lloyd
      Granite Bay Montessori School 9330 Sierra College Bl
      brian AT gbmontessori DOT com Roseville, CA 95661
      +1.916.367.2131 (voice) +1.791.912.8170 (fax)

      PGP key ID: 12095C52A32A1B6C
      PGP key fingerprint: 3B1D BA11 4913 3254 B6E0 CC09 1209 5C52 A32A 1B6C
    Your message has been successfully submitted and would be delivered to recipients shortly.