Why should I use DominoEX rather than another mode?
It depends on what you are looking for. If you need an easy to use, quick to tune fast response mode
that works under poor conditions, there are few other choices. This is especially true if you are a digi-mode beginner, or find tuning these modes difficult. Since DominoEX works better than both RTTY and PSK31, and is faster and slicker than both, is there really any choice?
Why is the DominoEX waterfall display so much clearer than that of other programs?
Because the designers are more clever... no, not at all! Actually it is because the waterfall display is operated synchronously with the incoming data. Most tuning displays do not do this. It also helps
that the waterfall has its own AGC.
You will notice that as soon as a signal appears (even if very weak), the noise just instantly disappears, because it is not
synchronous with the signal. In addition, if you have the speed wrong, the waterfall will be more furry. Sync is so good that it works on
signals you can't hear, and so even these weak signals are clear on the waterfall.
What happened to the old Domino (DominoF)?
DominoF (and DominoG) were development versions, used to prove the technology now included in DominoEX.
The new modes are significantly superior, and benefit from over a year of on-air testing. They are faster and easier to use, and sport a full character set as well as secondary text and technically better performance. Just throw out the old software.
Is DominoEX compatible with the old Domino?
No, it is not, unfortunately. There are several points of difference. To have kept them the same would have been to miss out on all the new advantages, such as improved ISI performance, faster text speed and enlarged character set. You should not now use the old programs, or confusion would reign!
How do I tell DominoEX from another MFSK mode?
DominoEX has 18 tones, and is the only mode with 18 tones, but I don't expect you'll be able to count them! The biggest giveaway is that it is the only narrow MFSK mode without an obvious idle condition. MFSK16 starts with a single tuning tone (the lowest) and returns to it when idle. DominoEX does not, since it is never idle. The old DominoF had a downward swooping sound during idle.
You can tell one DominoEX mode from another DominoEX mode by listening to the cadence (the rate of the tones).
You can check that the sound is the same as your setting by briefly transmitting and listening to your signal. You soon get used to it.
A certain confirmation is that the waterfall display will be very clear and sharp at the correct speed, and furry if the speed is wrong. If the speed seems correct, but nothing prints, or prints garbage, carefully check the tuning, and also check that you have the correct sideband. No, you can't change sidebands from in the program.
Which sideband should I set my rig to for DominoEX?
The same one you use for SSB would be the best bet. That is what everyone else will expect. That means LSB
below 9MHz, and USB above 9MHz, including VHF and UHF.
How does DominoEX compare with Morse for sensitivity?
Morse is pretty good, especially between experienced operators. However, it's not just a matter of sensitivity, as propagation conditions come into the equation as well. Morse actually takes some beating when
ionospheric conditions are unstable.
Although dependent on the operator, and a subject of considerable discussion, nobody, experienced or otherwise can copy Morse by ear at reasonable speeds much below -6dB S/N in 3kHz bandwidth (perhaps slightly lower with a good narrow filter). However, without any FEC,
DominoEX 8 for example, can be copied 100% at -15dB S/N in 3kHz, while DominoEX 4 achieves about -18dB S/N in 3kHz. In all cases, copy is better by about 3dB when a narrow filter is used.
By the way, under these conditions, DominoEX 8 rattles along at 55 WPM!
Computer-read Morse is significantly inferior to DominoEX in all respects, as it suffers badly from signal amplitude errors.
How does DominoEX compare with SSB for sensitivity?
Operators' ears acquire a certain amount of 'training', but even the best operator can't copy SSB at 0dB S/N in 3kHz bandwidth for very long, as it takes considerable effort and concentration. DominoEX works easily down to -15dB S/N, so you can run 10% of the power and still have better copy than SSB, and with none of the effort.
Other modes can be copied when you can't hear them or see them on the waterfall display. Doesn't that mean
they are more sensitive than DominoEX?
No, not at all, and it's easy to prove with a simulator. First, modes that sound like noise are difficult to identify in noise,
so you can't 'hear' them. Secondly, if the software waterfall display is indistinct or insensitive, you won't see the signal to tune it,
and the wider the signal, the bigger the problem becomes.
Wouldn't you rather be able to see what you are doing? If you can't tune 'em, you can't work 'em!
Also, sensitivity is only one of several performance factors to be considered. Check the performance of these other modes
with a multi-path simulation with noise, NVIS and Doppler propagation conditions!
Sometimes DominoEX 11 performs badly on 80m in the early evening, and yet 8 baud is superb, and 16 baud is also good. Why is this?
DominoEX 11 has its tones spaced about 11Hz apart. The receiver can discriminate tones with a resolution of about 3Hz. On 80m during the early evening, in addition to
quite marked multi-path, there is often as much as 4Hz Doppler shift. This causes confusion in the receiver. The
DominoEX 8 mode has its tones double spaced, at about 16Hz apart, the same as DominoEX 16. The resolution is then 4Hz, which gives a better margin for Doppler, even though the speed is slower.
You will note that later in the evening, 11 baud performs better again. When things are very noisy, DominoEX 8 or slower will be better than
DominoEX 11 or DominoEX 16, because the slower symbols give better noise handling.
On REALLY bad nights, when the lightning is S9 and virtually continuous, (SSB operators will have given up), you may find 4 baud without FEC is best. This is because the symbols
are longer than the static bursts, and the noise is integrated out. The typing speed is still 25 WPM. Also (provided you don't have bad multi-path as well),
check out 22 baud with FEC! Here the speed is high enough that the
static bursts may be far enough apart for good error correction.
Why do we have so many different speeds (modes)?
The ionosphere has a wide range of different properties depending on propagation conditions. Obviously the highest speeds would be
preferable, but don't always work. By providing speeds in approximate half-octave steps, and an FEC option, we can be assured of finding something
suitable. The high bands have high Doppler, but lower timing problems. Lower bands have moderate Doppler, except around sunset, but
have pronounced multi-path timing problems. LF bands are very noisy, and here and on VHF signals are very weak but stable, and so very slow
but very sensitive modes work best. A little experimentation will soon show what's best. Here's a rough guide:
In this context, 'DX' means different things on different bands. For example, on 80m DX means anywhere outside groundwave range; on 20m double-hop or long path; on LF, MF and VHF, any weak signal application. DominoEX
works a bit like a manual (stick shift) car - when the going gets tough, change down a gear!
Hint - Print this chart out and stick it on your computer!
Hint - 4 baud is good for QRP beacons on any band. Just drop the beacon message in the Secondary Text and press Transmit!
Hint - When working in a net with local and DX stations, all participants should use the lower of the recommended speeds - but remember these are only a guide.
Why such odd speeds as 11 and 22 baud? What do the names mean?
To make program operation simpler, and the program compatible with as many computers as possible, we have stayed with the four most common standard sound card
sampling rates: 8000, 11025, 16000, and 22050 samples/sec. There are 1024 samples per symbol in the faster modes, and 2048 per symbol in the slower
modes. We end up with speeds of 8000 ÷ 2048 = 3.90625 baud; 11025 ÷ 2048 = 5.3833 baud; 16000 ÷ 2048 = 7.8125 baud, and 11025 ÷ 1024 = 10.7666 baud;
16000 ÷ 1024 = 15.625 baud; 22050 ÷ 1024 = 21.5333 baud.
In all cases we round the true baud rate up or down to the nearest integer to give the name. For example, 21.5333 baud gives us
DominoEX 22. Any the wiser now?
The naming convention is DominoEX nn (where nn is the rounded baud rate) for non-FEC modes, and DominoEXFEC nn for FEC enabled modes.
Can I use DominoEX to transmit files or pictures?
At present, no. You can transmit a text file (with or without error correction) to the other operator's receive screen, where it can
be saved to file, but that's all. There are plans to add file and image
transmission, and a simple protocol for each has been defined, but at present there is no functional software to support them.
Why the name DOMINO?
Consider the similarities - can you think of others? 
- A field of white dots on a black background (the waterfall)
- Dots on a grid or matrix (frequency and time domain spacing of tone
elements)
- Black and white representing things in the digital world
- The two independent ends of the Domino tile might represent the two symbols of each
character, or the rendering of data as a numerical difference
When I change speeds, the tones come out wrong for a few seconds. Why is this?
It should be that the transmitted data is flushed when you change speeds. This would avoid the problem. However, in the interests of program
simplicity, this isn't done at present, so samples remaining in the buffer when the transmitter stopped are sent first, and of course at the new
speed the samples are wrong. Don't worry, nothing you typed is lost, as the stuff remaining in the buffer is Secondary Text.
There are two related problems. When you FIRST transmit after starting the program, nothing happens for a
second or two. This is because there is nothing in the buffer.
When you transmit after having moved the waterfall, you may hear off-frequency tones when you first transmit. Don't worry, no data is lost.
There seems to be a problem with the RX screen. Sometimes my transmitted text shows as a random series of
characters up the left margin, and the guy at the other end sees the same. Why is this?
We wish we knew! It is an idiosyncracy of the way Windows™ 'Rich Edit' boxes work, and something to do with the process of transferring text from the keyboard buffer to the transmitter queue. For some reason 'LF' characters are substituted for the real data. It has proved to be a
difficult bug to fix as it happens only occasionally, and never at all on some computers.
To avoid this problem, it seems to be best to leave the typing 'insertion point' focus in the transmit window. Where possible, use the keyboard
shortcuts rather than the mouse to control the program. The problem is more likely to occur if you cut and paste text, change focus to another program, or click in the RX window. When the problem happens, the most reliable solution is to close the program and restart. Sometimes the problem goes away if you change back to receive and then transmit again, but all the untransmitted text should be cleared.
Sometimes the Function Keys don't seem to work. Why is this?
This is one of the 'features' of the Windows™ operating system, especially XP. You probably inadvertently pressed the 'ALT' key at some point. Just press the Function Key again and it will probably work.
Why do I lose changes to some settings if the computer crashes?
The setup (including the MACRO contents) is kept in a file which is saved only when you close the program. If you make changes you want to
keep, and there is some risk of the computer crashing, close the program after making your changes,
then reopen it, or use the 'File/Save preferences parameters to file NOW' menu option. Some options always revert to defaults - operating
mode and interleaver span, for example.
If you completely mess up the preferences.ini file (for example by editing it manually, which can cause the program to crash), simply delete the file, and the program will make a new one. You will of course need to set the callsign and re-enter all your macros again.
What automatic functions can I use in Macros?
There is only one automatic function available in this demonstration program: the <EOT> 'delayed receive' function.
This can be included in any Macro, provided it is on a new line at the endof the Macro.
There are no plans to add further automatic functions.
Sometimes the program won't recognise the sound card, and I've found that there are two programs opened!
One is hidden under the other. Why is this?
There is no mechanism in this relatively simple(!) program to prevent multiple instances from being opened,
and of course the second instance is placed on top, and can't access the sound card. Simply close this one and
use the other. It is best not to launch two instances. This is most prevalent if you have a shortcut to the
program on the tool bar and inadvertently click twice. It is best to place your shortcut in the
menu structure, or put the shortcut on the desktop.
I seem to be having a problem with PTT when I send a file. What's happening?
There is a poorly understood and inconsistent interaction between the Windows functions to open a file and to open a COM port.
On most computers and operating systems there is no problem. However, due to a combination of circumstances sometimes it is found that while when transmitting and a file is then selected to be transmitted, everything
goes as expected, but when the file is selected before the transmission is started, the transmitter drops out.
The best solution is to use VOX if you meet this problem, or simply select the transmit switch on the rig before sending a file.
You may also find that PTT works if you always do things in the same order. You could also avoid sending files, of course.
Be aware that selecting a file for transmission DOES NOT automatically start the transmitter. You still have to press ALT+T or use
the Mouse TX button.
My computer has two sound cards. Can I select which one I use with DominoEX?
No, you cannot. This software is intended for the more modest computers that most Amateurs might aspire to. If you can't bear to remove one sound card, or switch your cables over, buy another computer specially for radio.
No, nor does the software support CAT equipped rigs, antenna rotators, logging software, contest modes,
inverted signals, or make the coffee!
Just what is this FEC business anyway?
Forward Error Correction (FEC) is a technique which sends extra information to allow the receiver to work
out exactly what was transmitted despite received errors. A simple example (used on SSB and CW) is where we repeat things
several times to be sure that the information gets across. With digital modes, this business can be automatic.
The technique used depends on the type of errors expected, the type of data transmitted, and the modulation
technique used for transmission.
The FEC most frequently used on HF is the Convolutional Coder,
where each bit of data is subjected, along with several previously transmitted bits of data, to two or more mathematical algorithms, resulting in two or more transmitted code bits. In this way the 'energy' of each bit is spread across several seconds of transmission.
This spreading helps the receiver handle 'burst' type interference as well as sporadic errors due to ionospheric effects. It is less effective on continuous noise associated with weak signals or manmade interference.
The receiver decoder is crucial to this process, and has to 'unwind' the coding, and at the same time assess from what it receives what was the most likely data that was transmitted. FEC isn't perfect, but this type can provide a coding gain of several dB, and provides useful resistance to bursts of errors. Unfortunately FEC comes
at the cost of reduced throughput (since more information is transmitted about each bit) and extra delay, because it takes time to spread, unspread, and process the data.
The algorithms we use for DominoEXFEC are polynomials developed by NASA, and generate two coded bits for each data bit, and
involve the most recent seven bits in each calculation. We call this NASA R=1/2 K=7. This is followed by a scrambling process used to spread
the errors out. This process uses a matrix of numbers one nibble deep and 4 nibbles wide. We call this an interleaver with L=4. The receiver
has an automatic de-interleaver and a Viterbi soft decision decoder which works with about the last 15 pairs of received bits.
Hey, wait a minute! What's this soft decision thing?
I hoped you wouldn't ask! The FEC receiver Viterbi decoder works out the best path through a 'trellis' of previously received data, in order to
work out what was sent. Most decoders of this type use integer numbers (0,1,2...) to measure the paths and work out the best path.
When we use Hard Decision Decoding, the data going into the decoder has values 0 or 1 (or -1 and +1), again integer.
The Hard Decision Decoding process assigns 'soft' or floating point decimal numbers to the data going into the decoder, and uses floating point path calculations. The idea is to give the decoder some idea of how good the 'quality' of the data bits is. For example, if we're
very sure the data is 0 or 1, we might assign values of -0.9 or +0.9. If we are not very sure (pehaps lots of noise, or some Doppler error), we might assign only -0.1 or +0.1. This helps the decoder decide which possible decision is more reliable, which can lead to more coding gain.
Choosing approriate 'quality metrics' with which to multiply the incoming data is an experimental process, and the algorithm you choose may be better for
some conditions that others (it can even be worse than 'hard' decoding!). The algorithm we currently use takes the absolute remainder of the IFK+ detection process, scales it to 0 - 1 and subtracts it from 1. This value is an indication of the amount of instantaneous Doppler on the data,
and reflects the NVIS multi-path effects quite well. We then multiply the incoming data bits by this quality metric before passing them
through a soft value de-interleaver consisting of a four-plane floating point array to the Viterbi soft-decision decoder. The soft data passes through the de-interleaver so that quality metrics (which are nibble related) are correctly reflected at the bit level once de-interleaved. Well, you asked!
With FEC on, there seems to be quite a delay before text I type appears on the screen. Why is this?
When FEC is used, the data is fed through a coder which is 7 bits long, followed by an interleaver (to jumble the bits) 16 bits long, and so a delay is introduced. At the receiver, the de-interleaver is also 16 bits long, while the Viterbi decoder works back about 15 bits. The total delay is about 4 seconds at 11 baud.
In a related problem, when you tune in a signal with FEC, it will take several seconds for viable text to appear. You will see the Confidence Meter rise before the text appears.
With FEC on, does the transmission delay mean some characters are lost at the end of the over?
Certainly there is this risk. When you stop typing, leave a few seconds for the TX buffer and coders to be flushed before
going back to receive (watch for the last text to appear on the receive screen). If you use VOX or PTT control, the easiest way to achieve this is to use the RX macro which sends the sequence.
The transmitter will not stop until this sequence has been flushed from the coder and transmitted. You can also add this sequence to any
macros you define or type it from the keyboard.
With FEC on, is the signal any wider?
No, the signal width stays the same with FEC on, as the modulation is the same. The ITU definition remains the same as well.
The typing speed will be halved.
With FEC on, is the signal encrypted, and so illegal on ham bands?
The FEC coding uses two standard NASA algorithms, which are public domain (we use R=1/2 and K=7). The interleaver is also public domain (published on the
MFSK16 web site, we use L=4 by default). There is no encryption. The FEC mode is quite legal - the same character encoding is used in MFSK16. Anybody with the DominoEXFEC software or a recent version of MultiPSK can copy the signals, which is more than can be said for some commercial
modems used by Amateurs!
There's a really cool 'Auto-FEC ON' feature, but no 'Auto-FEC OFF'. Why is this?
Between overs, the FEC would switch off again if there was an 'Auto FEC OFF', and then you'd need to push
the button to transmit using FEC, the same as the station you are working. Further, if the received signal faded, there is the risk that the FEC would turn off, and given
the delay in getting FEC started, you'd lose more text than simply waiting for the signal to reappear from the fade.