FPGA Central

Hello,

For a project which I'm working on, I have a 60Hz sinewave modulated with a
square wave at 0.5Hz, modulation is 2.72%

The signal comes sampled at 8kHz, I should downsample it to 200Hz, so M =
40. I do that in two stages, first with M1 = 10, then with M2 = 4. I
implemented polyphase structure in Simulink, and runs great. By "great" I
mean that the output signal, sampled at 200Hz, preserves the squarewave
shape perfectly.

Ths structure used in Simulink is the one in P.P. Vaidyanathan's book
"Multirate Systems and Filter Banks", figure 4.3-4 (a), page 124.

However, In my C implementation (on SHARC, BTW), the downsampled signal
looks weird. By "weird" I mean that the envelope of the output signal,
instead of being flat (square) as it is expected to be, seems more like a
low frequency sinusoid, still it is noticeable when the amplitude rises and
falls at the same frequency of the original modulating square wave.

Given this information, and the fact that Simulink implementation maps
directly to the figure in Vaidyanathan's book, I am pretty sure that I have
some mistakes in my C implementation, but I can't find them.

Could someone here please give me advice on what mistakes in implementing
the polyphase M-fold decimation filters lead to the sort of "weirdness" that
I got from my C implementation? That would be of much support in finding
what I did wrong.

If someone who desires to help me wants to have a look at the Simulink Model
that I implemented, to the output of my C (for SHARC) implementation, and/or
to my C implementation itself, please let me know, and I will be more than
pleased in sending it to you.

Kindest regards,

--
Jaime Andrés Aranguren Cardona
jaac@nospam.sanjaac.com
SanJaaC Electronics
Soluciones en DSP
www.sanjaac.com

(Remove "nospam" from e-mail address)

Just a quick thought, one difference could be that in the Simulink case, your
8kHz sample rate is probably an _exact_ multiple of the 60Hz waveform, but in
the real-world case, it may not be. Try modifying your Simulink example to use
a slightly different frequency such as 60.37 Hz or something and see what
happens.

You could also try simplifying the problem by downsampling just the 60Hz
waveform without the modulation.

"Jaime Andrés Aranguren Cardona" <jaac@nospam.sanjaac.com> wrote in message
news:1103046565.72fb8397a7036cd0ab33545d0fe7c860@t eranews...
> Hello,
>
> For a project which I'm working on, I have a 60Hz sinewave modulated with a
> square wave at 0.5Hz, modulation is 2.72%
>
> The signal comes sampled at 8kHz, I should downsample it to 200Hz, so M =
> 40. I do that in two stages, first with M1 = 10, then with M2 = 4. I
> implemented polyphase structure in Simulink, and runs great. By "great" I
> mean that the output signal, sampled at 200Hz, preserves the squarewave
> shape perfectly.
>
> Ths structure used in Simulink is the one in P.P. Vaidyanathan's book
> "Multirate Systems and Filter Banks", figure 4.3-4 (a), page 124.
>
> However, In my C implementation (on SHARC, BTW), the downsampled signal
> looks weird. By "weird" I mean that the envelope of the output signal,
> instead of being flat (square) as it is expected to be, seems more like a
> low frequency sinusoid, still it is noticeable when the amplitude rises and
> falls at the same frequency of the original modulating square wave.
>
> Given this information, and the fact that Simulink implementation maps
> directly to the figure in Vaidyanathan's book, I am pretty sure that I have
> some mistakes in my C implementation, but I can't find them.
>
> Could someone here please give me advice on what mistakes in implementing
> the polyphase M-fold decimation filters lead to the sort of "weirdness" that
> I got from my C implementation? That would be of much support in finding
> what I did wrong.

Jaime Andrés Aranguren Cardona wrote:
> Hello,
>
> For a project which I'm working on, I have a 60Hz sinewave modulated with a
> square wave at 0.5Hz, modulation is 2.72%
>
> The signal comes sampled at 8kHz, I should downsample it to 200Hz, so M =
> 40. I do that in two stages, first with M1 = 10, then with M2 = 4. I
> implemented polyphase structure in Simulink, and runs great. By "great" I
> mean that the output signal, sampled at 200Hz, preserves the squarewave
> shape perfectly.
>
> Ths structure used in Simulink is the one in P.P. Vaidyanathan's book
> "Multirate Systems and Filter Banks", figure 4.3-4 (a), page 124.
>
> However, In my C implementation (on SHARC, BTW), the downsampled signal
> looks weird. By "weird" I mean that the envelope of the output signal,
> instead of being flat (square) as it is expected to be, seems more like a
> low frequency sinusoid, still it is noticeable when the amplitude rises and
> falls at the same frequency of the original modulating square wave.
>
> Given this information, and the fact that Simulink implementation maps
> directly to the figure in Vaidyanathan's book, I am pretty sure that I have
> some mistakes in my C implementation, but I can't find them.
>
> Could someone here please give me advice on what mistakes in implementing
> the polyphase M-fold decimation filters lead to the sort of "weirdness" that
> I got from my C implementation? That would be of much support in finding
> what I did wrong.
>
> If someone who desires to help me wants to have a look at the Simulink Model
> that I implemented, to the output of my C (for SHARC) implementation, and/or
> to my C implementation itself, please let me know, and I will be more than
> pleased in sending it to you.
>
> Kindest regards,
>
> --
> Jaime Andrés Aranguren Cardona
> jaac@nospam.sanjaac.com
> SanJaaC Electronics
> Soluciones en DSP
> www.sanjaac.com
>
> (Remove "nospam" from e-mail address)
>
>

You could also try a regular decimation implementation (instead of
polyphase) to see whether of not it's your polyphase filtering code.

Cheers,
David

Just another thought. Did you make sure you cycled through the coeffs in
the right order.
Try reversing the sequence in which you use the coeffs.
Although I am as careful as I can be, I can't tell you how many times I end
up experimenting
till I get the sequencing right.

Regards,
Dave Shaw
>
> Could someone here please give me advice on what mistakes in implementing
> the polyphase M-fold decimation filters lead to the sort of "weirdness"
that
> I got from my C implementation? That would be of much support in finding
> what I did wrong.
>
> If someone who desires to help me wants to have a look at the Simulink
Model
> that I implemented, to the output of my C (for SHARC) implementation,
and/or
> to my C implementation itself, please let me know, and I will be more than
> pleased in sending it to you.
>

Good suggestion. For some reason, I usually find the order is backwards from
what I would intuitively think! There was an interesting thread on this a while
back:
http://tinyurl.com/3s6dc

"Att" <david.g.shaw@att.net> wrote in message
news:agGvd.124735$7i4.59110@bgtnsc05-news.ops.worldnet.att.net...
> Just another thought. Did you make sure you cycled through the coeffs in
> the right order.
> Try reversing the sequence in which you use the coeffs.
> Although I am as careful as I can be, I can't tell you how many times I end
> up experimenting
> till I get the sequencing right.
>
> Regards,
> Dave Shaw
> >
> > Could someone here please give me advice on what mistakes in implementing
> > the polyphase M-fold decimation filters lead to the sort of "weirdness"
> that
> > I got from my C implementation? That would be of much support in finding
> > what I did wrong.
> >
> > If someone who desires to help me wants to have a look at the Simulink
> Model
> > that I implemented, to the output of my C (for SHARC) implementation,
> and/or
> > to my C implementation itself, please let me know, and I will be more than
> > pleased in sending it to you.

"Jon Harris" <goldentully@hotmail.com> escribió en el mensaje
news:328q1cF3k3plsU1@individual.net...
> Good suggestion. For some reason, I usually find the order is backwards
from
> what I would intuitively think!

Hello Sirs,

I tried reversing the coefficients, but that simply didn't work. This was my
original code (please excuse me for posting this long stuff here, but I
don't see any other method to let you know what I did):


// The Sample Rate Conversion Routines - Saving data, stage 1
void SrcSaveStage1 (float sample)
{
int i;
static int sampleCount;
float tmpSample;

// Update the delay line to input to SRC algo
for (i = SRC_STAGE1_N_FILT-1; i > 0; i--) {
srcStage1_Delay[i] = srcStage1_Delay[i-1];
}
srcStage1_Delay[0] = sample;

// Increment sample counter
sampleCount++;
if (sampleCount == SRC_STAGE1_N_FILT) {
// Toggle flag everytime we downsampled by 10
ToggleFlag4_9(8);
tmpSample = SrcProcessStage1(); // Process one of each M1(=10) samples,
SRC algo stage 1
SrcSaveStage2 (tmpSample); // And save for M2(4), stage 2
sampleCount = 0;
}
}

// The Sample Rate Conversion Routines - Saving data, stage 2
void SrcSaveStage2 (float sample)
{
int i;
static int sampleCount;

// Update the delay line to input to SRC algo
for (i = SRC_STAGE2_N_FILT-1; i > 0; i--) {
srcStage2_Delay[i] = srcStage2_Delay[i-1];
}
srcStage2_Delay[0] = sample;

// Increment sample counter
sampleCount++;
if (sampleCount == SRC_STAGE2_N_FILT) {
srcOut = SrcProcessStage2(); // Process one of each M1(=10) samples, SRC
algo stage 1
srcReady = true; // Set the flag
sampleCount = 0; // Restart counter
}
else {
srcReady = false; // Keep flag cleared
}
}

// The Sample Rate Conversion Routines - Processing data, stage 1
float SrcProcessStage1 (void)
{
float outSamples[SRC_STAGE1_N_FILT];
float output;
int i;

output = 0;
outSamples[0] = fir(srcStage1_Delay[0], srcStage1_1Coeffs,
srcStage1_1State, SRC_STAGE1_FILT_LEN);
outSamples[1] = fir(srcStage1_Delay[1], srcStage1_2Coeffs,
srcStage1_2State, SRC_STAGE1_FILT_LEN);
outSamples[2] = fir(srcStage1_Delay[2], srcStage1_3Coeffs,
srcStage1_3State, SRC_STAGE1_FILT_LEN);
outSamples[3] = fir(srcStage1_Delay[3], srcStage1_4Coeffs,
srcStage1_4State, SRC_STAGE1_FILT_LEN);
outSamples[4] = fir(srcStage1_Delay[4], srcStage1_5Coeffs,
srcStage1_5State, SRC_STAGE1_FILT_LEN);
outSamples[5] = fir(srcStage1_Delay[5], srcStage1_6Coeffs,
srcStage1_6State, SRC_STAGE1_FILT_LEN);
outSamples[6] = fir(srcStage1_Delay[6], srcStage1_7Coeffs,
srcStage1_7State, SRC_STAGE1_FILT_LEN);
outSamples[7] = fir(srcStage1_Delay[7], srcStage1_8Coeffs,
srcStage1_8State, SRC_STAGE1_FILT_LEN);
outSamples[8] = fir(srcStage1_Delay[8], srcStage1_9Coeffs,
srcStage1_9State, SRC_STAGE1_FILT_LEN);
outSamples[9] = fir(srcStage1_Delay[9], srcStage1_10Coeffs,
srcStage1_10State, SRC_STAGE1_FILT_LEN);

for (i = 0; i < SRC_STAGE1_N_FILT; i++) {
output += outSamples[i];
}

return output;
}

// The Sample Rate Conversion Routines - Processing data, stage 2
float SrcProcessStage2 (void)
{
float outSamples[SRC_STAGE2_N_FILT];
float output;
int i;

output = 0;
outSamples[0] = fir(srcStage2_Delay[0], srcStage2_1Coeffs,
srcStage2_1State, SRC_STAGE2_FILT_LEN);
outSamples[1] = fir(srcStage2_Delay[1], srcStage2_2Coeffs,
srcStage2_2State, SRC_STAGE2_FILT_LEN);
outSamples[2] = fir(srcStage2_Delay[2], srcStage2_3Coeffs,
srcStage2_3State, SRC_STAGE2_FILT_LEN);
outSamples[3] = fir(srcStage2_Delay[3], srcStage2_4Coeffs,
srcStage2_4State, SRC_STAGE2_FILT_LEN);

for (i = 0; i < SRC_STAGE2_N_FILT; i++) {
output += outSamples[i];
}

return output;
}

--------------------------

Every time a sample arrives (every 125 us, 8kHz sample rate), I execute
SrcSaveStage1(). In this routine I simply put the samples in the 10-tap
delay line, the one at the input of the "Polyphase Iimplementation Stage 1"
in the Simulink model. Once I have 10 samples aquired (and the delay line
full) I do the processing of it. This act of processing only when the 10
samples acquired implements the downsampling by 10 in the simulink model.
The processing is done in the SrcProcessStage1() routine. This one simply
consists on a bank of 10 FIR filters, with coefficients as defined in
Matlab, the same ones for the Simulink simulation. The input for each of the
filters is a tap from the delay line, so the input to the filter is
downsampled by 10, as desired. The output of the filters is summed up.

Once I have a sample out of the stage 1 (every 1250 uS, 800 Hz), I do the
same processing for stage 1, very similar as it was for stage 1, but with
the respective filters and downsampling factor (4).

So the final output is sampled at 200 Hz.

I think I was moving the downsampling blocks of each branch of the structure
(refer to Vaydianathan's book) BEFORE the input delay line. So I modified my
code, here it is:

--------------------------
// The Sample Rate Conversion Routines - Saving data, stage 1
void SrcSaveStage1 (float sample)
{
int i;
static int sampleCount;

// Update the delay line to input to SRC algo
for (i = SRC_STAGE1_N_FILT-1; i > 0; i--) {
srcStage1_Delay[i] = srcStage1_Delay[i-1];
}
srcStage1_Delay[0] = sample;

// Increment sample counter
sampleCount++;
if (sampleCount == SRC_STAGE1_N_FILT) {
sampleCount = 0;
}

SrcProcessStage1(); // Do the downsampling and filtering every 10 samples
}

// The Sample Rate Conversion Routines - Saving data, stage 2
void SrcSaveStage2 (float sample)
{
int i;
static int sampleCount;

// Update the delay line to input to SRC algo
for (i = SRC_STAGE2_N_FILT-1; i > 0; i--) {
srcStage2_Delay[i] = srcStage2_Delay[i-1];
}
srcStage2_Delay[0] = sample;

// Increment sample counter
sampleCount++;
if (sampleCount == SRC_STAGE2_N_FILT) {
sampleCount = 0;
}

SrcProcessStage2(); // Do the downsampling and filtering every 4 samples
}

// The Sample Rate Conversion Routines - Processing data, stage 1
void SrcProcessStage1 (void)
{
float outSamples[SRC_STAGE1_N_FILT];
float output;
int i;

static int sampleCount;

// Store data from input delay line into
// downsampling delay lines
srcStage1_Delay1[sampleCount] = srcStage1_Delay[0];
srcStage1_Delay2[sampleCount] = srcStage1_Delay[1];
srcStage1_Delay3[sampleCount] = srcStage1_Delay[2];
srcStage1_Delay4[sampleCount] = srcStage1_Delay[3];
srcStage1_Delay5[sampleCount] = srcStage1_Delay[4];
srcStage1_Delay6[sampleCount] = srcStage1_Delay[5];
srcStage1_Delay7[sampleCount] = srcStage1_Delay[6];
srcStage1_Delay8[sampleCount] = srcStage1_Delay[7];
srcStage1_Delay9[sampleCount] = srcStage1_Delay[8];
srcStage1_Delay10[sampleCount] = srcStage1_Delay[9];

sampleCount++; //Increment counter

// Once every delay line for downsampling has M1 = 10 samples,
// filter with the oldest sample on each delay line
if (sampleCount == SRC_STAGE1_N_FILT) {
// Toggle flag everytime we downsampled by 10
ToggleFlag4_9(8);

// Do the filtering
output = 0;
outSamples[0] = fir(srcStage1_Delay1[0], srcStage1_1Coeffs,
srcStage1_1State, SRC_STAGE1_FILT_LEN);
outSamples[1] = fir(srcStage1_Delay2[0], srcStage1_2Coeffs,
srcStage1_2State, SRC_STAGE1_FILT_LEN);
outSamples[2] = fir(srcStage1_Delay3[0], srcStage1_3Coeffs,
srcStage1_3State, SRC_STAGE1_FILT_LEN);
outSamples[3] = fir(srcStage1_Delay4[0], srcStage1_4Coeffs,
srcStage1_4State, SRC_STAGE1_FILT_LEN);
outSamples[4] = fir(srcStage1_Delay5[0], srcStage1_5Coeffs,
srcStage1_5State, SRC_STAGE1_FILT_LEN);
outSamples[5] = fir(srcStage1_Delay6[0], srcStage1_6Coeffs,
srcStage1_6State, SRC_STAGE1_FILT_LEN);
outSamples[6] = fir(srcStage1_Delay7[0], srcStage1_7Coeffs,
srcStage1_7State, SRC_STAGE1_FILT_LEN);
outSamples[7] = fir(srcStage1_Delay8[0], srcStage1_8Coeffs,
srcStage1_8State, SRC_STAGE1_FILT_LEN);
outSamples[8] = fir(srcStage1_Delay9[0], srcStage1_9Coeffs,
srcStage1_9State, SRC_STAGE1_FILT_LEN);
outSamples[9] = fir(srcStage1_Delay10[0], srcStage1_10Coeffs,
srcStage1_10State, SRC_STAGE1_FILT_LEN);

// Final sum of filter outputs
for (i = 0; i < SRC_STAGE1_N_FILT; i++) {
output += outSamples[i];
}

sampleCount = 0; // Restart counter (index)

SrcSaveStage2 (output); // And save for M2 = 4, stage 2
}
}

// The Sample Rate Conversion Routines - Processing data, stage 2
void SrcProcessStage2 (void)
{
float outSamples[SRC_STAGE2_N_FILT];
float output;
int i;

static int sampleCount;

// Store data from input delay line into
// downsampling delay lines
srcStage2_Delay1[sampleCount] = srcStage2_Delay[0];
srcStage2_Delay2[sampleCount] = srcStage2_Delay[1];
srcStage2_Delay3[sampleCount] = srcStage2_Delay[2];
srcStage2_Delay4[sampleCount] = srcStage2_Delay[3];

sampleCount++; //Increment counter

// Once every delay line for downsampling has M2 = 4 samples,
// filter with the oldest sample on each delay line
if (sampleCount == SRC_STAGE2_N_FILT) {
// Toggle flag everytime we downsampled by 4 (this means, by 40)
ToggleFlag4_9(7);

// Do the filtering
output = 0;
outSamples[0] = fir(srcStage2_Delay1[0], srcStage1_1Coeffs,
srcStage1_1State, SRC_STAGE1_FILT_LEN);
outSamples[1] = fir(srcStage2_Delay2[0], srcStage1_2Coeffs,
srcStage1_2State, SRC_STAGE1_FILT_LEN);
outSamples[2] = fir(srcStage2_Delay3[0], srcStage1_3Coeffs,
srcStage1_3State, SRC_STAGE1_FILT_LEN);
outSamples[3] = fir(srcStage2_Delay4[0], srcStage1_4Coeffs,
srcStage1_4State, SRC_STAGE1_FILT_LEN);

// Final sum of filter outputs
for (i = 0; i < SRC_STAGE1_N_FILT; i++) {
output += outSamples[i];
}

sampleCount = 0; // Restart counter (index)
srcReady = true; // Set the flag

srcOut = output; // Save the oufinal output data
}
else {
srcReady = false; // Clear the flag
}
}

--------------------------

Now, every 125 us I update the input delay line, and store the data from
each tap on this delay line into a delay line for downsampling. Once I have
M1 = 10 samples in the downsampling delay lines, I run my M1 = 10 filters,
taking only the oldest sample of the downsampling delay lines as input, and
sum up the result.

Then I trigger the corresponding process for the second stage, but I get the
same results as from the very beginning. Reversing the filter coefficients
does not help at all.

What else could I try, guys? I'd really appreciate if you can take a look at
my code, and help me find out where the mistakes can be, or provide me with
some reference C code.

Thanks you very much in advance,

--
Jaime Andrés Aranguren Cardona
jaac@nospam.sanjaac.com
SanJaaC Electronics
Soluciones en DSP
www.sanjaac.com

(Remove "nospam" from e-mail address)

Jaime Andrés Aranguren Cardona wrote:
> What else could I try, guys? I'd really appreciate if you can take a look at
> my code, and help me find out where the mistakes can be, or provide me with
> some reference C code.
>
> Thanks you very much in advance,

Did you see Grant's multirate code on dspguru.com?


--
Jim Thomas Principal Applications Engineer Bittware, Inc
jthomas@bittware.com http://www.bittware.com (603) 226-0404 x536
Failure is always an option

"Jim Thomas" <jthomas@bittware.com> escribió en el mensaje
news:10s0pegaj0r88e9@corp.supernews.com...
> Jaime Andrés Aranguren Cardona wrote:
> > What else could I try, guys? I'd really appreciate if you can take a
look at
> > my code, and help me find out where the mistakes can be, or provide me
with
> > some reference C code.
> >
> > Thanks you very much in advance,
>
> Did you see Grant's multirate code on dspguru.com?
>

Hi Jim,

Yes I did. It is not polyphase, right? I'd love it was... Any example in C
with ployphase implementation?

--
Jaime Andrés Aranguren Cardona
jaac@nospam.sanjaac.com
SanJaaC Electronics
Soluciones en DSP
www.sanjaac.com

(Remove "nospam" from e-mail address)

"Jaime Andrés Aranguren Cardona" <jaac@nospam.sanjaac.com> wrote in message
news:1103129550.7987b75918af9ea133251f5237596ac2@t eranews...
> "Jim Thomas" <jthomas@bittware.com> escribió en el mensaje
> news:10s0pegaj0r88e9@corp.supernews.com...
> > Jaime Andrés Aranguren Cardona wrote:
> > > What else could I try, guys? I'd really appreciate if you can take a
> look at
> > > my code, and help me find out where the mistakes can be, or provide me
> with
> > > some reference C code.
> > >
> > > Thanks you very much in advance,
> >
> > Did you see Grant's multirate code on dspguru.com?
> >
>
> Hi Jim,
>
> Yes I did. It is not polyphase, right? I'd love it was... Any example in C
> with ployphase implementation?

Yes - from what I remember it is a polyphase implementation.
Cheers
Bhaskar

> --
> Jaime Andrés Aranguren Cardona
> jaac@nospam.sanjaac.com
> SanJaaC Electronics
> Soluciones en DSP
> www.sanjaac.com
>
> (Remove "nospam" from e-mail address)
>
>

Try this:
http://www.mega-nerd.com/SRC/
It includes source.

"Jaime Andrés Aranguren Cardona" <jaac@nospam.sanjaac.com> wrote in message
news:1103129550.7987b75918af9ea133251f5237596ac2@t eranews...
> "Jim Thomas" <jthomas@bittware.com> escribió en el mensaje
> news:10s0pegaj0r88e9@corp.supernews.com...
> > Jaime Andrés Aranguren Cardona wrote:
> > > What else could I try, guys? I'd really appreciate if you can take a
> look at
> > > my code, and help me find out where the mistakes can be, or provide me
> with
> > > some reference C code.
> > >
> > > Thanks you very much in advance,
> >
> > Did you see Grant's multirate code on dspguru.com?
>
> Hi Jim,
>
> Yes I did. It is not polyphase, right? I'd love it was... Any example in C
> with ployphase implementation?

Jaime Andrés Aranguren Cardona wrote:
> "Jim Thomas" <jthomas@bittware.com> escribió en el mensaje
> news:10s0pegaj0r88e9@corp.supernews.com...
>
>>Jaime Andrés Aranguren Cardona wrote:
>>
>>>What else could I try, guys? I'd really appreciate if you can take a
>
> look at
>
>>>my code, and help me find out where the mistakes can be, or provide me
>
> with
>
>>>some reference C code.
>>>
>>>Thanks you very much in advance,
>>
>>Did you see Grant's multirate code on dspguru.com?
>>
>
>
> Hi Jim,
>
> Yes I did. It is not polyphase, right? I'd love it was... Any example in C
> with ployphase implementation?

The interpolation code on dspguru is most definitely polyphase.

My understanding is that polyphase only comes into play during interpolation.
It's only during interpolation that you get the opportunity to skip through the
coefs - essentially choosing a phase of the impulse response. In decimation you
work on contiguous samples, but only calculate the outputs you're going to keep.

Am I wrong?

--
Jim Thomas Principal Applications Engineer Bittware, Inc
jthomas@bittware.com http://www.bittware.com (603) 226-0404 x536
Hope springs occasionally.

Jim Thomas <jthomas@bittware.com> writes:

> Jaime Andrés Aranguren Cardona wrote:
> > "Jim Thomas" <jthomas@bittware.com> escribió en el mensaje
> > news:10s0pegaj0r88e9@corp.supernews.com...
> >
>
> >>Jaime Andrés Aranguren Cardona wrote:
> >>
> >>>What else could I try, guys? I'd really appreciate if you can take a
> > look at
>
> >
>
> >>>my code, and help me find out where the mistakes can be, or provide me
> > with
>
> >
>
> >>>some reference C code.
> >>>
> >>>Thanks you very much in advance,
> >>
> >>Did you see Grant's multirate code on dspguru.com?
> >>
> > Hi Jim,
>
> > Yes I did. It is not polyphase, right? I'd love it was... Any
> > example in C
>
> > with ployphase implementation?
>
> The interpolation code on dspguru is most definitely polyphase.
>
> My understanding is that polyphase only comes into play during interpolation.
> It's only during interpolation that you get the opportunity to skip
> through the coefs - essentially choosing a phase of the impulse
> response. In decimation you work on contiguous samples, but only
> calculate the outputs you're going to keep.
>
>
> Am I wrong?

Well, I hate to say wrong because I see exactly where you're coming
from and I like to view it your way, but according to Mitra [1] the
term "polyphase," and the corresponding partitioning of filter
coefficients, can be applied to both interpolators and decimators.

In a polyphase M-fold interpolator, you have M polyphase filter coefficient sets
E_0 through E_{M-1} that each operate at the incoming sample rate. Each are then
upsampled by M, delayed, and then summed. The end result is that, assuming the total
filter length is M*K (so that each polyphase section is K coefficients long),
your computations require M*K*Fs multiplications/second instead of M^2*K*Fs,
where Fs is the input sample rate.

In a polyphase M-fold decimator, you have M polyphase filter coefficient sets
E_0 through E_{M-1} that each operate at the outgoing sample rate. Each section
is fed from an M-fold downsampler. M phases of the input signal are obtained
at the M downsampler outputs by delaying the input of each by a sample. Then
each polyphase section is convolved and the results summed. Again
your computations require M*K*Fs multiplications/second instead of M^2*K*Fs,
where Fs is the output sample rate.
--
Randy Yates
Sony Ericsson Mobile Communications
Research Triangle Park, NC, USA
randy.yates@sonyericsson.com, 919-472-1124

> Yes - from what I remember it is a polyphase implementation.
> Cheers
> Bhaskar

Hi,

Thanks Jim, thanks Bhaskar, thank you everybody.

Yes, it definitely is polyphase implementation. To be honest, I was
expecting to see some code similar to mine, with a "viewable" input delay
line, and additional delay lines for the decimation of the samples, prior to
filtering, one filter per branch.

After a thorough study of the code and actually running (and debugging) it
on MSVC++ (which I couldn't do when I first replied to Jim), I could really
understand it... What a clean and beautiful implementation of decimation
filters, the polyphase way!

Although I am just up to integrate and test it with my SHARC code, it looks
like it won't be a source of confusion anymore!

I'll let you know how does it go.

Kindest regards,

--
Jaime Andrés Aranguren Cardona
jaac@nospam.sanjaac.com
SanJaaC Electronics
Soluciones en DSP
www.sanjaac.com

(Remove "nospam" from e-mail address)

> > My understanding is that polyphase only comes into play during
interpolation.
> > It's only during interpolation that you get the opportunity to skip
> > through the coefs - essentially choosing a phase of the impulse
> > response. In decimation you work on contiguous samples, but only
> > calculate the outputs you're going to keep.
> >
> >
> > Am I wrong?
>
>
> In a polyphase M-fold decimator, you have M polyphase filter coefficient
sets
> E_0 through E_{M-1} that each operate at the outgoing sample rate. Each
section
> is fed from an M-fold downsampler. M phases of the input signal are
obtained
> at the M downsampler outputs by delaying the input of each by a sample.
Then
> each polyphase section is convolved and the results summed. Again
> your computations require M*K*Fs multiplications/second instead of
M^2*K*Fs,
> where Fs is the output sample rate.

This is how I understand it is, too... Don't see the reason for Jim to say
that polyphase only comes into play during interpolation. Could you Jim
please explain me your point of view?

As I see on most diagrams, you have the filter splitted in branches, each
one having a different phase response, thus the term "polyphase", both in
interpolation and decimation filters.

I ask too, "Am I wrong?".

Regards,

--
Jaime Andrés Aranguren Cardona
jaac@nospam.sanjaac.com
SanJaaC Electronics
Soluciones en DSP
www.sanjaac.com

(Remove "nospam" from e-mail address)

In article <10s36eofav28raa@corp.supernews.com>,
Jim Thomas <jthomas@bittware.com> wrote:
>The interpolation code on dspguru is most definitely polyphase.
>
>My understanding is that polyphase only comes into play during interpolation.
>It's only during interpolation that you get the opportunity to skip through
>the coefs - essentially choosing a phase of the impulse response.

Why choose a phase with one can calculate the coefficients of the
precise phase?

I prefer to think of both upsampling, interpolation and decimation as
identical processes, consisting of a filter plus an interpolator. If the
decimation results line up with the input, the the interpolator become
trivial (constant phase 0). The lowpass filter usually changes to cut at
near or under half the minima of the input and output sample frequencies.
The filter+interpolator (usually a windowed sync) coefficients can
sometimes be calculated directly, per sample, even in real-time on
a fast PC, no precalculated phase table lookup required except for
efficiency reasons (and the sin/cos routines can be more cache friendly
than large lookup tables on embedded systems with tiny caches). This,
of course, depends on the choice of window function (which can be much
more expensive than calculating a cosine or three).

The upsample-decimate and polyphase table method are merely opaque
optimizations, needed for systems with various performance or power
limitations. How often does one write their own sin/cos routines
for any other generic program?


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

"Jaime Andrés Aranguren Cardona" <jaac@nospam.sanjaac.com> writes:

> > > My understanding is that polyphase only comes into play during
> interpolation.
> > > It's only during interpolation that you get the opportunity to skip
> > > through the coefs - essentially choosing a phase of the impulse
> > > response. In decimation you work on contiguous samples, but only
> > > calculate the outputs you're going to keep.
> > >
> > >
> > > Am I wrong?
> >
> >
> > In a polyphase M-fold decimator, you have M polyphase filter coefficient
> sets
> > E_0 through E_{M-1} that each operate at the outgoing sample rate. Each
> section
> > is fed from an M-fold downsampler. M phases of the input signal are
> obtained
> > at the M downsampler outputs by delaying the input of each by a sample.
> Then
> > each polyphase section is convolved and the results summed. Again
> > your computations require M*K*Fs multiplications/second instead of
> M^2*K*Fs,
> > where Fs is the output sample rate.
>
> This is how I understand it is, too... Don't see the reason for Jim to say
> that polyphase only comes into play during interpolation. Could you Jim
> please explain me your point of view?

I know I'm not Jim, but I see what he was saying. Think of it like
this. The meat-headed way to do decimation is to compute the
convolution of the full (non-polyphase) filter and input data at every
input sample. Then you toss M-1 out of M of those computed
outputs. The non-polyphase but still-computationally-efficient way is
to perform a full filter convolution at every Mth input sample but
using all K*M input samples to do it with, i.e.,

y[n] = sum_{j=0}^{K*M-1} x[n*M - j] * h[j].

(Remember here that the filter length is K*M.)

This method still only takes M*K*Fs multiplies/second but it doesn't require
the filter to be partitioned.

> As I see on most diagrams, you have the filter splitted in branches, each
> one having a different phase response, thus the term "polyphase", both in
> interpolation and decimation filters.
>
> I ask too, "Am I wrong?".

It's almost a matter of how you write it. The linear convolution is

y[n] = x[n*M + 0*M - 0] * h[ 0*M + 0] + x[n*M + 0*M - 1] * h[ 0*M + 1] + ... + x[n*M + 0*M - (M-1)] * h[ 0*M + (M-1)]
+ x[n*M + 1*M - 0] * h[ 1*M + 0] + x[n*M + 1*M - 1] * h[ 1*M + 1] + ... + x[n*M + 1*M - (M-1)] * h[ 1*M + (M-1)]
+ ...
+ x[n*M + (K-1)*M - 0] * h[(K-1)*M + 0] + x[n*M + (K-1)*M - 1] * h[(K-1)*M + 1] + ... + x[n*M + (K-1)*M - (M-1)] * h[(K-1)*M + (M-1)]

To get the "polyphase" version just look at this column-wise instead of row-wise.
--
Randy Yates
Sony Ericsson Mobile Communications
Research Triangle Park, NC, USA
randy.yates@sonyericsson.com, 919-472-1124

"Randy Yates" <randy.yates@sonyericsson.com> wrote in message
news:xxpfz265etg.fsf@usrts005.corpusers.net...
> "Jaime Andrés Aranguren Cardona" <jaac@nospam.sanjaac.com> writes:
>
> > > > My understanding is that polyphase only comes into play during
> > interpolation.
> > > > It's only during interpolation that you get the opportunity to skip
> > > > through the coefs - essentially choosing a phase of the impulse
> > > > response. In decimation you work on contiguous samples, but only
> > > > calculate the outputs you're going to keep.
> > > >
> > > >
> > > > Am I wrong?
> > >
> > >
> > > In a polyphase M-fold decimator, you have M polyphase filter
coefficient
> > sets
> > > E_0 through E_{M-1} that each operate at the outgoing sample rate.
Each
> > section
> > > is fed from an M-fold downsampler. M phases of the input signal are
> > obtained
> > > at the M downsampler outputs by delaying the input of each by a
sample.
> > Then
> > > each polyphase section is convolved and the results summed. Again
> > > your computations require M*K*Fs multiplications/second instead of
> > M^2*K*Fs,
> > > where Fs is the output sample rate.
> >
> > This is how I understand it is, too... Don't see the reason for Jim to
say
> > that polyphase only comes into play during interpolation. Could you Jim
> > please explain me your point of view?
>
> I know I'm not Jim, but I see what he was saying. Think of it like
> this. The meat-headed way to do decimation is to compute the
> convolution of the full (non-polyphase) filter and input data at every
> input sample. Then you toss M-1 out of M of those computed
> outputs. The non-polyphase but still-computationally-efficient way is
> to perform a full filter convolution at every Mth input sample but
> using all K*M input samples to do it with, i.e.,
>
> y[n] = sum_{j=0}^{K*M-1} x[n*M - j] * h[j].
>
> (Remember here that the filter length is K*M.)
>
> This method still only takes M*K*Fs multiplies/second but it doesn't
require
> the filter to be partitioned.
>
> > As I see on most diagrams, you have the filter splitted in branches,
each
> > one having a different phase response, thus the term "polyphase", both
in
> > interpolation and decimation filters.
> >
> > I ask too, "Am I wrong?".
>
> It's almost a matter of how you write it. The linear convolution is
>
> y[n] = x[n*M + 0*M - 0] * h[ 0*M + 0] + x[n*M + 0*M - 1] *
h[ 0*M + 1] + ... + x[n*M + 0*M - (M-1)] * h[ 0*M + (M-1)]
> + x[n*M + 1*M - 0] * h[ 1*M + 0] + x[n*M + 1*M - 1] *
h[ 1*M + 1] + ... + x[n*M + 1*M - (M-1)] * h[ 1*M + (M-1)]
> + ...
> + x[n*M + (K-1)*M - 0] * h[(K-1)*M + 0] + x[n*M + (K-1)*M - 1] *
h[(K-1)*M + 1] + ... + x[n*M + (K-1)*M - (M-1)] * h[(K-1)*M + (M-1)]
>
> To get the "polyphase" version just look at this column-wise instead of
row-wise.

Nicely done Randy - good explanation!

Cheers
Bhaskar

> --
> Randy Yates
> Sony Ericsson Mobile Communications
> Research Triangle Park, NC, USA
> randy.yates@sonyericsson.com, 919-472-1124

"Bhaskar Thiagarajan" <bhaskart@my-deja.com> writes:
> [...]
> Nicely done Randy - good explanation!

Thanks Bhaskar! Since I had just studied these structures in my DSP
class at NC State I was particularly up on the topic.
--
Randy Yates
Sony Ericsson Mobile Communications
Research Triangle Park, NC, USA
randy.yates@sonyericsson.com, 919-472-1124

On Thu, 16 Dec 2004 09:21:11 -0500, Jim Thomas <jthomas@bittware.com>
wrote:

>Jaime Andrés Aranguren Cardona wrote:
>> "Jim Thomas" <jthomas@bittware.com> escribió en el mensaje
>> news:10s0pegaj0r88e9@corp.supernews.com...
>>
>>>Jaime Andrés Aranguren Cardona wrote:
>>>
>>>>What else could I try, guys? I'd really appreciate if you can take a
>>
>> look at
>>
>>>>my code, and help me find out where the mistakes can be, or provide me
>>
>> with
>>
>>>>some reference C code.
>>>>
>>>>Thanks you very much in advance,
>>>
>>>Did you see Grant's multirate code on dspguru.com?
>>>
>>
>>
>> Hi Jim,
>>
>> Yes I did. It is not polyphase, right? I'd love it was... Any example in C
>> with ployphase implementation?
>
>The interpolation code on dspguru is most definitely polyphase.
>
>My understanding is that polyphase only comes into play during interpolation.
>It's only during interpolation that you get the opportunity to skip through the
>coefs - essentially choosing a phase of the impulse response. In decimation you
>work on contiguous samples, but only calculate the outputs you're going to keep.
>
>Am I wrong?

I'm coming in in the middle of this and there's already a lot of good
responses here, but:

Polyphase filters are commonly used in decimating applications when
the decimated samples need to be interpolated somewhere in between
where the original samples were. Many modern communications systems
do this for symbol recovery, where an oversampled input is
simultaneously phase-locked and downsampled to the signal symbols.
Polyphase filters are great for this since the symbol rate can be
changed without changing the ADC sample rate and the related
anti-alias filters, etc.


Eric Jacobsen
Minister of Algorithms, Intel Corp.
My opinions may not be Intel's opinions.
http://www.ericjacobsen.org

Randy Yates wrote:
[snip]
>
>
> It's almost a matter of how you write it. The linear convolution is
>
> y[n] = x[n*M + 0*M - 0] * h[ 0*M + 0] + x[n*M + 0*M - 1] * h[ 0*M + 1] + ... + x[n*M + 0*M - (M-1)] * h[ 0*M + (M-1)]
> + x[n*M + 1*M - 0] * h[ 1*M + 0] + x[n*M + 1*M - 1] * h[ 1*M + 1] + ... + x[n*M + 1*M - (M-1)] * h[ 1*M + (M-1)]
> + ...
> + x[n*M + (K-1)*M - 0] * h[(K-1)*M + 0] + x[n*M + (K-1)*M - 1] * h[(K-1)*M + 1] + ... + x[n*M + (K-1)*M - (M-1)] * h[(K-1)*M + (M-1)]
>
> To get the "polyphase" version just look at this column-wise instead of row-wise.

I think I see where you're going with this, but I still have questions. In
order to get my brain wrapped around this equation I had to plug in some real
numbers. I chose M=3 and K=3. Unless I made a tragic error, the above reduces to:

y[n] = x[n*3 + 0] * h[0] + x[n*3 - 1] * h[1] + x[n*3 - 2] * h[2]
+ x[n*3 + 3] * h[3] + x[n*3 + 2] * h[4] + x[n*3 + 1] * h[5]
+ x[n*3 + 6] * h[6] + x[n*3 + 5] * h[7] + x[n*3 + 4] * h[8]

Still having trouble, so I plug in n=0 and try again:
y[0] = x[ 0] * h[0] + x[-1] * h[1] + x[-2] * h[2]
+ x[ 3] * h[3] + x[ 2] * h[4] + x[ 1] * h[5]
+ x[ 6] * h[6] + x[ 5] * h[7] + x[ 4] * h[8]

and again, with n=1:
y[1] = x[3] * h[0] + x[2] * h[1] + x[1] * h[2]
+ x[6] * h[3] + x[5] * h[4] + x[4] * h[5]
+ x[9] * h[6] + x[8] * h[7] + x[7] * h[8]

It looks to me like x needs both its rows and columns swapped. I'd be a lot
happier if I ended up with something like this:

y[1] = x[9] * h[0] + x[8] * h[1] + x[7] * h[2]
+ x[6] * h[3] + x[5] * h[4] + x[4] * h[5]
+ x[3] * h[6] + x[2] * h[7] + x[1] * h[8]

Again, I'm allowing ample room for the possibility that I'm wrong, so don't be
shy! Is your equation correct?

--
Jim Thomas Principal Applications Engineer Bittware, Inc
jthomas@bittware.com http://www.bittware.com (603) 226-0404 x536
Hope springs occasionally.

Jim Thomas <jthomas@bittware.com> writes:

> Randy Yates wrote:
> [snip]
>> It's almost a matter of how you write it. The linear convolution is
>> y[n] = x[n*M + 0*M - 0] * h[ 0*M + 0] + x[n*M + 0*M - 1]
>> * h[ 0*M + 1] + ... + x[n*M + 0*M - (M-1)] * h[ 0*M +
>> (M-1)]
>> + x[n*M + 1*M - 0] * h[ 1*M + 0] + x[n*M + 1*M - 1] * h[ 1*M + 1] + ... + x[n*M + 1*M - (M-1)] * h[ 1*M + (M-1)]
>> + ...
>> + x[n*M + (K-1)*M - 0] * h[(K-1)*M + 0] + x[n*M + (K-1)*M - 1] * h[(K-1)*M + 1] + ... + x[n*M + (K-1)*M - (M-1)] * h[(K-1)*M + (M-1)]
>> To get the "polyphase" version just look at this column-wise instead
>> of row-wise.
>
> I think I see where you're going with this, but I still have
> questions. In order to get my brain wrapped around this equation I
> had to plug in some real numbers. I chose M=3 and K=3. Unless I made
> a tragic error, the above reduces to:
>
> y[n] = x[n*3 + 0] * h[0] + x[n*3 - 1] * h[1] + x[n*3 - 2] * h[2]
> + x[n*3 + 3] * h[3] + x[n*3 + 2] * h[4] + x[n*3 + 1] * h[5]
> + x[n*3 + 6] * h[6] + x[n*3 + 5] * h[7] + x[n*3 + 4] * h[8]
>
> Still having trouble, so I plug in n=0 and try again:
> y[0] = x[ 0] * h[0] + x[-1] * h[1] + x[-2] * h[2]
> + x[ 3] * h[3] + x[ 2] * h[4] + x[ 1] * h[5]
> + x[ 6] * h[6] + x[ 5] * h[7] + x[ 4] * h[8]
>
> and again, with n=1:
> y[1] = x[3] * h[0] + x[2] * h[1] + x[1] * h[2]
> + x[6] * h[3] + x[5] * h[4] + x[4] * h[5]
> + x[9] * h[6] + x[8] * h[7] + x[7] * h[8]
>
> It looks to me like x needs both its rows and columns swapped. I'd be
> a lot happier if I ended up with something like this:
>
> y[1] = x[9] * h[0] + x[8] * h[1] + x[7] * h[2]
> + x[6] * h[3] + x[5] * h[4] + x[4] * h[5]
> + x[3] * h[6] + x[2] * h[7] + x[1] * h[8]
>
> Again, I'm allowing ample room for the possibility that I'm wrong, so
> don't be shy! Is your equation correct?

Nope! You're right. I had a sign problem in the x's. This corrects that problem (hopefully
there are no others!):

y[n] = x[n*M - 0*M - 0] * h[ 0*M + 0] + x[n*M - 0*M - 1] * h[ 0*M + 1] + ... + x[n*M - 0*M - (M-1)] * h[ 0*M + (M-1)]
+ x[n*M - 1*M - 0] * h[ 1*M + 0] + x[n*M - 1*M - 1] * h[ 1*M + 1] + ... + x[n*M - 1*M - (M-1)] * h[ 1*M + (M-1)]
+ ...
+ x[n*M - (K-1)*M - 0] * h[(K-1)*M + 0] + x[n*M - (K-1)*M - 1] * h[(K-1)*M + 1] + ... + x[n*M - (K-1)*M - (M-1)] * h[(K-1)*M + (M-1)]

Thanks for the correction, Jim.
--
% Randy Yates % "Maybe one day I'll feel her cold embrace,
%% Fuquay-Varina, NC % and kiss her interface,
%%% 919-577-9882 % til then, I'll leave her alone."
%%%% <yates@ieee.org> % 'Yours Truly, 2095', *Time*, ELO
http://home.earthlink.net/~yatescr

Randy Yates wrote:
> Jim Thomas <jthomas@bittware.com> writes:
[snip]
>>Again, I'm allowing ample room for the possibility that I'm wrong, so
>>don't be shy! Is your equation correct?
>
>
> Nope! You're right. I had a sign problem in the x's. This corrects that problem (hopefully
> there are no others!):
>
> y[n] = x[n*M - 0*M - 0] * h[ 0*M + 0] + x[n*M - 0*M - 1] * h[ 0*M + 1] + ... + x[n*M - 0*M - (M-1)] * h[ 0*M + (M-1)]
> + x[n*M - 1*M - 0] * h[ 1*M + 0] + x[n*M - 1*M - 1] * h[ 1*M + 1] + ... + x[n*M - 1*M - (M-1)] * h[ 1*M + (M-1)]
> + ...
> + x[n*M - (K-1)*M - 0] * h[(K-1)*M + 0] + x[n*M - (K-1)*M - 1] * h[(K-1)*M + 1] + ... + x[n*M - (K-1)*M - (M-1)] * h[(K-1)*M + (M-1)]
>
> Thanks for the correction, Jim.

That's better, and now I see what you mean. But... it seems to me that
arranging the filter equation into rows and columns like this is somewhat
artificial.

At this point I'm just going to confuse people who already understand polyphase
filters but aren't confident in their understanding, and for that, I apologize
in advance. I guess I'm firmly in that same camp.

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?

--
Jim Thomas Principal Applications Engineer Bittware, Inc
jthomas@bittware.com http://www.bittware.com (603) 226-0404 x536
Getting an inch of snow is like winning ten cents in the lottery - Calvin

Jim Thomas <jthomas@bittware.com> writes:

> Randy Yates wrote:
> > Jim Thomas <jthomas@bittware.com> writes:
> [snip]
> >>Again, I'm allowing ample room for the possibility that I'm wrong, so
> >>don't be shy! Is your equation correct?
> > Nope! You're right. I had a sign problem in the x's. This corrects
> > that problem (hopefully
>
> > there are no others!):
> > y[n] = x[n*M - 0*M - 0] * h[ 0*M + 0] + x[n*M - 0*M -
> > 1] * h[ 0*M + 1] + ... + x[n*M - 0*M - (M-1)] * h[ 0*M +
> > (M-1)]
>
> > + x[n*M - 1*M - 0] * h[ 1*M + 0] + x[n*M - 1*M - 1] * h[ 1*M + 1] + ... + x[n*M - 1*M - (M-1)] * h[ 1*M + (M-1)]
> > + ...
> > + x[n*M - (K-1)*M - 0] * h[(K-1)*M + 0] + x[n*M - (K-1)*M - 1] * h[(K-1)*M + 1] + ... + x[n*M - (K-1)*M - (M-1)] * h[(K-1)*M + (M-1)]
> > Thanks for the correction, Jim.
>
>
> That's better, and now I see what you mean. But... it seems to me
> that arranging the filter equation into rows and columns like this is
> somewhat artificial.

I agree. But it sure sounds impressive.

> At this point I'm just going to confuse people who already understand
> polyphase filters but aren't confident in their understanding, and for
> that, I apologize in advance. I guess I'm firmly in that same camp.

I think you've got more on the ball than you think.

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

In a sense, yes. The difference between a "standard" FIR that is operating
in a system in which the input and output sample rate is the same and a
decimator is that you don't skip output computations.

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.
--
Randy Yates
Sony Ericsson Mobile Communications
Research Triangle Park, NC, USA
randy.yates@sonyericsson.com, 919-472-1124

"Randy Yates" <randy.yates@sonyericsson.com> wrote in message
news:xxpr7lp3pdz.fsf@usrts005.corpusers.net...
>
> 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').

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 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" <randy.yates@sonyericsson.com> wrote in message
> news:xxpr7lp3pdz.fsf@usrts005.corpusers.net...
> >
> > 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').