Introduction

FSQ is a Fast Simple QSO mode designed specifically for HF. It works well under NVIS and sunrise/sunset conditions on the lower bands, and also works well for short skip and grey-line on higher bands. It can also be used on VHF FM, and clearly has a much wider useful range of operating conditions that other more conventional digital modes. FSQ transmission is also well within the capability of micro-controller based devices for low-power propagation transmissions (MEPT and telemetry). The FSQ modulation, coding and FSQCall protocol are publicly disclosed and described, and the software is open source. FSQ was developed by Con Wassilieff ZL2AFP with the assistance of Murray Greenman ZL1BPU. The first QSO took place between these two on 28th November 2014, and the first Alpha executable release was on 17th December 2014. The source code was released with the Beta version 0.23 on 3rd March 2015. The first US version release (V0.24 RC1 by Bob NW8L) was on 29th March 2015. The first full-package public release was by Bob NW8L on 29 April 2015. A version of fldigi with full FSQ support was released by Dave W1HKJ on 16 July 2015, and includes support for Linux and Mac platforms. The first eight-channel remote telemetry application, by Murray ZL1BPU, went live on June14 2016. FSQ is intended for fixed frequency (channelized) operation, with dedicated calling frequencies. It isn't intended as a 'tune around to see what you can find' mode! Some of the unique features of FSQ are described below. First, (for the impatient!) the downloads, and then some history.

Code Links

History

Let's review the general history of Amateur MFSK modes. The first Amateur MFSK mode developed anywhere was MFSK16, specified by Murray Greenman ZL1BPU, then first developed and coded by Nino Porcino IZ8BLY in 1999. Before MFSK16 arrived, long distance (DX) QSOs using digital modes were very unreliable: reliant, as they were, on RTTY and later PSK31. MFSK16 changed all that, using 16 tones and strong error correction. Great for long path DX, but nobody could ever say it was easy to use, never mind slick (quick and agile)! Over the next few years, many MFSK modes appeared, in fact too many! Most of these were aimed at improving performance on bands with QRM. Most used very strong error correction, some types a poor match for MFSK, and these were very clumsy in QSO, because of long delays. The next major development, aimed at easy QSOs with slick turnaround, was DominoEX, designed by Murray Greenman ZL1BPU and coded by Con Wassilieff ZL2AFP, which was released in 2009. Rather than using error correction as a brute-force approach, DominoEX was based on sound research, and achieved its performance through carefully crafted modulation techniques that required no error correction. The result was a simpler, easier to tune, easily identified mode with fast turn-around. DominoEX is widely used and available in many software packages. A later development by Patrick F6CTE and then Dave W1HKJ, added FEC to this mode (THOR), but did not add greatly to performance, and at the same time eroded the fast turn-around. The final DominoEX- related development was EXChat, a version of DominoEX designed specifically for text-message style chatting. While completely compatible with DominoEx, it operates in 'Sentence Mode', sending each short over when the operator presses ENTER. EXChat was developed by Con ZL2AFP and released in 2014. Back in 2013, Con ZL2AFP developed an MFSK mode for LF and MF which used an unusual decoding method pioneered by Alberto I2PHD: a 'syncless' decoder, which used a voting system to decide when one tone finished and another began. The first use of this idea was in JASON (2002), which proved to be very sensitive, but very slow, partly because it was based on the ASCII alphabet. The new mode, WSQ2 (Weak Signal QSO, 2 baud) combined the syncless decoder with more tones, 33 in total, and an alphabet specially developed by Murray ZL1BPU, which could send each lower case letter (and common punctuation) in just one symbol, resulting in a very sensitive (-30 dB SNR) mode with a 5 WPM typing speed. In subsequent discussion in late 2014, between the developers ZL2AFP and ZL1BPU, it was realized that if the computer had enough processing power to handle it, WSQ2 could be 'sped up' to become a useful HF chat mode. This required a large amount of development and retuning of the software to achieve adequate speed was involved, along with much ionospheric simulator and on-air testing used to select the most appropriate parameters. Tests proved that the idea not only worked well, but it also had marked advantages over existing HF MFSK modes, even DominoEX. As expected, the new mode was found to have superior tolerance of signal timing variation, typically caused by multi-path reception, and would also receive with no change of settings over a wide range of signalling speeds. So this is how FSQ came about. It uses the highly efficient WSQ character alphabet, IFK+ coding, the same number of tones as WSQ (33), but runs a whole lot faster, up to 60 WPM, and uses different tone spacing. The symbol rate (signalling speed) is modest (six tones per second or less), but each individual tone transmitted carries a surprising amount of information, resulting in a high text transmission speed. And it operates in 'Chat' (sentence) mode, which allows the user to type as fast as possible, since they type only while receiving. The ability to send messages and commands selectively has opened a huge array of communications possibilities.

What Makes FSQ Different

Incremental Keying

FSQ uses Offset Incremental Frequency Keying (IFK+), a type of differential Multi-Frequency Shift Keying (MFSK) with properties which make it moderately drift-proof and easy to tune. IFK+ also has excellent tolerance of multi-path reception. IFK was developed by Steve Olney VK2XV. IFK+ (with code rotation) was proposed by Murray Greenman ZL1BPU and first used in DominoEX. IFK+ prevents repeated same tones without complex coding, and provides improved rejection of propagation-related inter-symbol interference. In the context of sync-less decoding, the IFK+ code rotation also prevents repeated identical tones, which could not have been detected by this method. Efficient Alphabet

In FSQ, a relatively high typing speed at modest baud rate comes about because the alphabet coding is very efficient. All lower case letters and the most common punctuation can be sent in just one symbol, and all other characters (the total alphabet contains 104 characters) in just two symbols. (The alphabet is listed below). This is a simple example of a Varicode, where it takes less time to send the more common characters. The character rate is close to six per second (60 WPM), the same as RTTY, but at only 1/8th of the baud rate. (RTTY has only one bit of information per symbol, 7.5 symbols per character, and wastes a third of it's information on synchronization, and despite this, works poorly on HF). No Sync

Another important factor in the design of FSQ is that no synchronising process is required to locate and decode the received characters. Lack of sync means that reception is much less influenced by propagation timing changes that affect almost all other modes, since timing is quite unimportant to FSQ; it almost completely eliminates impulse noise disruption; and it also contributes to very fast acquisition of the signal (decoding reliably within one symbol of start of reception). Fast acquisition removes the need for addition of extra idle characters at the start of transmission, and this leads to a very slick system. Add high resistance to QRM and QRN, thanks to the low baud rate, and you have a system so robust that it does not need error correction. Arbitrary Sending Speed

Unlike most other modes (the exceptions are LF modes JASON and WSQ2), the FSQ receiver operates without needing any information about the sending speed. It will operate from 2 baud to 6 baud, and anywhere in-between, with no changes to settings. The speed tolerance of FSQ is very wide, in excess of 3:1. This is completely unique to FSQ, and gives operators great flexibility. The slower speeds are more robust and slightly more sensitive. Four sending speeds are provided, 2, 3, 4.5 and 6 baud (approximately 20 to 60 WPM), which the receiver will decode with no change of settings. While the default speed is 6 baud, 4.5 baud is generally more reliable unless conditions are excellent. Chat Operation

FSQ is designed for simple but effective 'Chat' operation, rather like phone text messaging or Skype™ chat; fast and easy to use. You don't use 'overs' as you would with a conventional digital or voice mode. It is highly suited to net operation. You just type a sentence and press Enter. Directed Messaging Option

In addition, the FSQCall program, which operates FSQ, operates by default in an Active (Selective Calling) mode, which provides automated functions, and is also useful for net and emergency operation; as it provides network management, link establishment and order and reporting features. FSQCall is based on the FSQ digital modem, but adds numerous Selective Calling functions. It is now also widely used for chat QSOs because the protocol is easy to learn and it offers junk-free reception. Directed Messaging (Selective Calling) is described briefly below. Directed Telemetry

Telemetry can also be directed to specific stations, or to all stations, and also to specific files at each station. Repeated telemetry frames sent to the same address and file places the data in the same file in sequential order. Telemetry can also of course be relayed, or sent from a third-party program via FSQCall. Directed Image Transfer

FSQ can also be used to transmit and receive good quality pictures using special formats that have also been designed for NVIS propagation. The signals are analogue, of similar bandwidth to the FSQ digital transmissions. The transmissions can be used in Chat mode, and in Directed mode can be directed to specific (or all) stations for automatic reception. There are three modes: LO-RES COLOUR, HIGH-RES COLOUR and FSQ-FAX (B&W). Pictures can be transmitted from file photos, scanned documents, drawings and live shots from a web-cam! Here are some examples - 40m transmissions using 15W and a range of 300km.

FSQ-FAX reception example





(Left) LO-RES reception example (Right) HI-RES web-cam reception example Remember - all these pictures are as received after a 300 km transmission! Directed File Transfer

Files can be sent to a specific station, or all stations in range, and are saved automatically. The recipient is advised, and the sender notified if the file was saved safely. Files can be retrieved from a specific station, and you can also read brief or detailed listings of files available from any station running FSQCall V0.34 or later. File transfer is secure in that you can't over-write important files, and you can't read files from anywhere else but the Shared folder on the other station's computer. While the file content is limited to standard text, it could be any type, for example .CSV, .HTML or .TXT, even program source code. If there seems to be an error in the file, simply request it again. Error Correction

Because of the way it has been designed, FSQ is so robust that it does not need any error correction for normal QSOs. That means that transmissions are not slowed down or delayed by the heavy overhead imposed by error correction. Things are slightly different for Emergency Communications and Public Service applications, where there are many occasions when it is highly important for documents to be guaranteed 100% perfect, and FSQCall V0.40 now provides this capability. From FSQCall V0.40, equipped with FSE V0.05, you can now send files with very strong Forward Error Correction, and be confident that they will be received 100% correct. FSE uses widely recognised Reed-Solomon error correction, and features human-readable transmissions and two coding strength levels, 15 or 30 errors per 255 character block.

Technical Details