|
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:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 |
Hi, Tom: Please see my comments below. Thanks On 1/4/2011 12:36 AM, Tom Rondeau wrote:
That is alright, I think I can take it as a quirk of the algorithm, it's nice to know :)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 codeThanks, 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
[Prev in Thread] | Current Thread | [Next in Thread] |