discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] filters


From: 'Eric Blossom'
Subject: Re: [Discuss-gnuradio] filters
Date: Tue, 29 Jan 2002 12:39:31 -0800
User-agent: Mutt/1.2.5i

On Tue, Jan 29, 2002 at 10:57:56AM -0800, Ettus, Matt wrote:
> > On the general channel selection filter (son of VrComplexFIRfilter), 
> > I plan to have the callback build the prototype low pass, 
> > then tranform
> > it depending on the channel center frequency.  This will allow us to
> > "tune" on the fly.
> 
> Sounds good.  What method of filter design?

I was thinking of using Remez.  I think for the channel selector
(particularly narrow band), we're going to need something that can do
better than the 50 dB the current windowed design does.  I plan on
doing the windowed design too.

> > > Have you gotten that SPUC code integrated?
> > 
> > Nope.  If you need it now, I'll get to it.
> 
> I just need generic FIR filters.  I guess I could whip up something to get
> me by for the short term.

OK.

> Question:  I'm all in favor of using STL types like vector, but I always
> worry about whether they do bounds checking.  That could get expensive.

I don't think that they bounds check, but the other issue is that I
suspect that were going to want to hand the taps off to assembler/mmx
at some time.  I would be nice to know exactly what the representation
is.  Perhaps instead of using vector, we should use something simple
that just bundles together the pointer to the taps and the length.  We
don't need any of the dynamic resizing, iterators, etc.

> > I'm working on the RS stuff, and got a nice answer back from Phil Karn
> > on how to handle the (207,187) codec.  With the given API, I need to
> > prefix the message with 48 zeros.  This converts the (207+48,187+48)
> > into (255,235) which his code directly handles.  With an API change,
> > we could save a few cycles, since the 48 zeros could be skipped.
> 
> It would be interesting to see how fast you can get this to run.  The code
> is efficient, but 20mbits/sec is a lot.  I got nervous yesterday when I saw
> that Phil said he could only Viterbi decode ~9 Mbits/sec on a 1 GHz PIII
> using SSE optimized code.  Then I realized he was using a code with a much
> longer constraint length than HDTV.

I'll let you know what I come up with.  

I'm proceeding with the RS stuff (since I've got it all in my head),
and then when I'm done with it, if you haven't gotten to it, I'll work
on the filter stuff.

I've also got some questions about the convolutional interleaver.  
If you get a chance, give me a call sometime.

Eric



reply via email to

[Prev in Thread] Current Thread [Next in Thread]