For wide–area nets and message transfers, there are few situations where a peer–to–peer (P2P) exclusive connection is needed. However, for many, many local and regional nets or groups, it is not uncommon, and may be appropriate for two stations to send data between themselves error–free. For instance a field commander may want to get a situation report from a satellite station at a shelter or feeding location. It is not necessary for all stations in the area to receive the message…just the commander.
When file transfer between only two stations is required, the use of a synchronous mode known as ARQ (see the explanation earlier) is not only appropriate, but desireable. ARQ provides a few benefits and more than a few disadvantages.
First, ARQ works by way of two stations (nodes) exchanging a series of information and data packets to get a “connection” established. Once “connected” further data is sent in known block sizes and each block is checked for integrety. In this way, ARQ attempts to make 100% error–free data exchange possible.
Such an exchange of data blocks received, checked, and acknowledged, injects a considerable amount of overhead to data transfer. As a matter of practicality, ARQ is three times less efficient than, using FLAMP for instance, to send the same message error–free. The distinct disadvantage using FLAMP is that it is not a direct peer–2–peer transmission. Anyone on frequency that has FLAMP may received the message.
Another consideration is the absolute requirement of a wired interface from computer to radio. ARQ cannot be used with the so called “Acoustical Coupling”. The reason is that the ARQ protocol controls the PTT…not the soundcard. It would be too hard to anticipate when to key the transmitter manually or when to release it.
Add to that the fact that some modes (namely MT-63 and OLIVIA) definitely do not work with ARQ. That is not a deficiency of the mode but a operating querk of those particular modes.
When using FLAMP and modes that do support ARQ, careful choice of block size become important so as to maximize efficiency and shorten transmit times. Too large a block may make transmissions too long and introduce the possibility of introducing errors from noise or fading. Too short, and message transfer time is lengthened due to the overhead of excessive number of blocks that have to be transmitted and acknowledged and / or re-transmitted.
The choice of data block size becomes important for files over 2K. When setting up FLARQ it is necessary to select a block size that is both efficient and appropriate for channel conditions. The higher the noise level, the smaller the block size (generally speaking) to avoid high numbers of NAKs during transmission.
It should be also noted that transmission of strictly binary files or data should be avoided in general on HF. ARQ does not lend itself to large binary data being transfered without error nor in short data exchanges. Non–error–correcting modes such as PSK–32 should always be avoided. Opt instead for the multi–carrier forward error–correcting modes like 8PSK125R (the R suffix indicates redundency for FEC).
The PSK modes introduce another inefficency into the mix. PSK modes use a Varicode encoding scheme to improve signal efficiency. Varicode is an encoding scheme that converts alpanumeric characters to binary before sending. The binary characters may be more efficient to send, but they are also much more vulnerable to noise since a bit error of only one bit causes an incorrect data reception. Varicode is also very unfriendly where most text or data compression is used. Again, only one bit being wrong causes data errors. On top of that, the saving due to compression of data is minimal compared to plain text.
Lets say station A wants to “connect” with station B nearby and transfer a file. When FLARQ is configured correctly and is active, station A will send an identifier message called a “beacon”. Station B hears the beacon and responds. Both stations exchange the “connection” protocol data through a series of “handshake” messages.
Once “connected”, either station may start a file
transfer. The file is broken into a series of blocks for
transmission. Each block is verified as it is sent and when received,
the other station sends an acknowledgement message (ACK) or a
rejection (NAK). If rejected, the same block is re-sent until the
other station sends an ACK indicating the data is correct. When all
data is sent, a message ACK is sent and both stations indicate a
completed file transfer has occured, usually with a end of file (EOF)
and/or end of transmission (EOT). Lots of data flying back and forth.
And if a static crash or other noise corrupts the data block, this
too will cause a re-send. It should be obvious to the reader that, noisy channels (like most HF frequencies) would make ARQ difficult and/or lengthy.
The image to the left shows station B has received a beacon message
from station A and is responding. This establishment protocol must be
completed before any data can be exchanged.
Once the link has been “connected”, the sending station A
can select a file to tranfer and begin the process.
Data blocks are sent and ACKs are received until all the data has
been sent or either station receives a “disconnect”
message. This is no preset length of time or blocks. The exchange
will continue as long as the sending station has more data to send
that has not been ACKed.
This image shows two connected stations...in this case, W3YI connected to W3YJ, transferring data. W3YJ is Harry Bloomberg, Assistant SEC in the Western Pennsylvania ARES ARRL Section. Much of this document is drived from material he uses in training.
There are several things worthy of note. The filename of the file being transferred is shown in the box near the middle of the window. And, the progress of data transfer is shown as a progress meter just to the right of the file name box.
So why FLARQ? On high–speed, low noise channels (like VHF/UHF frequencies and above, simplex or through a repeater), it is very efficient; enabling data transfer quickly and without error. Two stations can exchange large files and data in relatively short time. Repeater delays and courtesy beeps are possible with FLARQ. Block size is completely selectable making it very flexible where changing conditions occur. On HF very low noise conditions rarely exist below 17 meters. ARQ mode will cause an excessive amount of “Re–send Requests” or NAKs, thus lengthening the time to complete the data transfer and “disconnect”.
The well known WinMOR protocol in WinLINK uses such methods, albeit with much higher reliability.
FLARQ is mentioned here as it is a vital part of NBEMS and can be used in certain local–area communication plans. It is not generally considered as a prefered wide–area HF file transfer method due to the low noise efficiency mentioned.