Analyzing RC response with convolution theorem and fft.

  • #1
davidbenari
466
18
Some textbooks like (Numerical recipes the art of scientific computing) derive the DFT as a Riemann sum of the CTFT. With this in mind it would be natural then to approximate the identity

##y(t)=x*h=\mathcal{F}^{-1}\big\{XH\big\}##

with the mathlab code y=ifft(fft(x).*fft(h)) which roughly means that my response is the inverse DFT of the product of the DFTs.

I have been reading recently that this approach isn't really valid in the case of the DFT. The relevant identity in the discrete realm is

##\mathcal{F}^{-1}(XH)_{n}=\sum_{l=0}^{N-1} x_l (y_N)_{n-l}##

which is called a circular convolution.

But so far, my ifft(fft...) approach yields results that are completely compatible with the analytical results.

I also want to mention that I have checked for the well-known result that convolving with a shifted impulse, shifts your response along the domain; and the result that scaling an impulse, scales the response.

I've implemented impulses by inputting the coefficient in the dirac-delta function in some position on a vector, without really justifying why this works.

So therefore I have two questions:

Why is the y=ifft(fft(x).*fft(h)) approach valid and compatible with the theory? Is this the way its supposed to be? How can I justify such a thing? Why aren't the step factors ##dt## involved in this approach?

Why are impulses correctly modeled by only inputting the coefficient that would correspond to the dirac-delta function? (This seems intuitive to me, but I wouldn't like to say my opinion as I would prefer to listen to you mostly).

Finally, if I want to analyze another signal like cos(t), I do have to include the step ##dt## in order to get results congruous with the analytical results. Why is this occurring ?

Thanks!
 
Engineering news on Phys.org
  • #2
Circular convolution using DFT will give you approximately the same results as regular convolution as long as you zero-pad your input vectors, typically you make them twice as long as the input data,.

This is for the usual reason: the original identity requires you to integrate +-inf; in a DFT you obviously have to use a finite sized vector and this truncation is what is causing problems. A DFT is never just a "numerical Fourier transform", there are a whole bunch of issues that you need to keep track of to avoid errors (see windowing, padding etc)
 
Last edited:
  • Like
Likes davidbenari

Similar threads

Replies
2
Views
6K
Replies
7
Views
3K
Replies
5
Views
3K
Replies
7
Views
2K
Replies
3
Views
2K
Replies
6
Views
6K
Replies
1
Views
1K
Back
Top