WSQCall

Introduction and Setup Information

Version 1.20 24/03/2018

Introduction

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.

    New Features

    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:

    WSQCall operates in 'chat mode', with an operation style familiar to those conversant with cellular phone or internet chat.

    How it works

    The receiver has essentially four processes: signal detection, decoding, parsing and command processing:

    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.

    Synchronous Decoding

    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

    Installation


    The PTT/CAT settings dialogue.

    Software Compatibility

    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!


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