I wonder how " l o n g " time it takes to send those extra two
characters in the exchange
----- Original Message -----
From: "Richard Ferch" <ve3iay@rac.ca>
To: <rtty@contesting.com>
Sent: Sunday, January 01, 2006 3:52 PM
Subject: Re: [RTTY] dashes vs. no dashes
> 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
_______________________________________________
RTTY mailing list
RTTY@contesting.com
http://lists.contesting.com/mailman/listinfo/rtty
|