Weak signal modes

FEC modes

This page covers the technical aspects of WOLF, WSPR, JT9 and Opera. Tutorials or users guides can be found elsewhere on the web:

• WOLF: WOLF - a proposed new signal format for LF weak-signal work
• WSPR: WSPR users guide, Quick tutorial to start using WSPR, 
• JT9: WSJT-X User’s Guide, JT9 weak signal communication on the HF-bands
• FT8: WSJT-X v1.8 User Guide, Tips for FT8 DXers
• Opera: Welcome to the Opera

Links to the applications itself can be found in the software page.

WOLF
WOLF (Weak-signal Operation on LF) is probably the first amateur radio mode that used FEC. It was developed in 2003 by Stewart Nelson, KK7KA.

WOLF uses BPSK modulation at 10 bits per second. The theoretical bandwidth is 10 Hz, but depending on how the BPSK modulation is performed sidebands up to a few 100 Hz can be quite strong and annoying to nearby stations. Fortunately WOLF provides the possibility to increase the transition time of the phase shift, what reduces the sidebands significantly.
BPSK modulation has a 6 dB benefit over simple on/off keying: with on/off keying (CW and QRSS) the received signal varies between 1 and 0, with BPSK between +1 and -1. This results in a double output voltage at the detector, what equals to a 6 dB gain.
WOLF transmits a fixed 15 character message, allowing short texts as used in a standard QSO. The character set is limited to 40, being the uppercase letters (A-Z), figures (0-9), space, punctuation and slash. You count only 39? Me too. This is because any character beyond this set of 39 is transmitted as the 40^th character and in reception displayed as an asterisk (*).
Next the 15 character message is split up 5 groups of each 3 characters. Each of these groups has 64000 (40·40·40) possible combinations, what fits into a 16 bits (2¹⁶ = 65536). Thus the 5 groups (of each 3 characters) are packed in a 5·16 = 80 bits. Even though no real compression is done the 15 character message is wrapped efficiently into 80 bits.
Now a convolutional FEC coding with a rate of 1/6 was applied, resulting in a 480 symbol code. This code is first interleaved and then merged with a synchronisation pattern of the same length into a 960 symbol code. More details about the coding can be found in the article WOLF Coding Process by Andy Talbot, G4JNT.
At a BPSK transmission rate of 10 baud it takes 96 seconds to transmit the entire message.
The sync pattern is not only used to retrieve synchronisation for a single transmission, it is also used to improve SNR by combining multiple transmissions:
Half of the energy of a transmission is put in the sync pattern and the other half in the data pattern. Thus each of the 80 data bits contains only 1/80 of the energy of the sync pattern (= -19 db). So even if the individual data bits are far below the decoding level the reference stream can still be used to determine the frequency and timing of the signal, and then estimate the phase with good accuracy. This information is used to try to demodulate the datastream, even if the individual databits are to weak to be decoded. Then the results of several frames can be added together, until the signal-to-noise ratio is good enough to decode the message.

The original application is running under DOS (not so uncommon at that time) and takes a WAV file as input. It has to be launched with command line options, in order to select the center frequency and activate a noise blanker and returns a number of parameters followed by the decoded (or attempted decode) message:

• t: elapsed time since start [seconds]
• f: frequency offset [Hz] (frequency of the detected signal relative to the expected frequency)
• pm: power of best sync match [arbitrary units, linear]
• jm: offset of sync pattern at best match [0 to 479]
• q: SNR of the reference channel (1. value) and data channel (2. value) [dB]. Data channel values above -5 dB should give correct decoding.

A complete frame takes 96 seconds and thus WOLF tries to decode every 96 seconds, with one exception: During the first frame there are 3 quick attempts to decode the signal, after 24, 48 and 96 seconds, based on a partial frame. If the signal was strong enough decoding might be successful already after these first attempts. During this first attempts some of the given parameters are different:

• a: phase of the carrier relative to the start [radiants, -pi/2 to +pi/2]
• dp: power of the detected carrier [dB relative, normalized to the length of the record]
• ci: bit phase of the detected sync [1/80 second units, 0 to 15]
• cj: offset of the sync pattern [0 to 479]

Wolf Büscher, DL4YHF, developed a Windows based Graphic User Interface (GUI) for the WOLF software, including the decoding of signals direct from the sound card and a QSO mode. This makes the reception and transmission of WOLF signals much more user friendly.

WSPR
WSPR (pronounced 'whisper') stands for 'Weak Signal Propagation Reporter' and is a beacon mode (not suited for QSO's). It was first released in 2008 by Joe Taylor, K1JT. The code is open source.
WSPR uses a highly efficient protocol to transmit the callsign, the 4 character grid locator and the power level (in dBm) of a station during 110,6 seconds transmission. Transmissions are time synchronised and start exactly 1 second after an even minute. A full description of the WSPR protocol can be found in the WSPR users guide (appendix B) or in the excellent article 'The WSPR Coding Process' by Andy Talbot, G4JNT.

The entire message is compressed into 50 bits: 28 for the callsign, 15 for the locator and 7 for the power level.
Callsign: The callsign has always 6 characters, that can be A-Z, 0-9 and 'space'. All together 37 characters, that are given values from 0 to 36 such that '0' to '9' give 0 - 9, 'A' to 'Z' give 10 - 35 and 'space' is 36. Furthermore 3^rd character has te be a number. In order to allow this a callsign can start with a space (eg. 'W1ABC' will be coded as '_W1ABC, where '_' = space). If the callsign has less than 6 characters spaces will be added in a way the 3^rd character is always a number (eg. 'OR7T' will be coded as 'OR7T__', not '__OR7T' or '_OR7T_'). As a result:

• The 1^st character can be any allowed characters (0-9, A-Z or 'space') → 37 possibilities
• The 2^nd character can be 0-9 or A-Z but not 'space' → 36 possibilities
• The 3^rd character must be a number → 10 possibilities
• The 4th, 5th and 6th character cannot be numbers → 27 possibilities

Thus for the callsign there are 37·36·10·27·27·27 = 262177560 possibilities, just less than 2²⁸ (268435456). So the callsign can be fitted in 28 bits.
Grid locator: the first 2 characters are A - R (18 possibilities) the last 2 are 0 - 9 (10 possibilities). That makes 18·18·10·10 = 32400 possible combinations, so the grid locator will fit in 15 bits (2¹⁵ = 32768).
Power: The power level can vary from 0 to 60 dBm (1mW to 1 kW). These 61 possibilities could be fitted in 6 bits (2⁶ = 64), but 7 bits are used. Although any value in this range could be coded, the WSPR software only accepts value ending on 0, 3 and 7 (0, 3, 7, 10, 13 ... 57, 60).

The protocol as described above is the most frequently used. WSPR allows also more extended protocol that allows a compound callsign (including an additional prefix or suffix such as OH0/DL1XYZ or G4ABC/P) and/or a 6 character grid locator. As it impossible to squeeze this extended information lossless into 50 bits the message will be sent in 2 transmissions:

• 1^st transmission: Compound callsign + power. For example 'OH0/DL1XYZ 23'.
• 2^nd transmission: 15 bit hash code based on the callsign + 6 character grid locator + power. For example '<OH0/DL1XYZ> JP90XI 23'.

If the callsign is enclosed in angle brackets it means that the hash code is received, rather than the full callsign. As a compound callsign needs 43 bits the derived 15 bit hash code is not unique, some (very different) callsigns have the same hash code. This means that a certain hash code can only be assigned to a callsign after the full callsign has been received. Hash codes that do not correspond to a previously received full callsign are displayed as '<..>'. It also means that in theory a mix up of 2 callsigns with the same hash code is possible, but for a 15 bit hash code the chances are extremely low.

The 50 bit compressed message undergoes some further steps:

1. It is FEC coded using a non-recursive convolutional code with a constraint length of 32 and a rate of ½, resulting in a 162 symbol code.
2. It is interleaved, meaning that the 162 symbols are shuffled to make it more robust to short QRM or QSB bursts. Shuffling is done in a known way, so at the RX side the correct order can be restored.
3. The 162 code symbols are now merged with 162 synchronisation symbols in order to have sufficient transition needed for synchonisation. Each source symbol is combined with a sync symbol taken from a pseudorandom (but known) table.

The code now contains 324 symbols. These are fused in 162 groups of each 2 consecutive symbols. Each group is converted from binary to decimal values between 0 and 3 ('00' → 0, '01' → 1, '10' → 2 and '11' → 3). For example: a symbol code starting with '110111100001110010...' will be converted into a series of 4-state values starting with '313201302...'.
Finally comes the modulation: the 4-state value series is used for 4 tone MFSK modulation, where a 0 corresponds to the lowest tone and a 3 to the highest. Both tone spacing and baud rate are about 1.46 Hz (12000/8192 to be exact). At the given baud rate it takes about 110.6 seconds to transit the message (162/1.465). The bandwidth of the signal is about 6 Hz (4·1.46). WSPR messages can be decoded correctly at SNR levels down to -29 dB at 2.5 kHz bandwidth (with occasional decodes down to -32 dB).

Both transmitting and receiving WSPR rely on accurate timing (better than 1 second), so ensure that your computer clock is properly synchronized. Most operating systems will synchronize with an internet time service only once a week or so, what can cause timing errors of several seconds. Therefor it is recommended to synchronize more frequently (depending on the accuracy of your computer clock every hour or even less). Most convenient is the use of a dedicated time synchronization app such as Dimension 4, MeinbergNTP or NetTime (all freeware).

JT9
The great success of WSPR soon led to the demand for a similar QSO mode. As a result Joe Taylor, K1JT, developed the 'JT modes'. Like WSPR, these are MFSK modes based on a highly compressed data structure in combination with strong FEC. On 472 kHz (and below) only JT9 is used as this mode has the best S/N threshold and the smallest bandwidth.
A JT9 message contains 72 bits: 71 data bits and a flag bit. The flag bit indicates whether it is a structured message or a plain text message. For structured messages the 71 data bits are divided into 2 callsign fields of each 28 bits (same structure as in WSPR) and a 15 bit field for a grid locator (also structured as in WSPR), report, acknowledgment or 73. For plain text messages all 71 data bits are used for a arbitrary alphanumeric text of maximum 13 characters.
The FEC coding is identical to WSPR, non-recursive convolutional code with a constraint length of 32 and a rate of ½, now resulting in a 206 symbol code. Next this code is interleaved.
Synchronisation however is done in a different way as for WSPR: taking advantage of the MFSK modulation no synchronisation symbols are merged into the code, but instead an additional MFSK tone is reserved for synchronisation: JT9 uses MSFK 9 tones, where the 8 highest tones are used for the data transfer and the lowest tone for synchronisation. 8 data tones means that 3 data bits are conveyed per transmitted MFSK tone (8 = 2³). Thus a series of 69 MFSK tones is needed to transmit the code (206/3 = 68.667, rounded up to 69). Finally 16 synchronisation tones are merged into the data tones, resulting is a series of 85 MSFK tones in total. Both baud rate and tone spacing are about 1.736 Hz (12000/6912 to be exact), so the signal bandwidth is 15.6 Hz (9·1.736) and the durations of each transmission is 49 seconds (85/1.736). The sensitivity of JT9 is about -27 dB (again at 2.5 kHz bandwidth).
Each transmission begins 1 second after the full minute. As JT9 is a QSO mode a station will transmit either the odd or even minute and will listen the other minute.
The structured messages can be used for a basic (and quick) QSO. Such a QSO requires mutual identification of both stations, reception of a report and the confirmation of the successful identification and report reception.
In JT9 it could look like this: 

For JT9 the same remarks about accurate timing as for WSPR apply.

FT8
FT8 is developed by Steve Franke (K9AN) and Joe Taylor (K1JT) and was added to the WSJT-X suite in 2017. FT8 is a 8-tone MFSK mode with a tone spacing is 6.25 Hz, resulting in a bandwidth of 50 Hz.  The name stands for "Franke and Taylor, 8-FSK modulation".
Each message contains 75 bits but at this moment only 72 bits are used, in the same way as for JT9. Next 12 CRC (cyclic redundancy check) bits are added. Then FEC is applied by using a LDPC, a low-density parity check code (unlike WSPR and JT9 that use a convolutional code FEC). FEC adds 87 parity bits to the code, resulting in a 174 symbol code. The 8-tone MFSK allows to transmit 3 symbols at once, resulting in a series of 58 (8-state) values. For synchronisation purposes 21 (8-state) values are added: 7 at the start, 7 in the middle and 7 at the end. In total 79 (8-state) values are transmitted at a baudrate of 6.25 Hz, so each transmission takes 79/6.25 = 12.64 seconds.
The transmit/receive sequence length is 15 seconds. This makes FT8 4 times faster than JT9 and it allows to complete a basic QSO in 1.5 minute. But this increase of speed comes at the expense of a larger bandwidth (50 Hz versus 15.6 Hz for JT9) and a reduced sensitivity (-20dB at 2500 Hz bandwidth, versus -27dB for JT9). In fact the sensitivity comes close to what can be achieved by a well trained and well equiped CW operator. So if the definition of  a weak signal mode is defined as any mode that can be detected below the SNR level of CW, FT8 can be considered to be at the edge of a weak signal mode.
Note the a transmission takes 12.64 seconds and the T/R sequence is 15 seconds. This leaves the operator 2 seconds or less (taking into account the decoding time) to react, quite a challenging task. Therefor a auto-sequencing option is included, allowing an automated response to the just decoded sequence during a QSO or after a CQ call.
For FT8 the same remarks about accurate timing as for WSPR apply.

Opera
As WSPR, Opera is a beacon mode, not suited for QSO's. The first version was released in 2012 and the author is Jose Alberto Nieto Ros, EA5HVK. In contradiction to the other modes described here the source code is not public domain and even the coding mechanism is kept a secret. Fortunately Guido ten Dolle, PE1NZZ, unveiled the coding mechanism based on Opera versions 1.1.9 to 1.2.8 in his article Opera Protocol Specification.
Opera transmits only a callsign, all other station information appearing in the Opera application (such as locator, QTH ...) is exchanged via internet. The callsign is packed in a 51 bit message:

• bit 47 - 50: unused (set to 0)
• bit 19 - 46: 28 bit packed integer holding a compressed instance of the callsign
• bit 3 - 18: 16 bit checksum of the packed callsign (bit 19 - 46)
• bit 0 -2: 3 bit checksum of the packed callsign and its checksum (bit 3 - 46)

The way the callsign is packed into 28 bits is identical to WSPR.
The 51 bit message is scrambled by XOR-ing to with a pseudo random sequence of the same length. This step ensures that there are enough transitions in the data (reduce the number of repetitive zeros).
Next FEC is applied, using a Walsh-Hadamard code that maps every 3 bits of the message into a 7 symbol codeword. The result is a 119 symbol code (7·51/3). This code is now interleaved to make it more robust to short bursts of QSB and/or QRN.
Finally the 119 symbols are Manchester coded: each 0 symbol is replaced by a 1-0 transition and each 1 symbol by a 0-1 transition. This doubles the code length, but ensures that there are enough transitions so the clock can be recovered at the RX side. Bit 0 is omitted and bits 238 - 239 are set to 1, resulting in a 239 symbol code to be transmitted.
Opera modulation is simple on/off keying (as for CW and QRSS). The advantage is the simplicity of the transmitter needed, but is also results in a duty cycle of only 50% whereas FSK and BPSK have a 100% duty cycle. If a high efficiency PA (class D or E) is used, the duty cycle is not an issue so Opera has a inherent 3 dB disadvantage over modes as WOLF, WSPR and JT9.

The duration of a single Opera transmission depends on the frequency used and varies from 30 seconds (Op05 mode, equivalent of 8 Bd) on SHF to 32 minutes (Op32 mode, equivalent of 0.124 Bd) on 136 kHz. On 472 kHz the Op8 mode is used, taking 8 minutes (0.5 Bd) for one transmission. The sensitivity depends on the mode, for Op2 it is about -23 db at 2.5 kHz bandwidth.

A rather contested feature of Opera is the "deep search" function, based on internet data exchange between several receiving station in order to decode signals.