WSQ is a Weak Signal QSO mode for LF/MF. It uses Incremental Frequency Keying (IFK, an MFSK variant), making it moderately drift-proof and easy to tune. The specific keying used, IFK+, was developed to eliminate inter-symbol interference, and significantly reduce the effects of carrier interference. WSQCall is the implementation of this technology with improved performance and the addition of a selective calling protocol.Digital mode signalling is measured in symbols, which are individual moments of time where the transmission has the same phase, frequency and amplitude. The symbol rate of WSQ is very slow, compared with other modes, (by default about two seconds per tone or 0.5 baud), but each individual tone transmitted carries a surprising amount of information, resulting in a typing speed of better than 5 WPM. WSQCall is almost as sensitive as WSPR, with the benefits of free-form text, simple operation, a low error rate, faster typing speed, and true QSO capability with no timing restrictions.
WSQ uses 33 tones, in the default mode spaced 1.46484375 Hz apart (3 x symbol rate), resulting in a signal bandwidth of 50 Hz, including the keying sidebands (bandwidth assessed according to ITU-R SM.1138). The modulation is constant amplitude, phase coherent differential MFSK, using IFK+ coding with 32 frequency differences. This means that the WSQ alphabet could be designed so each symbol carries enough information for all lower case letters to be expressed in just one symbol, which greatly enhances the speed. (Morse code requires on average about 10 symbols per letter). The ITU Designation of this mode is 50H4F1B. There are two further optional speeds, one faster, one slower, which are correspondingly wider and narrower respectively.
The WSQ Varicode Alphabet This latest version of WSQCall is also backward compatible with the older WSQ2 mode, which uses 1.953125 Hz spacing and a bandwidth of 66 Hz (ITU Designation 66H4F1B). Use of the older version is now discouraged, as there are many important advantages to the new version.
WSQCall borrows quite a bit of functionality from the HF system FSQCall, including selective calling, automated responses, and the ability to log all stations received. It also has several new features:
- An improved real-time detection technology (peak-hits decoder) for better sensitivity in noise.
- A raw detector sample output file, which allows users to experiment with synchronous decoding.
- Three fully adjustable notch filters (frequency, depth and width), to suppress interfering carriers.
- A very effective noise blanker, also adjustable, designed to deal with lightning interference.
- A really advanced post-processed synchronous decoder, which markedly improves the sensitivity
and readability of very weak signals.- Improvements to call sign recognition and command processing.
- A new 'please repeat' command, used to receive the last message again.
WSQCall operates in 'chat mode', with an operation style familiar to those conversant with cellular phone or internet chat.
The receiver has essentially four processes: signal detection, decoding, parsing and command processing:
- Detection - received audio is processed by repeated overlapping Fast Fourier Transforms (FFTs), to discover which frequency contains the most energy. The FFT acts like about 200 very narrow filters spaced about 0.5 Hz apart, operating together. The FFT sampling process happens at about eight times per second, and generates a list of bin numbers. The bins are spaced more finely than the transmitted tone spacing by a factor of three.
- Decoding - the FFT bin numbers are successively subtracted from the previous one (and divided by three) to discover the character code numbers. This subtraction, division and subsequent rounding also removes any drift and frequency error. The coded character numbers are then converted to ASCII characters using a look-up table.
- Parsing - the stream of characters (a sentence) is analysed looking for the start and end of the sentence, and any callsigns and commands. The Parser finds and validates the sender's callsign, checks the destination callsign and determines which command was used.
- Command Processing - any commands found are acted upon appropriately, displaying text or making transmitted replies.
The receiver also measures the signal SNR, displays the waterfall (using FFT data), displays the SNR meter, Correlogram, and Sync History, and operates the squelch.
On transmit, the process is essentially reversed: a sentence is assembled, callsigns and commands added, the sentence is coded, then transmitted using a numerically controlled digital oscillator to generate phase-coherent, constant amplitude audio tones from the computer sound device, with the appropriate tone spacing. The lowest tone is 1500 Hz, chosen so transmitter audio distortion harmonic products will fall outside the SSB transmitter filter.
The decoder technology used until now in FSQCall and WSQCall has been an FFT 'peak-hits' type, which looks for three sequential detector samples the same, to determine when the symbol has changed to another tone. In this version an improvement has been made to find three cumulative detector samples. This alternative has slightly improved sensitivity and reliability. Both of these detector options are inherently non-synchronous, as they rely on discovering in real time when the tone has changed. This works fine under most circumstances, and is very tolerant of sending speed variation and changes in propagation timing, but performs less well when the signal is very weak, well below the level of the noise.WSQCall V1.20 now introduces a second decoding technique, which is much less affected by noise. This Synchronous Decoder cannot make symbol to symbol errors in timing, so although individual incorrect decisions can be made when the signal is very weak, these errors are isolated, not perpetuated through the message. As a result, there is some improvement in sensitivity, but more importantly there is a marked improvement in readability of weak signals, since the error rate is reduced by sampling the data at carefully chosen points. The synchronous decoder is a post-processing type, i.e. works with stored data once reception has stopped. The challenge with WSQ is that there is no specific synchronisation information transmitted.
What is required is a process that can learn the point at which the tones change across the whole transmission, in a way that will cancel out any tone-by-tone timing variations, and then by sampling the signal away from the noisy change points, can reduce the effect of noise.
The FFT detector samples (the same ones used by the 'peak-hits decoder) are stored without making any decisions, from the start of reception (squelch opens) until the transmission stops (squelch closes). The FFT detector samples at a rate of 16 samples per symbol, about eight samples per second. All the samples from the whole received sentence are then stored and also saved as a file for possible external post-processing by third-party decoders. Once the transmission has stopped, several processes start.
Synchronisation
The first synchronous decoding process is used to discover message synchronisation, using a highly sensitive cross-correlator. The only thing we know about the received signal is its symbol rate (0.48828125 baud), but not where each symbol starts and stops. Since the stored samples are at exactly 16 times this rate, we can use a device called a cross-correlator, made from a numerical array, with 16 cells, used to determine where these symbol changes are. The cross-correlator technique used is extremely effective on noisy signals.The computer examines the received samples sequentially through the file, looking for any change in tone frequency (the tone samples are represented in the file by the FFT bin number which contained the most energy). The difference between numbers is squared and compared with a threshold. If the result is bigger than the threshold, the tone must have changed (or the detector was fooled by noise), so a corresponding accumulator cell in the cross-correlator array is incremented. The cross-correlator array index is stepped along as each sample in the file is tested, and when the index exceeds 16, it returns to one, so the array keeps in step with the samples at exactly 1/16th the rate. So you can see that most of the symbol frequency changes will be noted at a particular index number, so the array builds up energy in one cell more than the others.
The cross-correlator is very sensitive. It is normal for occasional incorrect detector decisions to be made, or additional or fewer changes to be spotted when the signal is weak, but the statistical character of the cross-correlator, combined with the predictable nature of the signal and the random nature of noise, means that the correct symbol change point (sync) can always be found reliably.
![]()
![]()
The cross-correlator histogram - strong signal (left), weak signal (right)The above pictures illustrate the array after the received signal has been processed. This is exactly what you see from the software. There are 16 cells, numbered left to right in each example, and it is clear that in the left example most of the symbol change energy (the sync point) is concentrated in cell 3. Not all the sync points were found, and some were probably wrong, but neither of these limitations affect the result, any more than noise caused by fades in the signal would. It is very clear that cell 3 contains the most energy.
In the weak signal example (the signal was -28 dB SNR), the histogram is much more spread, but there is a clear peak at cell 12.
Sampling
From the cross-correlator the program now knows with high reliability where the sync point is. Considering the first example above, this is at sample 3 in the file, and every 16 samples thereafter. In order to sample the received data with maximum accuracy, we need to sample it as far as possible away from the sync point, eight samples later, starting at sample 11 in the file. So the next process is to sample the file again, but this time every 16 samples, starting at sample 11. This sampled data is passed to the IFK+ decoder, now with minimum errors and no samples missed or added (as can happen with the 'peak-hits' detector).
![]()
![]()
The sync history graph - strong signal (left), weak signal (right)During the initial reception process (which provides the samples to run the cross-correlator), the symbol change points are also recorded in real time as dots on a graph. Two examples are represented above, exactly as shown by the software: a strong signal and a weak signal (the same signals as in the previous examples). The vertical axis is time, one symbol period (16 samples), and the horizontal axis also time, the full duration of the transmission. Every tone change discovered has been plotted as a dot at the appropriate points.
Notice how almost all the decision points are in a line, with some variation up and down, this variation especially obvious with the weaker signal. At the end of the transmission you see some of the dots are randomly placed, which represents the noise once the signal has gone away. If you look closely, you will also see places where dots are missing, but it is also abundantly clear that a line can be drawn horizontally across this graph in such a way as to miss all the dots. This is what the synchronous detector does: it avoids the symbol change points (where there is less signal energy and more noise from the detector) to maximise the accuracy of the samples, and also to completely avoid missing or extra samples. You can see that in the two examples above, the nominal line on the graph is at a different vertical position, because the sync point is different for each reception.
The samples are sent to the IFK decoder, then the ASCII decoder, and the resulting text reads:
![]()
The main RX Pane shows few errors (synchronous decoder)This is a screen capture from the actual on-air exchange, an almost perfect result - the transmission (red text) was over a distance of 300 km on 474 kHz during the day. The remote station relayed the message, which was received at -28 dB SNR. There are only three character errors, not bad considering the message made two 300 km journeys! (This is the message shown as the weak signal in the previous pictures).
Because the synchronous detector can't show you what's happening during reception (apart from the advancing sync history graph), the 'peak-hits' detector has been retained to show progress of reception in the Monitor Pane, as in previous versions, although you should expect more errors there. (See picture below - this is from the Monitor Pane). The synchronous detector result is displayed in the main Receive Pane, and also used to operate the message Parser (determines whether the message is for you), and the command processor, which determines what to do with the message, and how to reply if needed.
![]()
The Monitor Pane shows more errors (peak-hits decoder)There may be times when the 'peak-hits' decoder gives better reception, but mostly the synchronous decoder wins out. In particular, the synchronous decoder cannot handle the situation when one station transmits over or close to the end of another transmission. The correlator is not given an opportunity to reset at squelch closure, and will make a compromise sync position decision based on both transmissions, which is likely to be inappropriate for both transmissions.
If either station has a gross sound 'card' sampling rate error, this can also affect reception. This is easy to see in the Sync History as a sloping line, and results in a very flat Corellogram. The 'peak hits' decoder should still display the received signal correctly.
![]()
Poor sound card timing
- Download the zipped archive for WSQCall from the ZL1BPU website.
- Unzip the archive into a suitable folder on your C: drive. This must not be anywhere under Windows or directly on the desktop. (The program needs read/write permission). This action will also install the Help information in the /Help sub-folder, and will install WSQplot as well.
- Right-click on the executable WSQCALvxxx.EXE, select 'Create Shortcut', then drag the shortcut to the desktop or to your menu.
- Connect the receiver audio output to the computer Line Input via an isolating transformer or digital modes interface. Ensure that the Line Input is selected as a Record source. This is the same as any digital modes setup with an SSB transceiver.
- Connect the audio out from your computer to the transmitter via an isolating transformer or digital modes interface. This is the same as any digital modes setup with an SSB transceiver.
- Start the program using the shortcut you just made.
- Carefully read the Help files provided on the menu before operating. These files provide a guided tour through the software and its use, and give details of the syntax and expected operating procedure. The Help files are all available from the WSQCall program Menu.
- If using CAT, connect the appropriate (serial, USB or CI/V) cable or adaptor between the transceiver and computer. You may need to manually edit the setup file WSQCALvnnn_setup.txt, to set the correct data rate, or change your transceiver to suit the default rate, 9600 bps. You must close the program before you edit the file.
- Each time the program starts, it first shows the PTT/CAT settings dialog (shown below). If you are planning to use direct PTT via an interface box connected to a serial port, select 'Use PTT' and make sure the 'Comport' setting is correct for your interface. Ignore the 'Rig address' setting.
- If you plan to use CAT, and your radio is listed in the 'Rig address' list (mostly Icom models), select the appropriate rig, and select the 'Use CAT' radio button.
- If your rig is not listed in the PTT/CAT settings dialog, you must close the program (press Cancel) and manually edit the setup file WSQCALvnnn_setup.txt, to add the correct TX and RX commands for your radio. There is an index in the file which shows you where to place these commands. The software understands both text commands (such as 'TX;' and 'RX;') as well as Hex-ASCII (such as 'FEFE76E01C0001FD'). Make sure the COM port address, bit rate, parity and stop bit settings for your radio are correct in the file. Save the file and restart the program. From now on, choose the option 'Use CAT commands from file' to use your user-defined radio whenever you start the program. Make sure the 'Comport' setting is correct. You can ignore the 'Rig address' if using the 'Use CAT commands from file' option.
The Windows™ software is written in ANSI C, and is compatible with Win2000, WinXP, WIN7 and Win10. It may work with Vista on some computers. It should work under WINE on Linux computers. The program requires at least a 1GHz processor, SVGA display and a 16-bit sound card. One serial port (or USB equivalent) is required for PTT control. Memory requirements are minimal, and the program size is just a few hundred kB. The program should run quite well on a low-spec 'netbook' type computer, and the program screen size will also fit on the netbook screen. Be warned that some cheaper notebook computers may have sound card speed accuracy compatability issues. A good quality external USB sound device is the answer here.The program consists of just one executable 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 generated when you first run the program, and log files created when in use.
The design and code for FSQCall is publicly disclosed. Developers interested in writing software for this mode should contact ZL2AFP (zl2afp "at" xtra.co.nz) for source code and other details. We are especially interested in hearing about improvements to the synchronous decoder technique!