What about variations on a theme, like:
W1ABC 599-001 001 W1ABC
W1ABC 599-001 001-001 W1ABC (used under poor conditions)
I've tried these, just to experiment. Sometimes they seem to work OK,
while other times they seemed to confuse people.
73,
Kermit, AB1J
In a message dated 2/8/2013 4:45:22 P.M. GMT Standard Time, chen@mac.com
writes:
On Feb 8, 2013, at 4:19 AM, Bill Turner wrote:
> Please, please, please, NO dashes. While it does speed up sending, it
> interferes with the USOS (Un Shift On Space) function which most folks
> agree is a much better thing to have. USOS greatly reduces requests for
> repeats, especially when there is QRM and QRN.
It is another myth that an extra character helps when you are transmitting
all numerals.
The extra FIGS that follows the Space actually hurt. The reason is this:
if the probability of the error of a single character is Q, then the
probability that you do *not* have to repeat an exchange of N characters (all
N
characters survives) is (**N is the power of N)
1 - (1-Q)**N
For example, if Q is 0.1 and N is 8 (e.g., 599-123, i.e. transmitting
<figs>599<dash>123), then the above probability is 57%.
By transmitting that extra character, the probability that all characters
are received correctly is now
1 - (1-Q)**(N+1)
Or, using the same probabilities, the probability of not having to repeat
is now 61%.
The above with random errors.
Lets see what happens when a dash is specifically replaced by Space that
is followed by a FIGS, and we allow partial reception to count (i.e., the
other person can still see the 3 digit that what was sent correctly -- it not
safe, but I present this in case it is further argued that a FIGS somehow
will magically transform a 599-123 into something readable again).
Recall that the dash can be received wrongly, but unless it turns into
LTRS, it will just be printed as some other FIGS character, e.g., into a dot.
Recall that a dash is Baudot 0x03 and a LTRS is a Baudot 0x1F. The
Hamming distance is 3. So the probability of a dash turning into a LTRS is
very
low. I.e., if we use the same Q above of 0.1 (10% of the characters are
wrong), the probability of a dash turning into a LTRS is 0.3%.
Lets see what happens when you send the Space followed by a FIGS. The
Space can still get mangled and turn into something other FIGS character. But
lets look at the FIGS that has to also be sent. Given the same Q as
above, that probability that the FIGS can be turned into a non-FIGS character
is
9.7%! When that happens, you will receive "599 xQWE" where x is
anything but a FIGS character.
What if the space is mangled? well, it is the same as if the dash is
mangled... and guess what, you print exactly the same thing as what dash
message. I.e., If the space is mangled into a dot, you copy 599.123, which
you
also copy 599.123 if the dash turned into a dot. Remember that "123" only
prints incorrectly for the dash guy when the dash turns into a LTRS, and the
receiver prints 599QWE.
The only other possibility is if the preamble FIGS is received as
something else (say, as a dot).
The Space guy is received as ".TOO 123" and the Dash guy is received as
".TOO AWE" Most of us (and some software) will know what either means, and
not need a repeated exchange, but a newcomer to RTTY will be scratching his
head in both cases, and ask for a repeat.
So, do yourself a favor. If the exchange consists of only numerals, use a
dash in place of a space. If the exchanged is mixed, e.g., "599 NH" then
don't use a dash. But, don't do it blindly. Dashes are not always
better, but in the case that the original posted presented it (all numerals)
it
is better.
73
Chen, W7AY
_______________________________________________
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
|