[Top][All Lists]

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

Re: [Discuss-gnuradio] DDC and Polyphase Channelizer

From: Jimmy Richardson
Subject: Re: [Discuss-gnuradio] DDC and Polyphase Channelizer
Date: Tue, 04 Jan 2011 12:25:38 +0800
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7

Hi, Tom:

Please see my comments below.


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.


On 12/30/2010 11:47 PM, Tom Rondeau wrote:
On Wed, Dec 29, 2010 at 4:32 AM, Jimmy Richardson<address@hidden>
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
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
        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.
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
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.


reply via email to

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