[RTTY] Zone sent as letters?

[Kok Chen]

On Sep 28, 2009, at 9/28    6:50 AM, Bill, W6WRT wrote:

> If QRN or QRM wipes
> out the FIGS shift just before the 599, either of the above will  
> print as
> TOOAWTAWT.

As I have mentioned this more than once already, Bill, if a symbol  
error (what you refer to as QRN or QRM) can wipe out the FIGS that you  
mentioned, it can also wipe out the extra FIGS that USOS inserts after  
your space delimiter.  I know my English is deficient and I can't get  
this through clearly to you.

I.e., if a symbol error causes the FIGS that USOS sends after the  
space, you will see things ranging from "599 WWT" to "599 TWT" or "599  
RWT", which could be interpreted as 225, 525 and 425.  Whereas the  
case that you mentioned above can only be interpreted as "599-25", no  
matter what the FIGS is changed into.

You are selectively harping on the first FIGS being smashed and not  
addressing the issue of the extra second FIGS from being smashed.    
What is so special about the FIGS which USOS inserts that makes it so  
special that it won't get smashed?  Nature doesn't work that way.

The FIGS in the two cases (dash delimiter or space delimiter) have  
equal probability of being smashed -- unless you can present a  
mathematical basis of why a space character before a FIGS somehow  
makes that FIGS more immune to a symbol error (I can't think of one;  
but you are a more experienced RTTY op that I am.)

(Neither are you addressing the basic fact that the more characters  
there are, the higher the probability of an error (thus confusion)  
event.)

When there is an error hit, the FIGS does not just disappear unless it  
gets converted to another non-printing Baudot character; the FIGS gets  
converted into another printing character.

When a FIGS at the start of the dashed exchange is smashed, you print  
"xTOOAWT" on the screen.  When the extra FIGS gets smashed, you print  
"599 xWT" on the screen, where x represents the character that the  
FIGS is changed to.

So, which is less confusing if the FIGS is converted into a W, which  
is a Hamming distance of one away from a FIGS character?  I prefer  
something like WTOOAWT to something like 599 WWT, especially when the  
exchange involves a QSO number.  WWT can be mistaken for a "225"  
exchange.

You might prefer WWT to something like AWT, in which case I agree that  
using a space character is better for you.

Notice that no matter what the FIGS get converted to, a dash delimited  
exchange always prints as AWT (-25), even if there are multi-bit  
errors in the FIGS.

If the FIGS after a space delimiter is smashed into another printable  
character, you can print a large number of things; WWT (225) and more  
bizarre exchanges, such as JWT and ZWT when there is a one bit error.

When there are multi-bit errors, the extra FIGS when you use the space  
delimiter can now print even more confusing exchanges.  For a Hamming  
distance of two, what gets printed includes TWT (525), RWT (425), UWT  
(725), etc.

Heck, you could even get lucky and the <space><FIGS>25 in the space  
delimiter case comes out as " AWT" ("A" is Hamming distance of 2 away  
from FIGS.)

If the start bit of the FIGS gets smash, then the question is moot  
since most decoders don't do predictive synchronization by looking  
ahead at successive start bits.  Those that do will have a lag of a  
few characters, so you probably would want to turn the function off  
during a contest anyway because of the delay.  When a start bit is  
smashed, you loose quite a few characters and in either case a repeat  
of the exchange is needed.

I have wasted enough of everybody's time on this already and will not  
continue this thread unless there is a specific question that someone  
addresses to me.  I apologize for repeating myself and have nothing  
newer to offer.  I just wanted to dispel the pronouncement that a  
space delimiter used in conjunction with USOS is a "must" for  
everybody to adopt.  I have already earlier mentioned that a dash  
works equally well whether you use USOS, and its use is completely  
USOS-neutral, working equally well between folks who use USOS and  
folks that do not, while the space delimiter produces "miss shifts"  
between USOS and non-USOS systems that cannot be resolved even after  
an indefinite number of exchange repeats.

73
Chen, W7AY