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/
