[RTTY] RTTY

[Kok Chen]

Gary,

I did not listen to the contest this time.

The next time you operate a contest, please send me an email ahead of time and I will try to make time to record and analyze what could be wrong.  The path between Oregon and Alaska is usually very good.  Alternately, perhaps someone has recorded you this time, in which case I probably can use their recordings.

If other folks are copying you without any problem, your baud rate has to be within a few percent of being correct, otherwise they will start throwing lots of decoding errors when conditions are even a little rough (like a signal from KL7-land :-).  So baud rate is likely not to be the problem.

Changing the number of stop bits will change the WPM (without changing the baud rate).  The difference between 1 stop bit (7 bits per character) and 2 stop bits (8 bits per character) can slow you down noticeably (almost 15%).

The other possibility is your exchange itself.  If you are using a space character in between two numbers, each one will introduce an extra FIGS character if you have USOS turned on.  This BARTG is a numbers only exchange, so there could be many extra FIGS being thrown around.  If an exchange has 25 characters, and there are just two extra FIGS in there, you slow down by 8%.  For example, if others are sending "599-0123-0123," and you send "599 0123 0123," you can be perceived to be slower.

"Someone" in the contesting community should whip up a Java tool to figure out the number of seconds an exchange takes when you enter the actual exchange and states such as number of stop bits and USOS condition.  Perhaps such a tool should even be embedded into RTTY contest programs.   Most RTTY ops know how to count them, but it could be an eye opener for folks who are not familiar with stop bits and LTRS/FIGS shifts.  Often, it is not a matter of choosing a shorter exchange for the human reader, but on how you create the exchange for a machine.

73
Chen, W7AY