# Fast Simple Error-Correction
for FSQCall

## FSE Installation and User Guide

V0.05, 16.08.2016

MENU
Installation | File Preparation | File Transmission | File Reception

This document uses 'tool tips'. Hover the mouse over each graphic to see the information.

### 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

> FSE (Fast Simple Error-Correction) is what we call an FSQCall ‘Helper’ program. It operates in conjunction with FSQCall V0.40 (or later), accepting incoming encoded message files, decoding and saving them as text files; it also accepts outgoing text message files, the destination address (callsign), encodes the messages and transmits them.

> In order to provide absolute accuracy, FSE uses a Reed-Solomon encoding algorithm (similar technology to that used for CDs, DVDs and digital TV). The technique is able to correct many errors in a text message with absolute accuracy, and will report failure if there are too many errors – without ever delivering a possibly erroneous message. The ‘overhead’ involved in R-S coding is about 60 to 95%, depending on the strength selected.

> Compare this to the more common error management technique used with digital modes, that of binary convolutional coding,, with a Viterbi decoder, where the overhead is 100% or more. With binary convolution, the result is excellent error reduction, but not absolute error correction, as some errors may still remain, and you may not know where they are.

> Transmission
> Many digital radio modes are synchronous, and well suited to error correction techniques, since the only possible errors are substitutions (same number of bits or letters delivered as were sent, even if some are wrong). FSQ, however, is normally non-synchronous, and while this confers significant advantages, it is rather prone to a different type of error, that where letters can be omitted or extra letters inserted. This type of error makes accurate error correction impossible using conventional techniques.

> The FSE encode and transmit process

> So, beneath its simple exterior, FSE includes several advanced techniques to avoid these errors and deliver only perfect files.

> Reception
> FSE takes raw data from the FSQCall receiving detector, synchronously recorded, and post-processes it using a series of digital signal processing techniques. It can find the transmitted symbols with better accuracy than real-time FSQ. It detects synchronism and samples very accurately, so no letters can be added or omitted. A range of other coding strategies is also used to ensure that each character transmitted cannot be misrepresented as two characters, two characters interpreted as one, or a character omitted completely.

> FSE reception, sampling and decoding

> You can read about these techniques in detail, in the accompanying document, FSQ and Error Correction.

### Installation

> Unzip the archive provided into the same folder where the working FSQCall is installed. Apart from the latest version of FSQCall, there is just one other executable provided. When reception of error corrected files is expected, simply run FSE.exe along with FSQCall (must be V0.40 or later), and FSE will do everything for you. The raw sampled data files delivered by FSQCall will be found by FSE in the /Shared folder, sampled, decoded, and the resulting error-corrected decoded files will also be delivered into the /Shared folder. The raw data filess and still encoded files will be archived in the /Archive folder.

> FSE Program window when idle

> You need not run FSE for normal operation. If an encoded file is received when FSE was not active, simply run FSE and it will find and decode the message.

> If encoded files are expected, leave FSE running. It can be minimized and left running in the background.

### Preparing a File for Delivery

> Create the file using Notepad or some other text editor that generates genuine text files. Files created using FSM (Fast Simple Messaging) are also suitable, but word-processor and PDF files are not permitted.

> The file can be anywhere that is accessible by Windows Explorer, on the computer or on the local network. It should preferably not be in the FSQ /Shared folder, which can become rather cluttered.

> The maximum practical file size is about 1000 characters: any longer will take too long to transmit, and will, as a result, make recovering from uncorrectable errors more clumsy. It is better to split larger files into smaller ones which can be retransmitted one part at a time if errors cannot be recovered (as can happen if there is a deep fade during the transmission). A 1000 character message will take a little over four minutes to transmit.

> Another good reason to keep messages under 1000 characters is that band conditions may change during the time of transmission, or other stations may cause interference. If one of the computers used has poor sound card accuracy, there is also a risk of the decoder synchronism drifting off with a longer transmission time. No such problem has been found so far.

### Sending the Encoded File

> Let’s assume that the channel is clear, and you know the station the message is intended for is on-channel and in Active mode. (You can check this by sending them a callsign* command – they should reply callsign Active). When sending messages, it’s a good idea to avoid the general calling channel, where messages can be interrupted by Soundings.

> Make sure FSQCall is in 4.5 baud mode. FSE, being synchronous, operates only at this speed. The other station should ideally, but need not necessarily, be in 4.5 baud mode. Run FSE.

> When the file to send is ready, save it, and drag it from Windows Explorer onto the FSE program, where it says ‘DRAG FILE TO SEND HERE’. At this point you can select whether to use normal coding strength (the default ‘LESS FEC’) or the stronger ‘MORE FEC’. (See later for details).

> Enter the callsign of the station to receive the file into the ‘To:’ box at the bottom, and if the channel is clear, press SEND on the FSE pane. Within a few seconds FSQCall will find the encoded file and begin transmission.

> If another station comes up on the channel before transmission starts, FSQCall will wait. If the transmission is longer than a few seconds, FSQCall transmission will time out and the outgoing message will be cancelled. In this situation, you will need to drag and redrop the file, and press SEND again. FSQCall has a Menu feature (Options/TX reply retries), which can be used to extend the waiting time.

> As the file is transmitted, you will see that the message is a mixture of lower case gibberish and lower case plain text with some strange letters mixed in. There will be no numbers or upper-case text. The gibberish is the Reed-Solomon ‘syndrome’ data used for error correction. The whole transmission is made using a lower-case-only coding technique, which accounts for the strange letters in places where there might be capital letters or numbers in the plain text file.

> Lower case is used because (a) it is faster, and (b) there can never be insertion and deletion errors.

> If the file has been successfully received, the station will reply with an automated acknowledgement. This only informs you that the file has been received, not that it has been correctly decoded.

> If the other station reports that the file was not successfully decoded, try sending again with the ‘MORE FEC’ option. Don't simply cut and paste the message just sent from the receive pane into the transmit pane - if you miss even one letter, or add just one, the message could be undecodable. Use FSE to recode and send the message.

> Note that you can send the encoded files to multiple stations using the ‘allcall’ pseudo-call as the address.

### 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?

> Write to zl1bpu 'at' gmail.com or ask for help on the Yahoo FSQ mail group. It might be a good idea to carefully read the FSQCall Help information and this document again before you do.

### Credits

> ZL2AFP:
>   FSQCall application
>   FSQCall FFT-rate symbol over-sampler
>   Reed-Solomon coder and decoder
>   FSE Helper user interface and file functions
>   Package integration
> ZL1BPU:
>   LC-Maker and Unmaker, lower case restricted character set conversion
>   Symbol transition detection, sync-finding correlator
>   Synchronous symbol sampler and LC text decoder
>   Synchronous symbol recovery metrics
>   Correlator and Sync graphics
>   Documentation, email support

Copyright © Murray Greenman and Con Wassilieff 2013-2016. All rights reserved.