On Jan 13, 2012, at 2:33 AM, WW3S wrote:
> I had at least one qso that seemed very slow.....when I asked about it, I
> think he said he had a K3 and was sending RTTY using a key?
Not a straight key, but a Morse paddle.
In FSK mode, the K3 lets you key input using a Morse paddle. Regular Morse
(e.g., di-dah) from the paddle is converted to serial Baudot (e.g.,
start-1-1-0-0-0-stop) code to modulate the transmitter.
The problem is the way the K3 handles diddles (at least in the older firmware;
I have no idea if the situation has since been corrected).
In the firmware version of the K3 that I use, diddles are sent as usual if your
paddle is idle and the transmitter has finished sending the last character that
you have entered.
However, instead of the RTTY standard of sending a diddle *immediately*
whenever the modulator is idle, the K3 does not send a diddle right away.
So, if you are sending something long in Morse, like a zero (paddle has to go
dah-dah-dah-dah-dah) the transmitter has finished sending the previous
characters, while the next character has not yet completed. While waiting for
you to finished paddling, the transmitter appears to rest in the Mark state.
The next character is finally sent when the op has finished paddling.
With standard RTTY implementations, the diddle is sent immediately whenever the
transmitter is idle. Always. No exception. That is why RTTY sounds like RTTY
even for a very slow typist.
It does not even have to be a long Morse character to cause a stutter, since
most CW ops cannot send at an average rate of 60 WPM to keep up with 45.45 baud
RTTY.
It is for this reason that a K3 when keyed this way will "sound" slow. (Phil,
GU0SUP had detected it by ear a couple of years ago when the K3 implemented
this "feature." The unacceptable part of this is that one the technical
reasons for using diddles is completely wasted by this implementation.
One reason for diddles is to allow tuning when the sender is idle. Another is
to maintain the proper bias in the Automatic Threshold Corrector (ATC) circuit
(the K3 implementation will incorrectly skew the ATC threshold at the receiver).
But what many people don't realize is that a diddle creates a
pseudo-synchronously framed signal. I.e., the time between start bits is a
constant, at all times. This allows the implementation of better character
frame synch schemes, including what RITTY calls "digital flywheel."
I don't know what the exact mechanism in RITTY is, but the idea around
"pseudo-synchronous" character framing is that you use multiple characters'
start (and stop) bits to determine character synch. The wider the time window
that you use to detect frame synch, the longer a QSB (or loss of
synchronization in a flutter) the demodulator can handle.
By stuttering, the sender is doing himself a big disfavor because modems at the
other end that implements "pseudo synchronous" framing cannot take advantage of
the diddle. Imagine missing contact with a P5 DXpedition, just because the
diddle was not implemented correctly.
When you lose start-stop synch, a constant stream RTTY takes between 2 and 4
character most of the time to recover synch again. Because of that, when you
are right at the threshold of FSK demodulation, losing synch is one of the
biggest contribution to print errors.
So, do yourself a favor if you own a K3 -- use a real modem. The K3's internal
RTTY demodulator is also quite a few steps worse than standard software
demodulators; so not only the P5 might not copy you, you might not be able to
copy the P5 in the first place! :-)
In my investigations, I have found that under propagation that produces
Flutter, a good pseudo-synch implementation can get a cleaner copy 6 dB to 10
dB before a start-bit only decoder can. I.e., you need 4 times to 10 times
less power at the sending end to achieve clean copy. Pseudo-synch also helps
immensely with NVIS type propagation on the lower bands.
73 es HNY
Chen, W7AY
_______________________________________________
RTTY mailing list
RTTY@contesting.com
http://lists.contesting.com/mailman/listinfo/rtty
|