discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] DPSK demodulator computational efficiency


From: Tom Rondeau
Subject: Re: [Discuss-gnuradio] DPSK demodulator computational efficiency
Date: Tue, 10 Jun 2014 09:45:29 -0400

On Tue, Jun 10, 2014 at 9:31 AM, Kevin Langer <address@hidden> wrote:

Hi!

I am interested in the implementation of the DPSK demodulator block in GNU radio. I have been profiling and debugging code to better understand the implementation of this block. One thing I noticed is that all of the baseband filtering happens in the time domain. I find this peculiar because the convolution for the FIR filter is consuming ~30% of the call time (specifically on the calculation of the inner product).

The raised cosine filter (in fll_band_edge) appears to be consuming much of the CPU time during demodulation. Curious, I plotted the time required to execute time domain and frequency domain FIR filters and found that even for a low number of taps (55 in the DPSK demod example), the FFT version preforms much better than the convolution approach.

My question is, what am I missing about the data path flow that makes time domain filtering more attractive than frequency domain? It seems clear that an FFT approach to filtering would preform better but the entire provided demodulator block keeps the signal in the time domain. While I realize that there are benefits from preforming the matched filter at the same time as timing correction--as far as I can tell--these filters steps exist at a different level than the baseband filtering.

I would be interested to hear from anyone who has experience with DPSK demodulation implementation, and specifically anyone who has experience with computationally efficient receivers.


~Thanks


I actually thought that I changed that to an FFT filter a while ago. But the main reason it started its life using the time-domain FIR filters was because that's what was available at the time. The fir_filter kernels were already broken out and easy to use. We've since broken out the fft_filter blocks into usable kernels for purposes like this. So yes, it should be possible and beneficial to make this switch.

See if you can make the switch and make it work. There are a few i/o caveats about using the fft_filter over the fir_filter (since it works on a block at a time), but if you do, send us a patch!

Tom
 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]