RTTY
[Top] [All Lists]

Re: [RTTY] Suggestion for upcoming RTTY Roundup

To: "Tyler Stewart" <k3mm@verizon.net>,"'robert'" <tf3rb@internet.is>, <RTTY@contesting.com>,"'Shelby Summerville'" <k4ww@arrl.net>
Subject: Re: [RTTY] Suggestion for upcoming RTTY Roundup
From: Bill Turner <dezrat1242@ispwest.com>
Date: Sat, 31 Dec 2005 13:00:49 -0800
List-post: <mailto:rtty@contesting.com>
ORIGINAL MESSAGE:

At 12:15 PM 12/31/2005, Tyler Stewart wrote:
>Guess it depends on how smart your decoder is
>(both computer and human software) and whether you can type well which way
>works better.  My preference is for dashes...


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

It's not a question of smart or dumb decoders, it's an inherent issue 
with Unshift On Space (USOS). What you are doing by sending dashes is 
foiling USOS, not a good idea, IMO. Nearly every TNC and software 
uses USOS by default, for good reason.

For those new to RTTY, USOS resets your FIGS/LTRS case back to LTRS 
every time a space is sent or received. When copy is poor because of 
QRM/QRN and dashes are being used, the reset never happens and you 
get print like this:  599-48-48-48 instead of 599-RI-RI-RI. If you 
send 599 RI RI RI (without dashes) then USOS can reset back to LTRS 
with each space and you will get at worst 599 48 RI RI.

The idea of using dashes goes back to the early days of RTTY 
contesting before anyone realized the value of USOS. WF1B, bless his 
heart, included dashes in his default macros and people have been 
using them ever since. Sending dashes does indeed make sending 
faster, but you pay the price. I've been harping on this issue for 
years and gradually more and more people are seeing the light. Try it 
and see if the number of requests for repeats falls off dramatically. 
I'm betting you will change too.

To sum it up:
Dash = bad.
Space = good.
:-)

73, Bill W6WRT

_______________________________________________
RTTY mailing list
RTTY@contesting.com
http://lists.contesting.com/mailman/listinfo/rtty

<Prev in Thread] Current Thread [Next in Thread>