[RTTY] Best RTTY Program

[Joe Subich, W4TV]

> 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.

As dynamic as HF can be at times one could even make a case for 
running 3 x 3 or 3 x 5 demodulators ... with each of the three 
sets optimized for different characteristics (e.g., multi-path, 
selective fading, flutter) and using a "confidence" ranking to 
select the final output.  

73, 

   ... Joe, W4TV 
 


> -----Original Message-----
> From: rtty-bounces at contesting.com 
> [mailto:rtty-bounces at contesting.com] On Behalf Of Kok Chen
> Sent: Tuesday, January 27, 2009 11:37 PM
> To: RTTY Mailing List
> Subject: Re: [RTTY] Best RTTY Program
> 
> 
> 
> 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.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> RTTY mailing list
> RTTY at contesting.com http://lists.contesting.com/mailman/listinfo/rtty