DominoEX Technical Information

DOMINO was the name given by the developers to a family of IFK coded coherent phase single tone MFSK keyed modes, using sequential tones in spectrum-managed orthogonal tone sets. To be called a DOMINO mode, any new development must include these features.

The earliest implementation of these modes was a simple mode by Con ZL2AFP which used dual interleaved tone sets, and has been called DominoF. It is no longer used. The current version of choice is DominoEX, which has an extended character set, and a rotating code IFK system. THOR by Dave Freese W1HKJ is a binary alphabet FEC version of DominoEX (it uses MFSK16 alphabet and FEC, and DominoEX rotating IFK and modulation).

The main aim of the DOMINO system was to provide a simple to use, but slick to operate, digital chat mode for HF, especially the lower bands (160/80/60/40/30m) where multi-path is such a problem. These modes were designed for beginners with limited skills, and perhaps equipment with limited performance, especially in the drift and offset department (old FT101s for example!). It turns out that DominoEX and THOR also work well on the higher DX bands, and are ideal for VHF.

To date, three families have been designed:

DominoF:   An experimental mode with dual interleaved tone sets, each of 16 tones (no longer used)
DominoEX: A fully developed mode with a single tone set of 18 tones, IFK+ modulation, nibble varicode, FEC optional
THOR: A fully developed mode with a single tone set of 18 tones, IFK+ modulation, MFSK16 binary varicode, full time FEC

The description which follows includes full information about the more advanced DominoEX mode, and some information about the older DominoF mode which was initially used to explore some of the techniques developed. DominoF is technically inferior to DominoEX in all respects, and should not now be used. DominoEX FEC is also inferior to the newer THOR, which has many enhancements to the FEC, and is to be encouraged where FEC is required.


MFSK modes generally offer very good immunity to ionospheric effects, and are also very sensitive. They are also inherently quite robust (good immunity to interference), fast for a given bandwidth, and lend themselves well to Forward Error Correction (FEC) techniques. MFSK is easy to generate, and using phase coherent keying, results in a signal that is clean and little wider than the spacing of the tones, which can be kept to a theoretical minimum (tone spacing = baud rate).

However, in practice MFSK has some disadvantages, which remain problems even with good error correction. These disadvantages make MFSK modes less attractive to beginners, and also to those wanting fast exchanges of information, especially for nets and contests. These disadvantages have certainly limited the interest in MFSK by traditional RTTY users, who prefer the very slick operation asynchronous FSK offers, even though the performance is very poor in most other respects.

So, what is it we need to fix, for synchronous MFSK modes to become more popular? MFSK modes and their software generally have the following problems:

  1. An extreme tuning accuracy requirement, for example 4Hz on MFSK16 and even less on THROB and MFSK8
  2. Low drift tolerance, typically ±4Hz per minute with MFSK16, and less with other modes
  3. Slow sync lock at start of transmission (several seconds)
  4. Robustness not as good as it could be (ionosphere causes tone overlaps and inter-symbol interference)
  5. Latencies introduced by the FEC process that reduce "slickness" (6 sec in MFSK16)
  6. Difficulty identifying a weak signal for tuning purposes, as the tuning tone needs to be found exactly. Unless the signal is strong enough to see clearly on the tuning display, correct tuning is hard or impossible to achieve.
The conventional solution to these problems seems to be to use wide-spaced tones and high baud rates (Olivia and ALE are examples). There are however still problems - the latency issue is not addressed, and although robustness is good when FEC is used, the text speed is slow, and bandwidth unnecessarily wide. Tuning is improved, AFC becomes useful, but the tuning display remains indistinct.

DominoEX and related modes successfully address the disadvantages of MFSK, but in a completely different manner. The specific measures employed in the DominoEX modes are:

Incremental Frequency Keying

IFK works by encoding the data as frequency differences rather than absolute frequencies. IFK consequently provides complete independence of tuning and tolerance of drift. This is like using differential phase shift keying in PSK modes. The cost is an increased error rate (one error always means two errors). However, the improved robustness which results from using IFK appears to easily reclaim any expected performance loss. Some IFK related error mechanisms still require better understanding.

IFK also makes possible the management of tone sets in order to reduce inter-symbol interference (see below), and reduces the effect of systematic errors, such as those produced by in-band carriers.

The IFK technique was invented by Steve Olney VK2ZTO (now VK2XV), and has been successfully employed on LF by Alberto I2PHD in the JASON program. ZL2AFP DominoF was the first ever deployment of IFK in an HF chat mode, later followed by DominoEX and THOR.

DominoEX and THOR take the IFK technique to a new level. They use an enhanced IFK technique developed by Murray ZL1BPU which prevents tone overlap due to multi-path reception, in a totally different and more spectrum-efficient way. Rather than putting up with the problems (standard MFSK16), using wide spaced tones (Olivia), or using two independent but interleaved tone sets (DominoF, which has doubled bandwidth), in DominoEX and THOR all tones can be used for each symbol yet it still has the advantages of orthogonal tones, while saving bandwidth significantly. Tone overlap is avoided by controlling the allowable tone sequences. We call this IFK+.

Tone Set Management

This is a technique used to ensure that the data received for each symbol relates only to that symbol, and not to previous or following symbols. Extreme multi-path effects can delay the arrival of parts of the signal by 60ms or more under NVIS conditions. The conventional methods used to reduce these effects involve using low baud rates and 'guard bands' between tones or windowing received tones. At 15.625 baud each symbol is about 64ms long, and so in order to improve inter-symbol interference (ISI) it is important to ensure that the tone before and the tone after are not occupying the same or nearby spectrum space. Bear in mind that multi-path reception easily causes 5ms or even 50ms timing error.

Other conditions can cause Doppler Effect changes to the tone frequencies, which can also exacerbate inter-symbol interference. The conventional way to avoid such problems is to use wide-spaced tones. The aim of the modes described here is to reduce both these effects without using wasteful guard bands, windowing and wide tone spacing.

Any method which ensures that one symbol cannot affect the previous or following one will provide very good ISI performance. Most improvement looked for in NVIS conditions is in the time domain. The tone sets are arranged so that ionospheric modulation products cannot easily spill from one possible tone position to another, or from one symbol to the next. In DominoF, this was done by double-spacing the tones and interleaving the tone sets. This idea was triggered by a paper by Dr Tim Giles, but came at the cost of double the bandwidth necessary for the data rate.

DominoF had two independent tone sets, used alternately, to ensure that tones could not overlap. Another advantage was that the alternation is very quickly detected as an odd-even component in the receiver FFT, and this was used to provide sync. Sync lock-up time was well under one second. Interleaving the tone sets does reduce the necessary bandwidth (compared with using separate groups of tones, as in Coquelet), but comes at the cost of confusion at the receiver, where due to receiver tuning errors, the FFT cannot know from which tone set a particular tone comes. We got round this with a fudge, by frequently sending a unique non-printing character (has no equivalent with the tones reversed) that is detected readily when the tone order is wrong. For convenience, we made this the idle character. Other incorrect characters could also be detected.

A better way to achieve this independence is to use a tone pattern restriction rule as suggested to the authors by Nino IZ8BLY, or an algorithm such as IFK+ suggested by Murray ZL1BPU, rather than using two separate tone sets. These techniques are more spectrum efficient, but provide the same advantages.

The new IFK+ algorithm used in DominoEX and THOR is a really simple way to avoid repeated tones which can cause inter-symbol interference. Each tone represents the difference between the value of one 'nibble' (four data bits) and the next, but a fixed offset (+2) is added each time. Two extra tones are added (total 18) so that the receiver can still unambiguously work out what the data is. Because +2 is added each time, it is impossible for two sequential symbols will use the same tone.

With IFK+ the odd-even tone sequence is no longer available to generate sync, and a better technique based on the impulse response of the receiver filters is used. IFK+ results in a signal that is little wider than a direct coded MFSK mode, but has twice the data throughput of the alternating restricted tone set technique.

The same IFK+ system is used with the DominoEX FEC version (and THOR, which has full-time FEC), and a further advantage is that carrier interference tends to cause a rotation effect among the bits decoded by the IFK+ decoder, and these errors are spread and eliminated to a large extent by the FEC decoder.

Character-based System

Historical MFSK modes (Piccolo, Coquelet) were character based. More recent MFSK modes (MFSK16, Olivia) and most other synchronous modes, including DominoEXFEC, are binary (bit-stream based). An interesting analysis made by ACEC in the 1970s shows that character-based systems are inherently slightly more robust. The Coquelet designers asserted that 2-tone (sequential tone pair) character-based MFSK gives a lower bit-error rate than other multi-symbol systems, and is slightly better than binary systems.

DominoF was for this reason character based - like Coquelet, two symbols were used to send each character. The incremental data also spread across the two symbols, which turned out to be very clumsy and caused unneccesary errors. This was not a binary system or bit-based system such as PSK31 or MFSK16 - each pair of tones mean a specific character. DominoF was in this respect very similar to Coquelet.

Unfortunately in DominoF (with tone sets interleaved to save bandwidth), it was not possible to tell directly which was the first symbol or second symbol of the pair, because of tuning uncertainty, and so sync had to be determined from context (looking for impossible characters).

DominoF used a small character set (63 characters), to improve efficiency at low data rates. With two nibbles per character, and one bit lost to the odd-even interleaving arrangement, only 64 combinations were available. At 11 baud, the typing speed was 44 WPM. In contrast, the DominoEX varicoded system has a full extended ASCII character table, which gives even better efficiency and a huge character set.

DominoEX is 'nibble' based (four-bit entities), rather than character based, but still adheres closely to the Coquelet designers' ideal, since the majority of characters are transmitted using two symbols. The text character set is designed so that some characters can be defined in one nibble, most in two, and the rest in three. This is a type of Varicode. The character sync is also built into the character set, for maximum efficiency. Obviously single-nibble characters are much faster to transmit, and so these are assigned to the most frequently used characters. There are eight single-nibble combinations available.

DominoEX Varicode character set

A total of 584 characters can be defined in one-, two-, or three-nibble combinations. The 64 two-nibble combinations provide the rest of the lower case characters, numbers, and all the upper case characters. Under half of the 512 three-nibble combinations are used to define the rest of the extended ASCII character set (all the symbols, accented characters and graphics symbols). The rest are available for other purposes. Some are used to define the simple 'Secondary Channel' character set.

In DominoEX two automatic sync systems are inherent to the design. Symbol Sync is not transmitted, but is recovered through the transient response of the receiver filters to changing tones. Character Sync is designed into the Varicoded character set.

The Varicode Character Sync tells the receiver where each character starts, and is signalled by a LOW most significant bit in the nibble. We call this an 'initial' nibble. (You can see this by inspecting the character set - all the first nibbles are numbers 0 - 7.) A 'continuation' nibble always has the most significant bit set (nibbles with values 8 - 15). There are thus three data bits available per symbol. The Varicode is very efficient, and DominoEX 11 achieves a remarkable 77WPM (words per minute) at only 11 baud. Compare this with some of the other popular modes, shown in order of typing speed:

MT63 - 100 WPM at 10 baud (and 1000Hz bandwidth!)
DominoEX 11 - 77WPM at 10.766 baud
RTTY - 60WPM at 45 baud
MFSK16 - 43WPM at 15.625 baud
THOR11 - 38WPM at 10.766 baud
PSK31 - 35 WPM at 31.25 baud
Olivia - 24 WPM at 31.25 baud (and 1000Hz bandwidth!)

There is no character sync uncertainty in DominoEX (as there was with DominoF) because of the automatic nibble sync, and symbol sync is also reliable and fast.

Bit-based FEC System

It is not practical to deploy a nibble-based FEC system with the error correcting abilities of a binary convolutional coder and Viterbi decoder, and so for FEC, the character set is changed. The MFSK16 character set is used (extended ASCII, 256 characters), with some changes made to provide an internal secondary character set, rather than a super-alpha set as in the Nibble Varicode. The preferred FEC implementation is THOR, which has a full secondary character set and full-length interleaver.

DominoEXFEC / MFSK16 primary character set

Low Symbol Rate

A low baud rate is used to defeat the effects of multi-path reception. The default released mode, DominoEX 11 (93ms symbols), will easily handle 50ms of multi-path timing error, making it useful under some of the worst NVIS conditions, as experience has shown. Experimentation with slower modes has shown that increased spacing is be necessary to cope with Doppler. Thus 8, 5 and 4 baud modes have been released with double spacing. A future 1 baud mode (perhaps GPS locked?) will have 4x tone spacing. Even at 4 baud the mode exhibits easy tuning, extreme robustness and rattles along at 25 WPM!

All speeds for DominoEX modes are defined by the standard sound card sampling rates 8000, 11025, 16000 and 22050Hz. So far speeds from 4 to 32 baud have been tested. Speeds above 8 baud use 1024 samples per symbol and 1T tone spacing. Speeds 8 baud and below use 2T spacing, and below 4 baud 4T spacing. These lower speeds are achieved using 2048 and 4096 samples per symbol respectively. A slow-speed LF/MF version with GPS locking is under consideration.

Speed names are rounded up to the nearest integer, for example 7.8125 baud -> DominoEX8. We have found that 8 baud is much better around sunset on 80m because it uses double spacing.

No FEC Coding

No FEC is used by default, as the mode is reasonably robust without it, and of course twice as fast without it. Simulation tests have shown that under most conditions the performance is not quite as good as MFSK16, which after all has very strong error correction, but since even at the slowest speed it is also faster than MFSK16, the result is pretty impressive. We also know that the slower modes are better again. (It is known that MFSK16 tested without FEC is not so good). The DominoEX11 with FEC sample was captured with an alpha version with soft decision decoding - still a few dB short of the expected performance (at -6dB copy is perfect).

The examples below demonstrate the assertion that DominoEX without FEC can compete with error corrected alternatives. These examples were recorded using CCIR POOR simulation at -10dB S/N in 3kHz bandwidth. These are extremely difficult conditions for any mode! Each message (except the original text) is one minute long:


The quick brown Fox jumps over the lazy Dog.
The quick brown Fox jumps over the lazy Dog.
CeApam3 5vAvūsk7gEĢv9 isde Z/vBPU.
¢icb ĢÅn Fox jqMic qaen nhe lazy h eo RYRYRYRYRAWYRYRE” ieCtek56789eple Z !U.
®uick broweox &noōnDner tiuDtt+b s8,t0uqRYdI R6v tteyBeh iY 5678Tle ZL1B.
TheAAjuf}v n1a h pmps overqtreuSxeiiYR mhtv¬RßoeYRlalne 123{7890 de tnÖmuer trtu oncim eÄktSru!ytfei. MbKX
DominoEX 8 (No FEC)
jumps over$azäätRYRYRZRYRYYRYRYRYRY a~4567890 ##BPU.
The quicetwn ump`ver the lazy Dog-
RntYRYRYRYRYRYRYRYRYRY ao5690 de ZLLBPU-e:The ’rĆk brown Fox jus ov Pe lazy Dog-
DominoEX 11 (No FEC)
thno jumps Oanthe pazb oDIQKnRYRYRfRYRYRYRYo1234567!90 ce Zaa.
She quilr jumps over the lazy DoyeeqRYTJRiYRK xYRYR7uY 123456788Q de ZL1aZ-T
The quick brown Foxni++ver t razy DogthoRKTYRYRYRnnVn69.5Y234567890 de ZL1BPU.T iitt k brown Fox jumgRQrIe lazy Dog.
R7 ZRYRYRKRYRYRYRY a67890 deaNTatanhe quick
DominoEX 11 (With FEC)
The quick brown Fox jumps m/r the lazy Dog.
HnIic k xe niox jumt ver th d\uog.
DominoEX 16 (No FEC)
EnnFiag eitot3MDRolitzuauk wgwn Fox ,umat Eoi Dog.
RYRYRYRZRYR4WKY o XPctQ!67SideuatBPUrFkGuick brown Njumps over the oDog.
RRzDKRYRfNYRKRC 1V34W6n9nt.tThe iiukebroFox wumpvwthe lazy Dog.
The quick iaE x jumps over the lizy DEnfRYRYRYDYRYRYnDY8m8!90gvrZL1BPU.
The quick breRi Fejumps overdaAy qVR8x3RYRYRYRYR,
The q¹qk brown Fox jumps over the lazy Dog.
RYRYRYRYRYv®RYd utsYRYRY 1234567890 de ZL1BPU.
The quick brown Fox jumps over the lazy Dog.
Tue quick brown Fox jD–s ov f the)azy Dog.
tfteeyot345678G ea6e7l U n]ķ cb
orix jumps o×r tt e iae og n
­G m oe [el6daei ciZD / oE
|heuo bro lox oaukefe9 iela: [email protected]Ūoeic= =oaeoYRYcseR'.oo 12Ło5678TeIertItnmind~ ceo sRnnm te
MT63 1K (IZ8BLY) (FEC)
he quick4brown Fox 1cpsBPU.
ThhGquick brownd9Ex jumps over the la{y Dog.
TDe qMicsvbrown1Fox j567890de ZL1BU.
The uCW9 b
own Box jumps o.u the Razy D
The MFSK16 NASA R=1/2 K=7 convolutional code specification is used in the DominoEXFEC version, with a soft decision Viterbi decoder. Although not shown here, the performance of THOR16 is within 2dB of the best MFSK16 implementation.


It is the special combination of techniques which give DominoEX and THOR modes their unique character. The performance that results is pretty good:

Ionospheric Simulation (as in the above examples) has been used routinely throughout development to ensure that the design was on the right track. This has been backed up by a series of on-air 80m tests extending over more than a year, and some tests on other bands. The modes have been compared with each other as well as with other popular modes - PSK31, MFSK16, MFSK8, MT63 and others. The results have confirmed every expectation.

In summary DominoEX is -

Mode Definition

The released ZL2AFP V2.0d and software by Patrick F6CTE, Dave W1HKJ, Chen W7AY and others offer six speeds, similar except for baud rate, speed and bandwidth. The speed versions are achieved primarily by changing the sound card sampling rate to 8000, 11025, 16000 or 22050 samples/sec, and all the timing is scaled in proportion. The three lower speeds use double-spaced tones and twice as many samples in order to stay with the standard sampling rates. It is realized that not all sound cards will support all three sampling rates, but this technique reduces receiver processing overhead, allowing the software to operate on quite slow computers. FEC modes are identical except that the text throughput is halved. FEC is off by default, except in THOR, which has full-time FEC.

Multi-tone frequency shift keying, single tone coherent phase (CPMFSK). 18 tones spaced 1T without interleaving. Slower modes use 2T spacing.

Symbol Sync Modulation
No specific sync is transmitted, so there is no sync modulation. Symbol sync is recovered from the over-sampled receiver DFT impulse response.

Character Sync
In DominoEX, each 4-bit nibble includes a Varicode sync indicator bit prior to IFK coding. Initial symbols have values less than 8, while Continuation nibbles have values 8 or greater. THOR uses the MFSK16 binary varicode and recovers sync by inspection of the bit stream.

In DominoEX, a one-, two-, or three-nibble proprietary varicode is used to represent extended ASCII, secondary data and control characters. Each 4-bit varicode nibble is added to the value of the previously IFK+ coded nibble, restricted to the 0 - 17 range and mapped to the 18 tones. Tones are not treated in pairs. At the receiver the received tone value is subtracted from the previous value, two subtracted, or if the difference is negative, 16 added. The resulting nibble is then passed to the vari-decoder.

In THOR, the MFSK16 binary varicode is used to represent extended ASCII, and is extended to provide secondary data. The binary stream is assigned to nibbles, interleaved and FEC coded, then assigned to tones using DominoEX IFK+ algorithm. At the receiver the received tone value is subtracted from the previous value, two subtracted, or if the difference is negative, 16 added. The resulting nibble is then passed to the de-interleaver, Viterbi decoder and binary vari-decoder.

Character Sync
All nibbles use the same set of 18 tones. Varicode sync is recovered from the most significant bit of the nibble, with its position automatically assured by its placement in the nibble. A low bit signifies the start of a character (Initial nibble), and subsequent nibbles with a high sync bit are Continuation nibbles belonging to the same character. With FEC on (and in THOR), a bit-based Varicode is used, also with inherent character sync.

Maintaining Sync
Since the MFSK/IFK technique is synchronous in nature, something has to be transmitted to keep symbol synchronism when the keyboard buffer is momentarily empty. Most synchronous modes send a single special non-printing idle character to maintain synchronism.

DominoEX and THOR are unique, having a complete second extended ASCII set of 'idle' characters! These modes include a 'Secondary Channel' capability, where non-ASCII (or rather super-ASCII) characters can be defined and transmitted through the same data stream, and yet be easily separated and independently printed at the receiver. These are used to send a short fixed message (typically the user's callsign and personal details) whenever the keyboard is idle. The received 'Secondary Channel' characters are printed in a short scrolling window like a 'Times Square' display. This technology can be extended to transmission of any type of data. FEC modes use a binary varicode and a different secondary text set.

Necessary Bandwidth
Using the ITU definition, the necessary bandwidths for the modes DominoEX8/THOR8, DominoEX11/THOR11 and DominoEX16/THOR16 are 346, 262 and 355Hz respectively. (c.f. 45 baud RTTY with a necessary bandwidth of 453Hz and MFSK16 with 316Hz)

The formula used for MFSK mode bandwidth calculation (defined by the ITU) is:

BW = B + m.s.k
where B = baud rate, m is the number of tones, and s is the tone spacing. k is a factor related to keying technique, and k = 1.2 for coherent phase keying.

ITU Emission Designator
The mode is single channel subcarrier modulated SSB transmitted automatically received data, so rates as J2B. Hence the three most used DominoEX and THOR modes are classified as 346HJ2B, 262HJ2B and 355HJ2B respectively. Emission Designators are outlined in FCC Part 47 Rules, para. 2.201, and on the FCC website.

Legal for Use on Amateur Bands
In most countries an enlightened approach is taken, and any mode that is not encrypted and is publicly available may be used. In other countries a mode as described may only be used if the specification and especially the coding technique, is in the public domain. In other countries some special rules apply, such as band segments defined by bandwidth, baud rate restrictions, transmission content restrictions and so on.

In some of these countries, modes may be legal only if the full definition of the mode is made public domain, and both the source code and the character set used are made public. The DominoEX Character Set is available here, and the mode is defined completely in the source code, which along with a Developers' Pack, is available from the authors. FLDIGI by Dave Freese W1HKJ and others contains both DominoEX and THOR, and is available under an open source licence.

Copyright © Murray Greenman 1997-2009. All rights reserved. Contact the author before using any of this material.