[RTTY] What is that funky sound?

[Kok Chen]

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