[RTTY] K3 RTTY Decode

[Kok Chen]

On Mar 17, 2016, at 9:16 PM, Hank Garretson wrote:

> Good friend K1GQ wondered out loud about real data comparing K3 RTTY decode
> to software decoders. Here is fifteen minutes of real data.

(Hi Bill.)

Long ago, I had pondered how to objectively test built-in PSK31 and RTTY decoders in the Icoms.  Later, Elecraft also decided to add built-in decoders.  

From my *subjective* experience, for poor signals, the built-in RTTY decoder in the K3 did not come anywhere close to what I could decode on the desktop.  With verticals and wires, all of my received signals have poor SNR :-).  But I wanted objective numbers, like how many dB worse.  

The key to testing RTTY demodulators is to be able to test with a set of known and repeatable SNR, and then repeat for the various ITU parameters (multipath, Doppler shift, Doppler Spread, etc).  The audio output from what is called an HF Channel Simulators is sent to different modems.  

This is like sending an audio recording to different modems, but you are also able to also change the SNR, etc, to measure the dynamic nature of the modems.

(See RTTY Compare by VE3NEA: http://www.dxatlas.com/rttycompare/ . For those who have not noticed, Alex has added 2Tone and GRITTY's Selective Fading curves.)

So, is there also a way to objectively test the built-in decoders in superhet receivers the same way we objectively test modems?

I concluded that it is indeed possible, but only after I had stopped using superhets.  My K3 and KX3 have been gathering dust on the shelf for a few years now.

The way to do it is to feed the audio output of an HF channel simulator (PathSim on Windows, cocoaPath on Macintosh, KC7WW's simulator on Linux) into the audio input of a QRP SSB transmitter.  

In the case of a DUC type SDR transmitter, you can send the I/Q output from cocoaPath directly to the I/Q input of the DUC.  PathSim unfortunately does not have I/Q output; so you will still need to use the SDR as an SSB transmitter with PathSim.

For RTTY, the HF Channel Simulator audio output is basically a keyed AFSK tone pair using a known generated message.  

The audio also includes a known noise floor, all of which will be sent to the transmitter.  You therefore want to use a transmitter with very low IMD.  The various channel simulators are capable of including flutter, multipath and selective fading.  You also need to run very low power since the noise floor of the channel simulator is wideband.

To avoid a pink ticket, don't connect that transmitter to an antenna.  You can really confuse a nearby ham with an S9+80 dB signal that also comes with flutter! :-). 

With appropriate attenuation, feed the QRP transmitter directly into the input of the receiver (device under test).

You can now use Alex's RTTY Compare (or other programs) to produce similar plots to what he has on his web site.

With the Channel Simulator set for AWGN, you are able to very objectively compare the SNR of one decoder vs another.  It is the only way in the professional world to compare modems.  I believe David G3YYD fine tunes his 2Tone decoders by using PathSim to compare different versions.  

By adding flutter and selective fading, you can measure how much selective fading and flutter further degrades the copy.

So, if someone wants to completely characterize the performance of the built-in RTTY decoders in superhets, there is a way :-).

73,
Chen, W7AY