Re: [Discuss-gnuradio] DDC and Polyphase Channelizer

[Jimmy Richardson]

Hi, Tom:

Please see my comments below.

Thanks


On 1/4/2011 12:36 AM, Tom Rondeau wrote:
> On Sun, Jan 2, 2011 at 11:57 PM, Jimmy Richardson<address@hidden>  wrote:
> > Hi, Tom:
> >
> > Please see my comments below.
> >
> > Thanks
> >
> >
> > On 12/30/2010 11:47 PM, Tom Rondeau wrote:
> > > On Wed, Dec 29, 2010 at 4:32 AM, Jimmy Richardson<address@hidden>
> > >   wrote:
> > > > > Also, keep in mind that fred always develops he own filters straight
> > > > > from the remez algorithm. If you are using gr.firdes.low_pass, you're
> > > > > not going to get the same output filters. Closer would be to use the
> > > > > blcks2.optfir.low_pass, which uses the PM algorithm (which in turn
> > > > > uses Remez), but I couldn't give you the specs you need to build the
> > > > > same _exact_ filter as in fred's paper. But you'll get close enough
> > > > > that the basic shapes of the signals will be the same, if not every
> > > > > point.
> > > > Thanks for the suggestion, I modified filter statement to:
> > > >
> > > >         self._filter_taps = blks2.optfir.low_pass(1, self._input_rate,
> > > >                                                   self._cutoff_freq -
> > > > self._trans_width/2, self._cutoff_freq + self._trans_width/2,
> > > >                                                   0.9, 60, 400)
> > > >
> > > > Note I have to use 400 as extra taps otherwise remez won't work (too many
> > > > extremals -- cannot continue)
> > > Hm, that looks wrong. You shouldn't need to use the extra taps input
> > > just to get the algorithm to converge. It's really meant to be able to
> > > give you minor control over the number of taps you use, specifically
> > > if you need a filter with an even or odd number of taps. Using 400 is
> > > way too many.
> > >
> > > The real problem I think comes from your in-band ripple or 0.9. That's
> > > a value in dB and specifies the magnitude of the peak-to-peak
> > > fluctuations in the passband. I was able to use your settings above
> > > but specified a ripple of 0.1, which produces a filter of 764 taps.
> > You're right, the problem is with the ripple parameter, I changed the line
> > to:
> >         self._filter_taps = blks2.optfir.low_pass(1, self._input_rate,
> >                                                   self._cutoff_freq -
> > self._trans_width/2, self._cutoff_freq + self._trans_width/2,
> >                                                   0.1, 60)
> > and no extra taps are needed, although the new filter has 1524 taps.
> >
> > But I'm a bit confused why this works, I thought smaller ripple is better,
> > and thus harder to get, right? And the ripple parameter is the maximum
> > ripple allowed for the filter? If so, 0.9 should be more relaxed than 0.1?
> It's not quite that straight-forward. I've found issues when designing
> filters with an out-of-band attenuation of 80 that work fine but an
> attenuation of 60 fail to converge. The PM algorithm is essentially an
> optimization procedure that tries to fit a curve under the provided
> conditions. It's been a while since I've looked at the specifics of
> it, but because it's doing a curve fit, thinking about it in terms of
> one filter being more "relaxed" than another doesn't quite work. Sorry
> I can't give you more details or math about why this is true. Maybe
That is alright, I think I can take it as a quirk of the algorithm, it's 
nice to know :)
> someone else here has gone through this before and has more to offer?
>
>
> > > > I got the result, but still not the same as the one from Matlab:
> > > > 1. The channels seem to be shifted by 20 then wrapped around, i.e.
> > > > assuming
> > > > channel # starts with 1, the pfb result's channel 1 seems to be matlab's
> > > > channel 21, and channel 20 in pfb result seems to be matlab's channel 40,
> > > > channel 21 in pfb result seems to be matlab's channel 1.
> > > > 2. Assuming the channel shift/wrap is done, the time-domain plot still
> > > > are
> > > > not the same, pfb channel 1 (matlab's channel 21)'s plot seems to be the
> > > > same, and no signal channels do fit, but other channels' plot are not the
> > > > same (i.e. the situation is similar to my result of DDC).
> > > This strikes me as a simple naming issue; which channel you decide is
> > > 0 versus N. The way that I have the output of the channelizer working,
> > > channel 0 is the DC channel, channel 1 is the next one to the "right"
> > > (the next one in moving in the positive frequency direction). Channel
> > > floor(N/2) will either span the last part of the positive spectrum and
> > > the first part of the negative spectrum (if N is even) or be the last
> > > channel in the positive spectrum (if N is odd). Channel N-1 is
> > > directly "left" of channel 0.
> > Ok, thanks for the explanation, this cleared things up, I added a shift to
> > the matlab code to put the two results in line.
> >
> > > It's hard to know what you mean by the signals being "the same." Are
> > > they completely different?
> > Please check attachment for the results I get:
> > appendix_III_receiver_40z.result_time.shifted.jpg: This is the result from
> > harris' matlab code, channels are shifted to align with pfb_channelizer_ccf.
> > appendix_III_pfb.grfilter.result_time.jpg: This is the result from
> > pfb_channelizer_ccf, using filter generated from blks2.optfir.low_pass
> > appendix_III_pfb.matlabfilter.result_time.jpg: This is the result from
> > pfb_channelizer_ccf, using filter generated from matlab code
>
> Thanks, that helps.
>
>
> > Here's my observations:
> > 1. The two results from pfb_channelizer_ccf are the same, minus some time
> > shift, so I think filter is no the problem here.
> Due to group delay in the filters, almost certainly. What are the
> filter lengths for the optfir and matlab filters? The difference is
> probably the shift you're seeing.

Yes, the lengths are different, optfir is 1524, matlab is 600

> > 2. Comparing the result from matlab and pfb_channelizer_ccf: Channel 0, 5,
> > 10, 30, 35 are the same, the others are different, very strange.
> Indeed. Very strange. My guess is that there is a misconception
> somewhere in the code about sample rate. I can't quite see it in my
> head, but I'm guessing that the channel spacing isn't exactly the
> channel spacing you think it is.

You mean the oversample rate O = N/i is wrong? As far as I can see, 
that's the only number that could go wrong, since pfb_channelizer_ccf 
only takes 3 parameters, # of channels, taps and oversample rate, and it 
doesn't look like the other two can be wrong.

I checked the calculation of O again, but couldn't find the problem. In 
the Matlab code, harris uses loops "for nn=1:28:5600-28" to do the 
processing, so it does seems a 28-to-1 downsampling in 40 channels.

> Have you looked at the examples in gnuradio-examples/python/pfb?
> Specifically, channelize.py, chirp_channelize.py, and synth_to_chan.py.

I checked the first two samples when I wrote the channelizer, although 
it seems they didn't use the oversample rate parameter. I couldn't find 
the last one (synth_to_chan.py) though.

> Tom