Re: [Discuss-gnuradio] Processing expectations

[Tom Rondeau]

On Fri, Aug 7, 2015 at 2:47 PM, Tom Cook <address@hidden> wrote:

I'm brand new to SDR and I'm just trying to calibrate my expectations of what will be possible in real time.  I'm hoping someone here can give me a pointer or two.

I'm running GNU Radio 3.7.2 on Ubuntu 14.04, having installed from the Ubuntu repositories.  The machine I'm using has an Intel Core i5-2520M running at 2500MHz.

I'm constructing flowgraphs in GRC and using an RTL-2832U-based USB dongle as a receiver.

I've built a fairly simple broadcast FM stereo receiver as an example.  It has the following components:

* RTL-SDR source (768k sample rate).

* Low pass filter (768k sample rate, 96k cutoff, 4k transition)

* Rational resampler (4x decimation)

* WBFM receiver (quadrature rate 192k)

* Low pass filter (1x decimation, 192k sample rate, 15k cutoff, 2k transition)

* 2x Band pass filter (1x decimation, 192k sample rate, differing cutoff and transition)

You've just strung together 5 filters in a row here. You can do your decimation step in the low pass filter, and the WBFM stage has a filter in it, as well. That 4k transition in the initial LPF at 768 kHz will make for a long filter; if that's also doing 4x down sampling, you'll remove a lot of processing requirements there.

Think about all of these filter stages and how you might be able to combine them and reduce their overall power requirement.s

 

* Multiply

* Low pass filter (192k sample rate, 15k cutoff, 2k transition)

* Add, subtract

* 2 x rational resampler (4x decimation)

* Audio sink (sample rate 48k)

Again, you can do the resampling and LPF together; that resampler implements its own filter. You can also integrate the multiply stage into the LPF by setting the gain of the taps to your multiply value.

 

My system is not able to run this in realtime, producing regular underruns (about two per second).  Decreasing the receiver sample rate to 384k and decreasing the decimation factor in the first resampler to 2 allows it to run in without underruns, from which I deduce that the CPU is right on the edge of being able to process the flowchart in realtime.

Are my expectations of what I'll be able to do in realtime unreasonably high?  Is there something I'm missing, that I can do to make this run much faster?

Thanks,

Tom

It sounds like you're close to what you need to get this working. Just think more about the filter stages and values. Use gr_filter_design to plot them and see how many taps you're using to help you reduce the computational requirements.

Tom