RTTY
[Top] [All Lists]

[RTTY] Character Wait

To: RTTY Reflector <rtty@contesting.com>
Subject: [RTTY] Character Wait
From: Kok Chen <chen@mac.com>
Date: Mon, 3 Mar 2008 10:29:32 -0800
List-post: <rtty@contesting.com">mailto:rtty@contesting.com>
On Mar 3, 2008, at 9:17 AM, Charles Morrison wrote:

> Haven't really figured out a good reason for the Diddle Wait yet, it  
> just
> slows the diddles down when not sending text.


This so called "character wait" and "diddle wait" appears to be  
nothing more than stretching the stop bit (delaying the start bit of a  
subsequent character).  It is as if you have not turned diddles on and  
then proceed to type at a constant rate that is slower than 6.06  
characters per second.

As to what it does for you, I can imagine that stretching the stop bit  
can help to recover sync a little quicker each time a start bit is  
lost in the noise.  Lost start bits is a nemesis of asynchronous  
streams in a noisy environment, such as RTTY reception.

In RTTY, we are concerned with character error rates, and not directly  
with the bit error rates.  With synchronous data streams, the two are  
have a simple relationship.  With an asynchronous stream that uses  
start-stop bits (such as RTTY), the relationship between character  
errors and bit errors is not as simple and it depends on when you can  
again reliably "latch" on to a correct start bit (this is why non- 
integral stop bits really help to identify a real start bit from any  
other random bits).  It depends on what is being typed, and it could  
take a few character times before you pick up the correct start-stop  
rhythm again.  A single bit error, if it strikes the start bit, can  
therefore cause multiple character errors.

However, there are more efficient methods to counter start bit losses  
than to stretch the stop bit, one such countermeasure is to treat the  
asynchronous RTTY stream as a pseudo synchronous stream.  Those  
running the "flywheel" in RITTY, will benefit from a Baudot stream  
that uses 1.5 stop bits and with diddles turned on.  Turn off the  
diddles, and the RITTY flywheel fails.  Slowing the stream down will  
similarly not help RITTY's flywheel, and in fact might harm its  
usefulness.

Indeed, it is easier for an asynchronous decoder, through  
correlational methods, to identify non-integral stop bit durations  
such as 1.5 stop bits, than if you had stretched the stop bit to  
precisely 4 or 5 integral bits.

In short, there are many better ways to achieve better robustness  
against lost start bits than by slowing down the transmission rates.   
My preference is for everyone to stick to precisely 1.5 stop bits and  
let innovations in the RTTY decoders improve the start-stop problem.   
It is much better for the designer of the decoder if there is a known  
standard that people follow for sending the Baudot streams.

Anyhow, the discussions in the last few days has been quite useful for  
me in that it has forced me to think deeper about the problem of start  
bit losses and there are a couple of ideas that I have generated which  
I will be testing out in my homebrew software in the future.

73
Chen, W7AY

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

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