DOMINO TECHNICAL INFO

DOMINO is 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 ZL2AFP programs are the first software realization of these modes. Since the modes are in their infancy, and many improvements are hoped for, no claim is made that either the modes or programs are any more than steps along the way to communications excellence. We know that the simple programs don't have all the features users would expect in the fancier feature-packed programs, but then again, they are also easy to use and clearly demonstrate the purposes of the modes.

The main aim of the DOMINO system is 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 the modes also work well on the higher DX bands, and are ideal for VHF.

To date, two families have been designed:

DominoF:   An experimental mode with dual interleaved tone sets, each of 16 tones
DominoEX: A fully developed mode with a single tone set of 18 tones, and now with 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.

Description

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.

This new family of DOMINO modes successfully addresses the disadvantages of MFSK, but in a completely different manner. The specific measures employed in the DOMINO 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, 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.

DominoEX takes the IFK technique to a new level. It uses 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 MFSK), using wide spaced tones (Olivia), or using two independent but interleaved tone sets (DominoF, which has doubled bandwidth), in DominoEX 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 DOMINO modes is to reduce both these effects without using wasteful guard bands, windows 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 comes 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 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 FEC version, 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 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, 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. It can also be used to efficiently send binary data as well as text. 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
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 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.

DominoEXFEC / MFSK16 primary character set
DominoEXFEC secondary 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 is continuing with slower modes, and it would appear that increased spacing will be necessary to cope with Doppler. It is expected that 8, 5 and 4 baud modes will be released with double spacing, and 2.5, 2 and 1 baud versions (principally for beacon use) will be defined with 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 from 8 baud upward 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. Plans are in place for a slow-speed LF version with GPS locking.

Speed names are rounded up to the nearest integer, for example 7.8125 baud -> DominoEX 8. We have found that 8 baud is much better around sunset on 80m using double spacing, and 8 baud single spaced may be deleted to avoid confusion.

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 experimental slow modes are about 3dB 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 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:

ORIGINAL MESSAGE

The quick brown Fox jumps over the lazy Dog.
RYRYRYRYRYRYRYRYRYRYRY 1234567890 de ZL1BPU.
The quick brown Fox jumps over the lazy Dog.
RYRYRYRYRYRYRYRYRYRYRY 1234567890 de ZL1BPU.
CHIP64 UNCLOCKED DECODER (FEC)
CeApam3 5vAvsk7gEv9 isde Z/vBPU.
icb n Fox jqMic qaen nhe lazy h eo RYRYRYRYRAWYRYRE ieCtek56789eple Z !U.
uick broweox &nonDner tiuDtt+b s8,t0uqRYdI R6v tteyBeh iY 5678Tle ZL1B.
TheAAjuf}v n1a h pmps overqtreuSxeiiYR mhtvRoeYRlalne 123{7890 de tnmuer trtu oncim ektSru!ytfei. MbKX
DominoEX 8 (No FEC)
jumps over$aztRYRYRZRYRYYRYRYRYRY a~4567890 ##BPU.
The quicetwn ump`ver the lazy Dog-
RntYRYRYRYRYRYRYRYRYRY ao5690 de ZLLBPU-e:The rk brown Fox jus ov Pe lazy Dog-
YRYRYRYNYRYRLRYRKRY 1234W890 de r1a
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.
RYRYARYRYRYnzBit cod+dtcRYRYQjRtipcRYR de ZL1BPU.
HnIic k xe niox jumt ver th d\uog.
RYRYRYQojuyrYhgRYRYRYRYRYR
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.
aRfRRRYDYRYRYYRY 1234567890 de ZLLBPU.
The quick iaE x jumps over the lizy DEnfRYRYRYDYRYRYnDY8m8!90gvrZL1BPU.
The quick breRi Fejumps overdaAy qVR8x3RYRYRYRYR,
MFSK16 (STREAM) (FEC)
The qqk brown Fox jumps over the lazy Dog.
RYRYRYRYRYvRYd utsYRYRY 1234567890 de ZL1BPU.
The quick brown Fox jumps over the lazy Dog.
RYOYRYRYRYRYRYRYRYRYRY 1234567890 de ZL1BPU.
Tue quick brown Fox jDs ov f the)azy Dog.
RYRYRYRYRYRYRYRYRYRYQP Mo% >onl acgnsi
PSK31 (STREAM) (No FEC)
tfteeyot345678G ea6e7l U n] cb
orix jumps or tt e iae og n
R ^EeECRYR ienfRY
G m oe [el6daei ciZD / oE
|heuo bro lox oaukefe9 iela: sDog.@oeic= =oaeoYRYcseR'.oo 12o5678TeIertItnmind~ ceo sRnnm te
MT63 1K (IZ8BLY) (FEC)
he quick4brown Fox 1cpsBPU.
ThhGquick brownd9Ex jumps over the la{y Dog.
RYRYRYRYRYRYRYRYRYRYRY 1234567890 de ZLbbPU.
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. Once fully tuned, the performance should be within 2dB of MFSK16.

Performance

It is the special combination of techniques which give DominoEX 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 -

Not quite as good as MFSK16, but much quicker, slicker, much easier to tune in, and friendly to use.

Has much better tuning aids than other modes - you can see to tune signals you can barely hear.

Better than PSK31 under all circumstances, although about 4x as wide.

Better than RTTY by far, and just as quick to tune and slick to use.

Mode Definition

The released V1.0 PC program (and alpha FEC version 2.0a) 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.

Modulation
Multi-tone frequency shift keying, single tone coherent phase (CPMFSK). DominoEX uses 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.

Coding
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.

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, 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 is unique, having a complete second extended ASCII set of 'idle' characters! DominoEX includes 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 different secondary text set with 64 characters.

Necessary Bandwidth
Using the ITU definition, the necessary bandwidths for the modes DominoEX 8, DominoEX 11 and DominoEX 16 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 modes are classified as 346HJ2B, 262HJ2B and 355HJ2B. 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 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 the character set used is 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.

How IFK Works

Modulation

At the lowest level, DOMINO uses a 16 tone or 18 tone MFSK system with four data bits per symbol (i.e. per tone). These 16 or 18 tones are spaced apart by the same numerical frequency as the baud rate (7.8125, 11.025, 15.625Hz etc). The lowest audio tone (on transmit) is always 1100Hz. This is in essence much the same as MFSK16 and MFSK8. However, from here on, everything is different!

In the receiver, a series of overlapping DFTs (Discrete Fourier Transforms), operating at four times the symbol rate, are used to determine which tone is transmitted. The DFT resolution is four times the tone spacing, so can resolve the tones reliably even when the signal is drifting. A voting scheme is used to decide which 'bin' contains the tone at any one time, since this bin will contain more power (signal plus noise) than the others (just noise). Because the DFTs are performed synchronously with the received signal, four consecutive DFT results can be summed to determine which tone is received. This technique is extremely sensitive, since the bins are very narrow. An important property of the filter technique is that when sampled synchronously, the energy in the correct tone bin will increase to a maximum at the end of the sampling period, while the energy of the same tone in adjacent bins may increase part way through the sampling period, but will cancel out exactly at the end of the period. This technique is known as 'integrate and dump' sampling, and is the mainstay of most MFSK modes.

The output of the DFT receiver is a series of bin numbers, synchronised at symbol rate. Since there are four times as many bins as transmitted tones, the received IFK difference data is arrived at by subtracting the current number from the previous number, and then dividing by four, with rounding. In one stroke, the drift and tuning ambiguity are removed!

Overlapping DFTs are faster to perform than the more conventional FFT, because only the difference data need be processed anew each time. It is also a way to sample the data faster than it is transmitted. The same overlapping DFTs are also used to determine synchronization in DominoEX. If the energy in all the active bins of the DFT are summed, the signal power will be seen in a background of noise, but an important amplitude effect is noticed. The impulse response of a single transmitted symbol, received through a filter of this type is triangular in shape. When the sum of energy in repeated DFTs is examined, this characteristic shape is discovered. The synchronizing scheme uses a clock running at four times the symbol rate (which starts the DFTs), and the phase of this clock is moved back and forth (by adding or subtracting numbers from the counter) until the peak of the characteristic impulse response triangle occurs between the second and third DFTs for each symbol. The amount added or subtracted controls the response speed of the sync system.

Sync Modulation

In the older DominoF, tones are sent in two sets, the odd numbered tones and then the even numbered tones, numbered up from the lowest tone (number 0). Each character consists of one odd numbered, and one even numbered tone. Each tone carries three bits of character data, plus one bit (the least significant bit) which is the set number. So, if for example a character had the bits 101 010 for the first and second tones, they would be sent as 1010 0101, where the red numbers represent the odd-even tone set switching. The result is of course two consecutive four-bit numbers, one of the 16 MFSK tones.

The primary purpose of this unusual tone set switching is to provide a very strong symbol sync system at the receiver. If the receiver detector (which is a DFT process) has odd and even bins, it does not matter which are considered odd, and which even, or if the receiver is mistuned so transmitted even is received odd etc, there will still be a strong square wave component in the receiver at the odd/even rate.

The energy from odd bins of the DFT and the even bins of the DFT are summed and compared. The result is a square wave at half the symbol rate, but unfortunately because of the tuning ambiguity the receiver is not able to determine which phase of the square wave represents the first symbol of the pair, and so other means must be used. In fact, we call the received tone sets A and B rather than odd and even for that reason. There is no way to know from the symbol sync whether a received symbol pair are the first and second symbols of a character, or the second of one character, and the first of the next! This is called character sync, and is a unique feature of character based modes (it also applies to RTTY). Binary modes, in contrast, have no separate character sync, as the symbol sync is the character sync.

The new DominoEX system has just one set of tones, and so can use the tones more efficiently. As described above, sync is recovered from the characteristic impulse response, so no symbol sync need be transmitted. Character sync is achieved by marking each four-bit data 'nibble' with a sync bit. The character sets are defined so that this sync marker is automatically included, and so does not add overhead to the data stream.

Character Sync

Remember the ambiguity described above, where the DominoF receiver couldn't tell symbol A from symbol B to determine which order to use the data? Fortunately there is a very simple solution, which allows the text to be correctly interpreted - a special IDLE character is regularly transmitted, which has no equivalent character interpretation if the odd/even (A/B) order is incorrect. If the reverse version is received, the interpretation is toggled, and correct reception resumes. Generally this only happens at the start of an over, and is not noticed, except that sometimes the Character auto sync radio buttons at the right of the Tool Bar show "low", and sometimes "high". With serious fading the character sync can be seen to flip and then perhaps flip back.

Commonly used characters (such as SPACE) are also arranged to have no equivalent character in the reverse order, and so can trigger switching. However, this is still a fudge, and can result in poor copy under some circumstances. DominoEX does not need this device, as the character set includes its own synchronism.

When the characters are reconstructed (and in the correct order) in DominoF, they are simply looked up in a table (which converts the received number into a character) and the characters are sent to the Receive Window. There is no FEC, no error correction at all. Mangled characters will be interpreted as other characters. Completely incorrect characters (i.e. the few that do not exist) will be ignored, or (in DominoF) used to trigger a character sync switch. The character set contains about 60 active characters, mostly lower case, numbers, and some punctuation. There are no upper case characters.

DominoEX can use a range of different data sets (for example 9-bit binary with parity, text, graphics). The most versatile system used has a huge character set, provided through the use of a varicode (a scheme where characters used most have fewer elements and are thus faster to transmit - Morse, PSK31 and MFSK16 use varicodes). The DominoEX varicode is nibble-based rather than binary in nature, but very efficient none the less.

Two types of data nibbles are transmitted: a 'first' nibble, and a 'continuation' nibble. Characters can consist of one 'first' nibble, or a 'first' nibble followed by an unlimited number of 'continuation' nibbles. In the interests of sensible data sets and to limit the damage caused by errors, the scheme is limited to two 'continuation' nibbles. Each nibble carries three data bits, so one-, two-, and three-nibble characters can be created in 584 different combinations. The primary varicode character set is arranged so that most-used characters use fewest nibbles, and the result is a very efficient full extended ASCII character set (256 characters) where all the most used characters (letters and numbers) consist of only one or two nibbles. All the remaining 3-nibble combinations can be used for other purposes without causing printed characters. Since under half the total possible character combinations are used for primary text, many errors cause non-printing results.

At the receiver, whenever a 'first' nibble is received, the unused data ahead of it (may be just a single 'first' nibble, or a set with continuations) is processed. There are three primary tables - small ones for one- and two-nibble characters, and a larger three-nibble table. The character data addresses the tables. If the address is valid, the character is retrieved from the table and printed. If not, the 'character' may be an idle character (ignored as primary text) or a 'secondary character', which can be looked up in a further large table and processed separately. If the address is invalid in the primary tables and has no valid secondary function, it must be an error and is ignored.

IFK Coding

So far the IFK coding has been left out of the above discussion, since it is not relevant to symbol or character sync, which would operate identically with direct MFSK. However, in DominoF, instead of directly converting the character to be transmitted to a tone number pair, for IFK the character value is subtracted from the value of the previous transmitted character. At the receiver, the value is added to that of the previous received character. With only 8 tones per field, it would be obvious that subtracting one number from another would soon result in a number less than zero, and so 8 is added to the result. At the receiver, when addition causes the number to exceed 8, 8 is simply subtracted from the result. At a binary level this is easy, as all bits but the least significant three resulting from a subtraction or addition are ignored.

Since the same number of bits is required for IFK as for MFSK, and there would seem to be a risk of more errors (if there's one, there will always be two), why use this strange technique? The answer is to achieve frequency independence and drift tolerance. This is equivalent in the frequency domain to the use of differential PSK in PSK31 to achieve independence from Doppler phase variation.

Imagine that characters 95 and then 103 are to be transmitted. When the second one is transmitted, the difference (8) will be sent. However, let's say the receiver is mistuned badly, so it receives numbers off by 30 or so. No matter - the difference will still be 8, so the correct second character will be recovered by adding it to the known previous character. Of course the very first character of a transmission will always be incorrect, but nobody notices.

The process is similar in DominoEX, except that each nibble is represented as a frequency difference in its own right. Because +2 is added as part of the IFK+ algorithm to ensure symbol orthogonality, there need to be two more tones in order to allow reception without ambiguity. When each nibble is transmitted, the tone number used represents the difference between the last tone number used and the data nibble value, plus two. If this number takes the value over 17 (the number of the highest tone), 18 is subtracted and the new number used instead.

At the receiver, the tone numbers are subtracted to recover the result, with a further minus two. If this takes the number negative, 18 is added to the result to give the nibble value.

Drift Tolerance

There is another advantage to the IFK and IFK+ schemes used in DOMINO. At the receiver, there are four tone detecting bins for every transmitted number. This means that the numbers received are always four times those transmitted. That's simple - divide by four for the result, and round the number up or down to the nearest integer. The beauty of this is that drift of one or two bins between characters is lost in the division, as are any small offsets. The transmitter and receive can drift apart at a rate of about 200Hz per minute and still you can receive perfectly!

Buying Robustness

With a conventional MFSK system, performance is limited, when conditions are poor, by the effect the ionosphere has on the signal. Doppler frequency shift effects cause the signal to spread in frequency (vertically in the example to the right), and multi-path reception causes uncertainty of arrival time of the signal (horizontally in the example). Typical values on 80m would be 4Hz and 100ms. On higher bands Doppler is worse, but multi-path is generally less.

The pink rectangle in the diagram to the right represents the receiver FFT bin expecting to receive the tone, an individual symbol, and is typically about 8Hz wide and energy is accumulated for about 100ms. The grey ellipse surrounding the pink rectangle represents the area where energy from the received signal might appear at the receiver. If only that energy which falls in the bin is used, some energy is lost (sensitivity is reduced), but at least no energy that does not belong to the is received.

However, we have been looking at just an isolated symbol tone. In an MFSK system, for maximum efficiency, tones follow one another spaced the minimum distance in time and frequency, so some energy from the previous and next tones will inevitably fall in other bins, causing incorrect results by increasing Inter-Symbol Interference, and thus degrading performance when the signal quality is poor. In the example to the right, energy from a previous symbol, even from a symbol using a different tone, can fall erroneously into the receiver bin being considered.


Energy overlaps into adjacent bins with repeated tones (left)
and even adjacent tones (right)

In a system with managed tones, the tones can be forced to not be adjacent or the same, be it through being spaced twice as far apart, and interleaved, or through using an algorithm, so that the potential for energy to fall in the incorrect bin is much reduced. This is because at each tone, there is a set of adjacent bins that can be completely ignored. Energy from previous tones, following tones (i.e. affected by multi-path reception) and from adjacent bins (caused by Doppler) is largely ignored. This is illustrated graphically in the following diagram.


Data is managed so that inter-symbol interference cannot occur

Where to from here?

ZL2AFP DOMINO is the first system available to Amateurs which exploits IFK for HF, and is also the first to deploy interleaved orthogonal or managed tone sets. It is not the ultimate IFK mode - just the beginning! The authors are keen to hear from other developers interested in taking these ideas further, or in achieving some of what has been attempted here in some better way. There are developers with better skills and more experience whose attention we are attempting to alert with this simple program.

Improvements
We realise that there are shortcomings to the ZL2AFP DOMINO programs, and would love to hear constructive comments that could improve the various technical wrinkles that will be obvious to power users. This is especially true of the tuning independence and ISI strategy techniques. We are not interested in hearing about how many macros should be added, addition of a logging feature, or other bells and whistles. Just tell us how to make DOMINO work well, or do so yourself and pass on your ideas.

Work is continuing to define and test the properties of slower and faster modes. These will be released as work progresses.

Please pass the released programs on as-is, and at no charge, to anyone you feel would be interested, but do not reverse engineer the executable code. If you are interested in writing your own improved version, contact the authors for information and advice. Con ZL2AFP is prepared to make the source code available to genuine developers.

An ARQ mode using IFK
How about developing an ARQ mode using IFK? We have already demonstrated that DominoEX is so slick that 'Sentence Mode' is practical. An ARQ mode would allow packet-style operation on HF with much improved frequency error tolerance.

Existing simpler HF packet modes suffer badly with multi-path reception and Doppler, and some of the more sophisticated types, which fare better, require very high frequency tolerance, not easily achieved with a typical mobile installation. Since there is interest in HF mobile telemetry (specifically APRS), there is scope for an IFK coded ARQ mode to be designed in order to support this activity. DOMINO is intended to promote familiarity with the techniques that would be required. Fast-syncing DominoEX modulation would be especially appropriate as an asynchronous ARQ mode. Mobile operation would also use a transmit-only encoder (microcontroller) and so no PC or sound card. The PC TX/RX software would operate as a sound card driver, similar to the AVG packet driver.

A 32 tone, 31.25 baud ARQ system based on DOMINO would achieve 125bps in a 1kHz bandwidth, and probably achieve up to 500Hz tuning tolerance. Sync lockup would be under 0.5 seconds, allowing a typical APRS UI frame to be transmitted in under 8 seconds. It is not suggested that an ARQ design need necessarily support the full AX25 link layer protocol for connected and BBS operation.

ZL2AFP DOMINO was written in Power Basic for Windows V7.0 and V8.02 by Con ZL2AFP.

Copyright M. Greenman 1997-2005. All rights reserved. Contact the author before using any of this material.