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