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