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