[RTTY] Monitor with OScope?

[Kok Chen]

On Sep 17, 2006, at 8:33 AM, Bill Turner wrote:

> Speaking of MMTTY, it does have a virtual oscilloscope built in, but
> it has sort of a "rubbery" feel to it and a real scope would be
> better, IMO.

Warning: long description coming up for RTTY freaks who care :-).

That "rubbery" feel probably comes from a delay time between when the  
sound sample arrives and when it finally reaches the human eyes.  If  
the delay is long enough, the cross ellipse is useless for fast  
tuning because you get get a tuning hysteresis effect (overshooting  
the VFO) unless you tune very slowly.

The delay can come from many sources.  One is what the audio/music  
guys call "latency" in the operating system, another is latency from  
the size of buffer and sampling rate that the program uses, and it  
can also come from how you'd implement the filters and display.

There is a palpable operating system latency difference between MacOS  
9 and MacOS X, for example.  MacOS X has no latency to speak of.  In  
pass-through mode, you can use a microphone to record music while  
monitoring it on the digital output on headphones and you don't even  
hear an echo between the real music and the ones you hear in the  
headphones.  There is a setting for some sound drivers (such as the M- 
Audio Transit) on MacOS X to choose how much latency is allowed.   
This controls the buffer size used in the physical transfers on the  
PCI, USB or Firewire bus.  The smaller the buffer, the lower the  
latency, but you are also using more processor cycles to handle the  
interrupts.

The next culprit is the buffer size and sample rate used by the  
program itself.  For example, if you choose 4096 samples per buffer  
at 11025 samples per second, you have to wait 0.37 of a second before  
a buffer is passed from the operating system's audio implementation  
to your program.  A delay this long will make a crossed banana  
useless as a primary tuning tool.

Finally, when you have computed the actual spot on the x-y scope, it  
depends on how fast you want to refresh the display on the monitor.   
If the crossed banana occupies a 2" x 2" area on the screen and the  
backing buffer is being refreshed at over 30 times a second, it can  
use a hefty amount of processing power unless you also have a fast  
graphics card (like what gamers use on their computers).

With cocoaModem, I use 512 sample buffers at 11025 s/s and had  
purposely chosen a 3rd order IIR filter to implement the crossed  
ellipse instead of using an FFT (which might need thousands of  
samples to implement the mark and space filters for the crossed  
banana) or FIR filter.

The actual demodulation of text in cocoaModem is much more involved  
and goes through a much longer pipeline but people don't usually mind  
text appearing a half second after hearing a tone shift with the  
ears.  The crossed ellipse and waterfall displays in goes through a  
separate and extra processing thread and uses oodles of processing  
power (especially to refresh the display), but modern computers will  
just sit idle if you don't use it up :-).  I could have for example  
used the same mark and space signals from the matched filter used in  
the demodulator and save some compute power, but that would also make  
the cross ellipse useless for fast tuning (when I play in contests, I  
am an S&P type op and tuning speed is most important to me).

Getting the mark and space ellipses to be at right angles with one  
another, the mark and space filters need to have a 90 degrees  
relative phase shift 170 Hz away.  With a short IIR filter, this is  
tough to control when you also want to have independent control of  
the fatness of the ellipse (the eccentricity of the ellipse, for you  
pedantic guys), I simply use a geometric transformation to get the  
two ellipse to be orthogonal at the FSK shift.

I.e.,

Xmark' = a.Xmark + b.Xspace
Ymark' = c.Ymark + d.Yspace

This is similar to the pot that we used to use with oscilloscopes to  
inject some of the mark into the space signal and vice versa to get  
the two to be at right angles when a 170 Hz FSK signal is received.

So if you are implementing a digital crossed banana display yourself,  
these might be things to look out for.

We are so used to the "instant" reaction of oscilloscopes so poor  
digital implementations are the most obvious.  I used to use a  
surplus HP instrumentation X-Y(z) scope, with the z controlled by the  
amplitude of the signal so there is less chance of a phosphor burn- 
in :-)

The mark and space delay through a KAM-Plus for example is really  
small and works really well since it uses a couple of 6th and 8th  
order switched capacitor filters for the input bandpass filter and  
mark and space discriminators.

To simulate a fading phosphor, I pass a pixel location into a delay  
line when it is drawn on the screen and remove that pixel point when  
it reappears at the output of the delay line.  Abrupt delay line  
rather than an exponential phosphor decay, but looks ok.

I also have a AGC on the ellipse size (the AGC signal simply controls  
a+b and c+d in the equations above). This adds an extra 10 dB or so  
to the AGC within the rig to get the weaker stations to appear (but  
really weak stations are best tuned using a spectrogram - a.k.a.  
"waterfall").

When implemented properly, a crossed banana through a digital modem  
can be much more customizable than an analog one.

Between the geometric transformations and the filter bandwidths, it  
is very easy to make the display to "look just right."  In fact with  
cocoaModem, if the primary tuning mechanism is the cross ellipse  
itself, I use a fatter ellipse (easier to find the direction to tune  
in a badly off tuned signal).  If the primary tuning mechanism is a  
spectrum or a waterfall, and the crossed ellipse is being used as a  
fine tuning mechanism, then I use a narrower ellipse.

Finally, with LCD monitors -- no permanent phosphor burn-in!

73
Chen, W7AY