[RTTY] Best RTTY Program

[Kok Chen]

On Jan 27, 2009, at 7:37 PM, Rick Ruhl wrote:

> True Chen, but don't you think we'd have to do a Ring 0 lever driver  
> to get
> access to the registers in the sound card?  We could put all the dsp  
> code in
> there (in asm) and poof, no latency at all.

No, that is why I mentioned the lack of need to even use ASIO (a low  
latency sound driver that Steinberg developed because the Microsoft  
sound interface has too much latency for pro audio work -- see,for  
example
http://en.wikipedia.org/wiki/Audio_Stream_Input/Output  .

As long as the sound card's sampling period is constant, the DSP does  
not care about latency.

Imagine that I generate a voltage ramp from 1 volt to 8 volts,  
changing by one volt each millisecond.

A codec running at 1000 samples/second would encode the voltage  
waveform into 8 numbers, 1, 2, 3, 4, 5, 6, 7, 8.

It does not matter to the DSP code if these 8 numbers are sent to the  
processor as

1, 2, 3, 4, 5, 6,7, 8

or

1, 2, <pause> 3, 4, 5, 6 <pause>7, 8

or as

1, 2, 3, 4, <pause> 5, 6, 7, 8

The 5th sample will still be the 5th sample to the DSP filter, which  
assumes that the numbers started out in the codec with 1 msec spacings.

The only time it is important is that if the pauses add up so that the  
stream no longer keeps up to real time.

But that is no longer a problem with today's processors.  Take a look  
at how many percent of processor MMTTY is using.  cocoaModem runs 9  
separate demodulators concurrently for RTTY and yet it does not use  
more than about 10% of an old 2.3 GHz G5 machine.

Latency is a problem with tuning indicators, but not with actual  
conversion of mark/space tones into Baudot characters.

73
Chen, W7AY


P.S. why 9 RTTY demodulators in cocoaModem?  I have mentioned this  
before but it might be salient to repeat it as long as we are talking  
about comparing modems.

I am sure there are many of us who have seen a ST-8000 decode a  
character wrongly while a lowly KAM Plus decodes it correctly.  When  
people say the HAL is better than the KAM, they mean that the ST-8000  
is better on the average, not with every character.   I.e., when you  
compare the two modems, the better modem is not *always* right.  It is  
just right more times than the worse modem is right.

This effect is prevalent enough that from as long as I could remember,  
many contesters run with two modems and keeping an eye on the output  
of both modems.

If 2 is good, why not more?  Well, your eyes and brain get tired very  
easily.

In software, extra demodulators also cost nothing; it is not like you  
have to shell out $4000 to HAL for each one -- I simply instantiated  
more copies of a modem object (Obective-C is object oriented).  What  
cocoaModem does is to run 9 FSK demodulators behind your back, then  
use majority voting (9 is an odd number by design) to decide which  
character it prints to the screen.  Each demodulator has a slightly  
different ATC time constant and relative multipath delay. You don't  
have to keep an eye on multiple screens or windows, the majority  
voting module does it for you.

The majority is not always right of course, but they are right enough  
times to make it worth spending all the extra processor cycles.  This  
also has an additional advantage that I use this for squelching.  The  
more demodulators have a character in common, the less the chance the  
character is squelched away.  The squelch slider is simply a value of  
how many demodulators must agree for the character to print.

It is probably trivial to add to MMTTY, by the way :-).  Just run each  
demodulator with a slightly different "MMTTY parameter."  Then use an  
HF channel simulator to decide what sets of parameters you want to use.