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
_______________________________________________
RTTY mailing list
RTTY@contesting.com
http://lists.contesting.com/mailman/listinfo/rtty
|