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
_______________________________________________
RTTY mailing list
RTTY@contesting.com
http://lists.contesting.com/mailman/listinfo/rtty
|