Fast Simple Error-Correction
for FSQCall

Introduction

FSQ (Fast Simple QSO) provides a simple way to chat between two or more stations on the lower HF bands, or on VHF FM. It is sensitive and reliable, and very easy to operate since it uses fixed channels, and works rather like cell-phone text messaging. The operator need not be in the shack for messages to be received.

FSQ, and the FSQCall software which provides selective calling, automated file transfer and a host of other automatic features, were designed specifically for Emergency Communication and Public Service applications. However, until now, the one thing FSQCall has lacked was a way to transfer files and messages securely with absolute certainty of their accuracy.

In normal Amateur QSOs, a word accuracy of 90% is considered quite adequate to maintain a healthy QSO, and FSQCall easily achieves this level of accuracy without any form of error correction. However, for critical applications, such as passing emergency situation reports, position information, addresses or telephone numbers, detailed instructions or medical information, absolute accuracy must be provided. Fast Simple Error-Correction (FSE) provides this level of accuracy. It does not involve any encryption (the messages are more-or-less plain text), and utilizes the well-known Reed-Solomon block error correction technique.

How FSE Works

Installation

Preparing a File for Delivery

Sending the Encoded File

Receiving an Encoded File

Simply run FSE in addition to FSQCall. When an encoded file is received (it will have a filename with the suffix ‘.enc’), the file will be automatically decoded and saved (suffix .enc removed) in the /Shared folder. The FSQCall MSGRX light will also be on.

There is a small dark blue indicator ‘light’ and button at the bottom right corner of the FSE pane. When a message has been received and decoded, the light will change to red (as in the picture below), and the received, decoded, 100% accurate file will open in Notepad when you press the MSGRX button. See Figure 2. You can then read the file, rename it, forward it, save it elsewhere or archive it as required.

If there was already a file by the same name in the /Shared folder, it will be over-written by the new file.

FSE after receiving a file

Usually decoding is almost instantaneous, but sometimes it can take a while to establish sync securely, and determine which encoding strength is used (the method is discovered by trial and error), so results might not appear for a few seconds.

If the file has been successfully decoded, this will be very clear from the 'Notifications' message. The status information on the left of the FSE pane will give information about the quality of the reception and decode.

If the message does not successfully decode, a warning message will show in 'Notifications', and the red ‘light’ will not illuminate. The received file will contain errors, and will need to be sent again.

Other Information

Program Help
There's a small button top right with a ' ? ' on it. Press that to see this FSE Help information.

Engineering Information
The button labelled 'MORE' in the bottom right corner opens up further information about the file reception. This is what might be called an 'engineering' display, and if you don't understand it, don't bother with it. Pressing the same button (which now says 'LESS') restores the normal window. In the expanded display (see below), there are three extra features:

• At the left, a pair of radio buttons, allowing selection of stronger error correction while transmitting a file. 'LESS FEC' is the default setting, which will correct five errors per block.
• To the right is the Sync correlation indicator. This gives an idea of how the signal is spread by the radio path. The data will be sampled exactly between the peaks in this graph, which is the output of the cross-correlator. The peaks in the graph represent where the Correlator has found symbol transitions. The horizontal graph axis is time, 250ms between the main peaks. The vertical axis represents the number of sync transitions found in the file at each 21ms time step.
• The final item at the bottom is the Sync history, a graph of sync timing over elapsed time. Looking closely at the blue line, you can see that the file reported on in the picure had about 200 transitions (about 200 characters) in total, and there was a slight downward shift in the sync with time. The vertical 'noise' is caused by multi-path reception, which can be ±100ms or so on 80m.

FSE with 'Engineering' data

Relaying Encoded Messages

a. Automatic
At first thought it might seem possible to relay the encoded messages automatically via an Active station, simply by adding the relay station callsign and relay command in the ‘To:’ box (e.g. k3xyz!w1aw). Sure, it’s simple, but unfortunately this method is very unreliable.

Since the relay station(s) cannot be using synchronous reception, even if equipped with FSE, the relayed message will likely include insertion/deletion errors, which cannot be corrected. FSE can only operate when used with direct file store reception (# commands), not ! or ~ commands.

So don't attempt automatic relaying - use only manual relaying!

b. Manual
The correct solution is to select an attended Active station equipped with FSE as the relay station. Send the encoded message to them, with forwarding instructions embedded. They will decode the message, read the forwarding instructions, and resend via FSE (so that new error-free encoding is applied), to the destination or next intermediate point,

In this way, errors will not accumulate with each relay path, and all reception will be synchronous, eliminating the risk of insertion/deletion errors. If the message decodes, it can be passed on completely error free.

Before sending the encoded message to the next station in the relay, you should check that they are using FSQCall V0.40 or higher, by using the ‘callsign^’ command. Otherwise they will not have synchronous reception capability, necessary for FSE to operate.

The following message instruction protocol is suggested: place the following line at the top (first line) of the plain-text message:

[final_destination_station, via relay_station_1, relay_station_2…]

where the stations after the final destination are listed in relay order.

For example:

[w1aw, via k3xyz, wb1abc]

The relaying stations should follow the suggested order, or use an alternative if the suggested station is not available. In order to leave the relaying decisions to the relaying station, use the form:

[final_destination_station, via ]

with the suggested path omitted. If a message form is in use, follow the format of the message form. If made necessary by the requirements of form layout, append the intended path at the bottom of the message, again enclosed in [square brackets].

Because the path instructions are placed within the encoded message file, they are also protected by the error coding.

No mechanism is provided for automatic relay with error correction. It must be done manually.

Performance

Two encoding strength options are offered, and with increasing error correction capability comes increasing transmission time overhead. The following table shows the figures for a standard test message, and compares them to an uncoded text file transmission using the same 100-character plain text message. Each block can contain a maximum of 255 characters, which includes the error-correction syndromes as well as the plain text that they protect.

Performance
Correction Mode	Overhead % over uncoded	Transmission Time (sec)
Uncoded	0	42
LESS	60	67
MORE	95	82

An overhead of 60% means that sending the message would take 60% longer in ‘LESS’ mode than it would to send uncoded plain text. Measurements vary slightly due to message content and the additional uncoded header. Coding efficiency is not constant with message size. Where the message length just spills over into an extra block, the coding efficiency suffers slightly.

‘LESS” mode performs reliably on a 300km path on 80m at night, typically showing up to five errors corrected per block. The example in the picture above was over just such a path, and didn't need to correct any errors. There is plenty of error correction in reserve.

The FSE decoder is able to determine for itself which coding strength is in use. It does this by first trial decoding in ‘LESS’ mode, then if necessary trying again in ‘MORE’ mode. The Strength radio buttons set the coding used for transmission, and have no effect on reception.

R-S Coding Details
Correction Mode	Block Capacity (characters)	Correction Capability (errors/block)
Uncoded	-	None
LESS	225	15
MORE	195	30

Questions?