Chris,
There are several amateur radio to e-mail systems available now and they
all use ARQ.
For sending a shared resource, such as is done all the time on SSTV, the
stations are often using WinDream or Hampal which allow you to send out
replacements for bad segments. It can be time consuming, but it will
allow for perfect copy on the receiving end without repeating the entire
data stream.
The timing issue for ARQ has been solved for the PC side. And most any
rig would be able to handle it easily. The one exception was Amtor and
that is pretty much obsolete as an ARQ mode as it only transmitted three
characters on each "chirp."
73,
Rick, KV9U
Chris Jewell wrote:
>KV9U writes:
>
> > If you want to "broadcast" a message from one to many, then the only
> > practical alternative is to use a non-ARQ mode, typically with a large
> > amount of FEC. While this is done on amateur frequencies for sending a
> > bulletin, calling CQ, and having a roundtable, if your goal is to have
> > accurate messaging, then I don't see any option other than a good ARQ
> > system.
>
>A protocol for sending email messages over HF could have the
>following behavior:
>
>1. Sending station sends the message in packets of a specified or
> negotiated size.
>
>2. Each packet begins and ends with reserved control characters
> and is followed with a CRC-16 of the packet.
>
>3. Receiving station keeps track of which packets were received with
> good CRC and which were garbled.
>
>4. Upon receiving end-of-message, or at a pause after a defined or
> negotiated number of bytes or packets have been sent, the
> receiving station acknowledges all, or all up to a certain packet,
> or requests repeats of those packets which were received in error.
> It sends a complete ack only after all the packets have been
> received successfully.
>
>5. The sending station resends the failed packets then continues with
> send further packets of this message, or starts the next message
> using a higher packet number, or whatever.
>
>This is analogous to CW/voice traffic handling, where the receiving
>station either acknowledges receipt or sends "?wa", "?aa", "say
>again {word|all} after", or the like.
>
>This suggestion has at least one disadvantage compared to ARQ modes:
>the sending station does NOT get feedback after each packet telling it
>that it can switch to a faster and less robust submode, or that it
>should switch to a slower and more-robust one. Therefore, it may take
>longer than necessary to get the message through, whether due to
>repetitions that wouldn't have been necessary with prompt feedback, or
>by sending more slowly than necessary. On the other hand, it
>eliminates the ACK turnaround timing problems that prevent both some
>radios and some PC OSes from working well for ARQ comms.
>
>In essence, we are moving the reliability issue from the transport
>layer to the application layer. Such an email system could sit on top
>of anything from unchecked BPSK31 to FEC'ed MFSK-16 or MT-63, though
>of course many more retransmissions would be needed with the former
>than with the latter. Our choice of mode may depend partly on the
>band, BPSK-31, -63, or even -125 on 20M meters and up, but MFSK16 or
>MT63 on 160, 80, and 40, for example.
>
>It might be better to establish a separate layer between transport and
>application that could be shared by applications such as email, SSTV,
>and file transfer.
>
>This is a very old idea: IP sends packets which may get lost; TCP uses
>IP but retries until the data gets through, or gives up and tells the
>application layer that it failed; SMTP uses TCP's reliable data stream
>to deliver email. It's just that a reliable delivery layer for
>half-duplex HF radio is quite different from one for a full-duplex
>terrestrial WAN or a full-duplex satellite relay, or even PTP which
>carries TCP/IP, IPX, etc over landline modems or ISDN. Between half
>duplex with longish turnarounds, and such "joys" as QSB and QRN, the
>HF case is much more challenging.
>
>I'm sure that other hams are working on such ideas already, and we may
>be able to borrow techniques developed for commercial or military HF
>datacomm at small or no monetary cost. PCALE and Open5066 are
>examples, though I don't yet know much about the latter, and so have
>no opinion as to whether it will prove fit for ham use. Obviously,
>the people working on it think it is, and they know much more about it
>than I, so I'm hopeful.
>
>--
>73 DE AE6VW Chris Jewell Gualala, CA, USA
>
>
>
Need a Digital mode QSO? Connect to Telnet://cluster.dynalias.org
Other areas of interest:
The MixW Reflector : http://groups.yahoo.com/group/themixwgroup/
DigiPol: http://groups.yahoo.com/group/Digipol (band plan policy discussion)
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/digitalradio/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
