[RTTY] dashes vs. no dashes

[Richard Ferch]

The situation with UOS is actually more complicated. There are two 
different places where you can select UOS in MMTTY, one on the main window 
that only affects receive, and one under the Options/TX tab that only 
affects transmit. How these interact with each other depends on whether the 
exchange is mainly text (as in normal communications, or for W/VE stations 
in the Roundup), or mainly numbers (as in serial number contests, including 
DX in the Roundup), but you need to set them both to get the full advantage 
of UOS. Let's go through a few examples:

First, suppose my long exchange message for the Roundup contains 599 ON ON 
ON , which looks like 12 characters. Actually, it's a total of 14 
characters: [FIGS]599[SP][LTRS]ON[SP]ON[SP]ON .

If the[FIGS] character is lost to QRM/QRN, this comes out as TOO ON ON ON, 
which most receiving stations will be able to figure out. However, if the 
[LTRS] character is lost to a one-character noise burst, the decoded text 
becomes 599 9, 9, 9, -,$# -)) !9))928,& 53/5 8' -!!3:53$ -' 23)). Oops, the 
last part of that sentence should have read "and all following text is 
affected as well" - that's what happens without UOS ;-) Using a long 
message with lots of repeats (like the three ONs in this example) does not 
help at all.

For normal communications, allowing the loss of a single character to cause 
unintelligible nonsense until the next punctuation or number is sent is 
intolerable. There is a simple solution: UOS on receive (the UOS button on 
the main MMTTY window). With that button pressed, if the [LTRS] character 
is lost the decoded result is 599 9, ON ON and the following text is OK. 
Overhead cost: zero (the receiving CPU may spend a few more microseconds 
working instead of idling, but the net effect is still zero).

Now, however, what happens in the WPX RTTY contest? My message (let's drop 
the extra repeat) is 599 001 001 - 12 characters: [FIGS]599[SP]001[SP]001 . 
If the [FIGS] is lost, this becomes TOO PPQ PPQ. Does UOS help at the 
receiving end? Nope, it's still TOO PPQ PPQ. And that's not all. With UOS 
on receive and NO ERRORS AT ALL, this message is received as 599 PPQ PPQ - 
ouch!

The solution to this is to check the UOS box in MMTTY's TX options tab. The 
transmitted text becomes 14 characters - 
[FIGS]599[SP][FIGS]001[SP][FIGS]001 . Those two extra [FIGS] characters 
solve the problem with the UOS on receive, plus they increase the 
reliability even for receiving stations who do not use UOS. The worst that 
can happen with a one-character hit is TOO 001 001 or 599 PPQ 001 or 599 
001 PPQ, regardless of whether the receiving station uses UOS or not. 
Overhead in this example is about 0.3 seconds (two extra [FIGS] characters).

In other words, if implemented completely on both RX and TX, UOS avoids the 
problems caused by lost [LTRS] characters in normal text at the cost of 
some extra [FIGS] characters on transmit during all-number sequences.

Some people don't like the cost of the extra two [FIGS] characters, and 
came up with a way to shorten the WPX message even when UOS is used: change 
it to 599-001-001 . This is all in FIGS case, so it avoids the extra [FIGS] 
characters. The problem is, by finding a sneaky way to avoid the extra cost 
of UOS, it also loses much of the benefit. A single lost [FIGS] character 
results in TOOAPPQAPPQ, and UOS is powerless to fix it.

Experienced receiving ops will know what TOOAPPQAPPQ means without asking 
for a repeat. They will also know that a single right-click with the mouse 
in the right spot in the MMTTY receive window will change this to 
599-001-001 on the screen, and then depending on your software you may be 
able to use a left-click to pick out the serial number. However, 
inexperienced ops (or lazy ops, or tired ops after a long night of non-stop 
operating) will ask for repeats. You don't have to get too many requests 
for repeats to completely use up any time benefit you may have obtained by 
avoiding the extra [FIGS] characters (a single repeat request/response 
cycle will cost a minimum of about 4 seconds vs. the 0.3 seconds saved per 
exchange). And even without noise hits, if the receiving station is using 
software that does not automatically pick out the serial number between the 
dashes, you may have to wait for them to figure out and type in your 
exchange manually.

A further comment: suppose that I, not understanding how all this works, 
decide to change my Roundup message to 599-ON-ON (by analogy with the 
599-001-001 example). This looks like the same 9 characters as it would be 
with spaces, but it isn't; it is actually 13 characters as compared to 11: 
[FIGS]599-[LTRS]ON[FIGS]-[LTRS]ON . Those extra characters aren't a 
complete loss - they do improve reliability, because the possible effects 
of a single-character noise hit are more limited. But the cost/benefit 
ratio for this particular example is worse than it is with UOS and spaces 
(and it becomes much worse with a longer message containing three ONs 
instead of two).

To reduce the UOS overhead, when the exchange is all numbers you could try 
sending it with one dash and one space: 599-001 001 . This gets most of the 
benefits of UOS with half the overhead (but be careful: do NOT use 599 
001-001, which is just as expensive but less reliable; both copies of the 
serial number can be lost with a single error, whereas with 599-001 001 at 
least one of them will get through unless the error rate is high).

One final point: if you absolutely refuse to incur the extra overhead 
caused by using MMTTY's UOS on transmit option, then please use dashes 
between numbers instead of spaces, because at least that helps avoid 
fouling things up for the 95% of us who use UOS on receive (the 
perfect-copy 599 PPQ PPQ I mentioned in my fifth paragraph).

73,
Rich VE3IAY


-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.1.371 / Virus Database: 267.14.9/217 - Release Date: 30/12/2005