FPGA Central

<[email protected]> wrote in message
news:[email protected] oups.com...
> The most intuitive way I found to look at polyphase decimation (as I
> learned it) was through the "commutator" structure shown in the
> Crochiere book.
>
> If you start out by writing out the convolution sum for every n.
>
> y[n] = h[0]x[n] + h[1]x[n-1] + ... + h[N-1]x[n-N+1] , n=0,1,...
>
> For a rate-M decimator, throw away every M output samples and then look
> at your corresponding y[Mn] samples you wrote out above for a bunch of
> different n values, you will see the structure.
>
> Basically a direct-form decimator is similar to a standard FIR
> implementation, but instead of computing one y output for each x input,
> here you skip M samples in your x[n] history buffer for each y output
> sample. Hence your computations are reduced by M.
>
> For the polyphase approach, the commutator model basically does
> something similar where you commutate your samples into your structure
> - once you have injected M new samples into the filter you compute one
> output point. It is just another way to look at the efficient
> direct-form approach (but there are some subtle differences).

I really like the commutator model as well, since it maps well in my brain
with implementation in mind. However, I've always had trouble with most
references that use this in their diagrams.
For example, in the PP. Vaidyanathan book,
Figure 4.3-9 (page 131) still doesn't make that much sense. The delay line
in (a) makes sense. Then going from that to the exact order of how the
commutator rotates doesn't seem intuitive.
I woul've said, when n=0, the commutator is on the top branch. For n=1, I
would've picked the 2nd branch (since it is one sample delayed from the top
branch). But the book shows the 3rd branch.
In the past, I've tried working through it with brute force and the book's
answer does work out but it just wasn't sitting well with my intuition. I
wonder if one of you guys can make me feel at ease.
If some of you have been to fred harris' multi-rate class, his pictures look
a little different as well (he starts his commutators at the bottom branch).

Hmm...now that I look at it again, I think I know what I'm having difficulty
with (and why), but I'd still like to hear some of your thoughts.

Cheers
Bhaskar




>
> I had to put together a paper for some non-DSP engineers, it does show
> the commutator model if you are interested:
> http://www.hyperdynelabs.com/dsp/DSP...imizations.pdf
>
> Dont go grading me on it, the paper was a quick write up!
>
> Jim
>
>
>
>
>
> Jon Harris wrote:
> > "Randy Yates" <[email protected]> wrote in message
> > news:[email protected]..
> > >
> > > Once again I come to the point where I must state, supporting Jim's
> > > impression, that many things in DSP that "sound" very complex and
> > > intimidating are, when you cut through to the bottom line, aren't
> all
> > > that fancy. To me this "polyphase" stuff is in that category, but I
> > > admit that I haven't studied the higher concepts like those in the
> > > Vaidnayathan book on filter banks. Perhaps when you look at it from
> > > a linear algebra point-of-view there is more to see.
> >
> > I agree with this. When I first about polyphase, it seemed to be
> like a rather
> > obvious optimization. Most of the inputs to your filter are zero, so
> you don't
> > bother including them in the calculation. Most of the outputs aren't
> used
> > anyway, so you don't bother computing them. Simple!
> >
> > One other point, I first learned about polyphase in the context of
> sample rate
> > conversion by a ratio of n/m, where 'the upsample by n' and
> 'downsample by m'
> > are combined into a single filtering operation. In that case, you
> end up with
> > what looks like a standard FIR low-pass filter (sinc-like shape)
> whose impulse
> > response has been interpolated to a higher sample rate. But then you
> end up
> > only using a part (one phase) of that filter for every output sample.
> To me,
> > this rational conversion case is when you can really see the
> polyphase technique
> > in action and can get a grasp on why it is called polyphase
> (literally 'many
> > phases').
>

In article <[email protected]>,
Jim Thomas <[email protected]> wrote:
>Each value of y depends on every filter tap, so I still don't see why it's
>polyphase. If this is polyphase, aren't ALL FIRs polyphase?

Yes.

All this polyphase stuff is just a distraction, *except* for reasons of
implementation efficiency. Standard resampling filters are all (usually
windowed) variants of Sync (or sync-like) reconstruction FIRs, with the
Sync width appropriate to the output sample rate, and with some phase.
The phase seems to disappear from standard decimators because the
default input to output phase is taken as zero (but you don't have to
decimate that way!). Using Polyphase coefficient tables is one method
of optimization if the input/output ratio is appropriate. But the
input/output ratio can be irrational and you can still reconstruct with
Sync coefficients, they just have to be appropriate coefficients for
every output sample (calculated individually per sample or interpolated
for instance).

I've even found uses for resampling filters where the input/output
ratio has been 1:1 (tuneable precision delay lines for instance).


IMHO. YMMV.
--
Ron Nicholson rhn AT nicholson DOT com http://www.nicholson.com/rhn/
#include <canonical.disclaimer> // only my own opinions, etc.