[RTTY] WPX suggestion
Kok Chen
chen at mac.com
Fri Feb 8 11:45:26 EST 2013
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
More information about the RTTY
mailing list