Hi,

I am modelling a polyphase decimation filter in Simulink. In literature there are 2 variant implementations:

• with a commutator
• with extra delay elements and decimators

Slide 25 shows block diagram with commutator and slide 24 without in below presentation:

http://www.ws.binghamton.edu/fowler/fowler%20perso...

The attached PolyphaseDecimation2.slx is the version without commutator that gives correct results.

In the attached PolyphaseDecimation.slx I try to simulate the commutator variant. But there is a huge difference between normal filter followed by decimation versus my polyphase implementation. The sine generator makes frames of 4 samples and with a demux I unpack such a frame to four values. Let's calculate the first output value. For the full filter this is the value input(0)*h(0) that will be selected by the decimator as the delay elements are initialized with zeros. The next 3 values coming out of the filter will be discarded. For my filter it is input(0)*h(0)+input(1)*h(1)+input(2)*h(2)+input(3)*h(3). This is clearly different and this is because the input(1:3) are directly used without a delay element.

So probably my interpretation of a polyphase decimator with commutator is not correct? Or are the two variants really different?

Kind regards, Bert

The Simulink files are available at https://www.mathworks.com/matlabcentral/answers/46...

Are you doing your unpacking of the 4-sample frame correctly, so that the most recent sample is multiplied by h[0] and so on. It is easy to get the order reversed, and something you can easily check to see if that gives you the correct answer.

The computed results should be the same for both methods.

Just a comment on this already-solved problem: a good way to test this sort of thing is to run a collection of impulses through the system at various delays (various delays because a polyphase filter is not shift-invariant).

The commutated filter is just a way of reducing computation time over the upsample, filter, downsample version, so the results should be completely and exactly the same, with the possible exception of round-off errors.

It should be an easy test to do, and it should shine a good strong light on any problems.

Hi,

Thanks for sharing this test strategy!

Kind regards,

Bert

Thank you for this hint!

Indeed my formula input(0)*h(0)+input(1)*h(1)+input(2)*h(2)+input(3)*h(3) was incorrect, input was in the wrong order.

It has to be input(3)*h(0)+input(2)*h(1)+input(1)*h(2)+input(0)*h(3) and indeed the filters had to be applied in reverse order.

The other mistake I made was that the downsampler was taking the first sample of the four, while to be the same as the formula I just gave, it should be the last sample of the four. This can easily been done in this Simulink block, but the problem is that selecting another sample than the first adds latency and outputs first a zero. To compensate for that, I added a delay element after the commutator decimator.

And now both implementations give the same result. Problem solved!

The updated Simulink file can be found at https://www.mathworks.com/matlabcentral/answers/46...

Hello,

I send you a script and a model for two solution of decimation: the classical and with the polyphasefilters.

Regard 

josefsepp

polyphase_solution1.m

polyphase_solution_1.slx

Hi,

Thank you very much for sharing your implementation. It is in many ways different from mine, very interesting.

Kind regards,

Bert

Hello,

Here's another solution with a block Delay Line:

polyphase_solution_2.slx

polyphase_solution2.m

The delay block with a delay equal to one is necessary because the blocks Buffer and Delay Line insert a latent delay. Only then do you get the same output results.

Instead of the block Flip you can invert the order of the filters. The Buffer and Delay Line Block are first in and last out and you usually need first in first out behavior.

Regards

Josefsepp

Hi,

Thank you very much for this second implementation and explanation.

Kind regards,

Bert