Re: [Discuss-gnuradio] DDC and Polyphase Channelizer

[Tom Rondeau]

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

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

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

Tom


>>
>>> Is this because the filter taps in GNURadio is different from Matlab? Is
>>> there a way I can create a filter in GNURadio from a list of numbers
>>> exported from Matlab?
>>
>> It could be a filter issue. If you want to, generate you prototype
>> filter in Matlab, then you can just copy-and-paste those into your GNU
>> Radio program as a list and pass that to the pfb_channelizer.
>>
>> Tom
>>
>