Re: [linuxham] Re: New jpskmail client for windows and linux adds HF APRS and ARQ capability to Fldigi.
- On Mar 24, 2009, at 12:38 PM, Rick W wrote:
> Brian,Therefore the error detection needs to be *very* robust. Simple parity
> 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
> and would start to false data. This really messed things up when
> to connect and send commands to a BBS such as the Aplink System since
> sometimes it would receive incorrect commands, etc.
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. ofIn many cases that is true. Problems arise in stop-and-wait protocols
> changes a great deal on HF, therefore the only possible solution for
> best systems approach is one that operates adaptively. Certain kinds
> 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
at any layer.
> It is interesting that some of your suggestions are exactly whatThat would be very interesting. We could certainly use better
> appears to be using. It will have several levels of adaptive PSK and
> modulation at 62.5 baud, and also a slower 31.25 baud rate using 4FSK
> modulation. At least one additional modulation is being considered
> may use training pulses.
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, whileI have used PACTOR extensively. (I lived on a boat at sea for quite
> slower than Pactor 3, in most cases, might actually work better if ISI
> and Doppler exceed the capabilities of Pactor modes. Since Pactor 2
> 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.
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 beThat would be interesting.
> used in other programs.
73 de Brian, WB6RQN/J79BPL
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