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
|