[RTTY] Use of Oscilloscope In RTTY

[Kok Chen]

On Nov 29, 2007, at 11/29    9:20 AM, John MacFarlane wrote:

> Are 'hardware' oscilloscopes commonly used these days for tuning and
> monitoring RTTY signals - is it essential or nice to have?

Many years ago, I'd used a Textronix instrumentation scope (a 5"  
rectangular tube that had fixed gain x, y and z amplifiers, with no  
timebase), tapping the Mark and Space signals from a modified KAM  
Plus.  The mark and space signals are also rectified and fed into the  
z channel to prevent phosphor burns when the signal is static or near  
static (i.e., blanked the display when there is no signal).

The difference between being able to tune with crossed bananas and  
with the silly LEDs on the TNC was like night and day.

> I know that some software has a proxy scope that can be displayed  
> on a computer
> screen but from time to time I see references to the use of test
> equipment.

Many years ago (before I wrote cocoaModem) I replaced said hardware  
with a program that did nothing but behaved like a two channel  
crossed banana display.  The two crossed ellipses are used during  
split pileups on a dual receiver FT-1000MP, one for tuning the DX's  
QRG and the other to search for his QSX.

The advantage is that with LCD displays, there is no chance of a  
phosphor burn.  And once you "build" one, you can have as many  
"scopes" as you like for no extra cost.

I had also added a variable width filter to get either thin or thick  
ellipses.  Again, with no extra "parts" but to change numerical  
coefficients for the filters.

If you have used crossed ellipses, you will notice that it is easier  
to guess where an off tuned station is when they are on one side of  
center, if you have a wider bandwidth (fatter ellipse).  Whereas a  
narrow filter is useful to get a more accurate narrower ellipse to  
eek out that fraction of a dB of SNR for the demodulator.

> Is a piece of hardware 'better' for tuning-in a signal than doing  
> it by
> eye on the computer screen - or relying on a software scope?

IMO, there is no reason today why software implementation cannot beat  
hardware implementation.  Not just as good, but beats the limited  
things you can do in hardware before it costs too much.  The crossed  
ellipses in cocoaModem even mimics phosphor decay :-).

That being said, there are a couple of things to look out for when  
you brew you own software "scope."  The most important aspect is the  
latency of the DSP.  You want to get small packets sent from the  
sound card with as little latency as possible to the computer and the  
program has to display them (preferably without waiting for complete  
packets).  In Windows, it might be worth using the ASIO library  
instead of the resident Windows library.  The MacOS Core Audio  
library already provides extremely low latency and I have not found  
the need to replace with ASIO.  See the following article on the  
issue of latency:

http://www.digitalprosound.com/Htm/Articles/April/Audio_Latency.htm

Any latency of the order of 50 ms or more will cause a hysteresis  
effect -- if you tune the radio with a knob, you might overshoot the  
tuned position unless you slow down the rotation rate.  This never  
happens with hardware, and should not happen in carefully designed  
software in this day and age of multi-core multi-GHz computers.

Notice that at 11025 samples/second, a sound card with a 512 sample  
packet will already give 46 ms of latency.  So, if you can't get a  
smaller buffer size, go to a higher sampling rate.

This does not even count the latency through the DSP stages, and  
depending on how many buffer hand offs there are, each one adding  
another 46 ms.  IMHO, a crossed ellipse should be implemented in its  
own thread.  The actual Baudot decoding can suffer a longer latency  
(after all, each Baudot bit is already 22 ms), but the tuning tools  
should never have to.

IM(another)HO, cross ellipses should not go through an FIR or  
Goertzel filters, since they too will create additional latency.  I  
use an IIR filter, then postprocess the phase shift from the IIR by  
using geometric X-Y rotation.  Phase shifts will cause the crossed  
ellipse to be skewed, but in software, you can deskew them using  
affine transforms.

73
Chen, W7AY