FSQCall V0.40 has remote request Image send, enhanced file commands, auto file pick-up and send, and
a new resizable window with 'tool tips'. It also runs in Active (Selective Calling) mode by default.

FSQCall V0.40 also has HD image modes, so can send high resolution (640 x 480) colour pictures.
It supports HD cameras. V0.36 also supports short Sounding message payloads, and has advanced file
handling, including File PUT(#), File GET(+) and two File DIR commands based on GET.

If you contemplate developing from source code, please respect the copyright of the various developers.
See notes in the 'Code Development' section at the bottom of this page.

Remember that all the above programs and documents are subject to copyright. You may not copy, alter,
or quote from any ofthese downloads without the express permission of the relevant author.

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.

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

FSQ is essentially a speeded-up version of the weak-signal mode WSQ2, introduced in 2013. It also uses 33 tones, in this case spaced 9Hz apart (actually 8.7890625 Hz, exactly 1.5 x the
baud rate at the highest speed), resulting in a signal bandwidth of 300Hz, including the keying sidebands (bandwidth assessed according to ITU-R
SM.1138). The ITU Emission Designator is 300HF1B. The modulation is constant amplitude, phase coherent MFSK,
using IFK+ coding with 32 frequency differences, yielding 32 unique codes.
This means that each symbol carries enough information for all lower case letters to be expressed in just one symbol, which greatly enhances
the speed.

Incremental MFSK Coding
IFK+ coding means that the character numbers from the alphabet table are added to the previous transmitted tone number, and ONE is added
as well. The purpose of this added ONE is to force a continual rotation of the tones. This markedly improves tolerance of multi-path
reception (reduces inter-symbol interference) and also assists in reducing the effect of carrier interference. When the resulting tone number
exceeds 33, to keep the tones within range, 33 is subtracted from the tone number before transmission.

There is no 'idle' process in FSQ. Transmission starts with no padding, sends all the available characters, and stops when the buffer is empty.
The receiver can lock to the signal following the first tone, as it measures the distance to the next tone.
Thus the receiver detects and starts receiving the first character in under 200ms from the start of transmission.

Fast Fourier Transform Demodulation
At the receiver, the tones are spaced three FFT bins apart, which gives accurate rounding of the differences when the tone numbers
are determined from the FFT bin index and divided by three. (Bin spacing is 2.9296875 Hz). This division reduces the effect of drift and Doppler by a factor of three as well.
There are four alternative speeds (nominally 6, 4.5, 3 and 2 baud), although the tone spacing remains the same.
(Default values are shown BOLD).
Unusually for any digital mode, the receiver settings need not change when you change baud rate! Sensitivity is believed to be
about -13 dB SNR at 6 baud, and -16 dB SNR at 3 baud. That's about 10dB better and several times faster than 12 WPM Morse,
and slightly better than PSK31, MFSK16 and nearly as good as DominoEX11.

Automatic Preamble
Every transmission is automatically identified by the preamble callsign:, so the operator never needs to identify manually.
At the receiver, whatever the sender types appears after the callsign preface.

In FSQCall Directed mode, a special 'end of transmission' character is added as the last transmitted character. FSQCall mode has
slower squelch response,
which aids reception through fades, and this special character is recognised and used to quickly close the squelch to prevent
'junk' from printing. We call this 'smart squelch'.

Character Coding
High typing speed for a given symbol rate is achieved through the use of a highly efficient character coding scheme using Varicodes.
The FSQ alphabet has 29 characters that can be sent as a single symbol (all the lower case letters and frequently used punctuation)
and a further 75 characters using two symbols, encompassing 104 ASCII characters in total.

Lower case should be used wherever possible, as not only are these characters twice as fast to send as upper case,
they are generally easier to type, and the probability of errors in their reception is also halved.

Click the image to view the FSQ Alphabet and Varicode.It's the same as used in WSQ.

Screenshot of the ZL2AFP FSQCALL software
(Click on image for a bigger view)

FSQCall

FSQ is very suited to fixed-channel chat-among-friends operation, since it is simple and slick, tolerant of tuning, and prints very little garble
between real signals. Users can set up local nets on designated frequencies (say on 40 metres), and enjoy chatting on-and-off throughout the day.

Once it was realized that FSQ was adequately robust as well as slick and easy to use, it was decided that the time had arrived for the development
of a simple 'retro' style Directed Messaging (Selcall) system. This system, now the default mode of the program, is called FSQCall. This is simple to use, yet far more sophisticated than conventional Selcall systems.
The program now operates in FSQCall or 'Directed Mode' by default. See the
FSQCall page for details.

FSQCall allows chat sentences to be sent to one individual station (no-one else in FSQCall mode sees them),
to several, or all stations;
no junk appears on the screen at all; and it allows sentences to be saved to file remotely at another station or stations.
You can also query reception quality at another station, read back the status or location of the station, change the remote station's
sending speed, and even relay messages to a station via another station. FSQCall
maintains a list of stations heard, and logs reception to file.

Although not claimed to be an ALE system (Automatic Link Establishment), FSQCall performs many typical ALE functions in a simple, manual way, but does a lot more as well.
It is intended for single-channel use, and is not multi-band scanned. You can use it with a ham transceiver, or with an old marine
or land mobile SSB radio. Apart from the actual chat, the receiver operation is fully automated.

Software Compatibility

The Windows™ software is written in ANSI C, and is compatible with Win Vista, WinXP, Win7 and Win8. It has been used under Linux
using Wine. The program requires at least a 1GHz
processor, SVGA display and a 16-bit sound card. A Pentium 2 class or better is suggested. One serial port (or
USB equivalent) is required for PTT control. Memory requirements are
minimal, and the program size is about 200kB. The program will run adequately on an ASUS EEEPC Netbook if no other programs are running.

The program screen size is small, and fixed, allowing you to use a laptop with a modest screen, or have room for other applications on the screen.
If you find the receive screen does not hold enough text, try reducing the size of the font used.

The program consists of just one file, and no changes are made to the
computer's registry or anywhere else. To remove the program, simply
delete the files made during installation. A setup file is made in the
working folder. This can be deleted in order to start afresh.

Code Development

Developers interested in writing software for FSQ and/or FSQCall, based on the source code provided here, should contact
ZL2AFP (zl2afp "at" xtra.co.nz) and/or the other authors for advice. The various authors retains ownership and copyright.

Developments should be open source in keeping with the existing sources.
In addition, the FSQ and FSQCall
Protocol Specifications remain the copyright of and under control of the authors, and any changes, improvements and additions
must be approved by them.

FSQCall has been designed so that 'Helper' programs can interact with it. Examples of this are FSQPlot, which reads the Heard
Log and plots information from it, and FSM, which formats messages for transmission. We would love to hear from anyone prepared
to develop a'Helper' program that will provide efficient Forward Error Correction for file transmission, in a manner which copes
with character insertions and deletions, which are the prevalent error modes in FSQ.

Credits

The original idea for Incremental Frequency Keying came from Steve VK2XV/VK2ZTO

'Sync-less' peak-hit counting FSK was first suggested by Alberto I2PHD (and used in JASON)

The 'unsquare' 28/32 WSQ Varicode and the general WSQ and Chat concept were dreamt up by Murray ZL1BPU

The FSQCall protocol is an all-new design developed by Murray ZL1BPU with significant input from Con ZL2AFP

Prototype software was by Con ZL2AFP, after years of experience with MFSK modes, including DominoEX of course

The US Version owes its existence to the dedication of Bob Cunnings NW8L and Mike Dannhardt KA4CDN. Thanks guys!