USRP Under Flow

Hi all;

   Thanks to Mr. Balister I run USRP on BeagleBoard (

http://www.opensdr.com/node/17) . But it doesn’t give any sound when I
try
to listen FM radio. I think there is some mismatch in sampling rates or
data
format. I read other mail list archives but they didn’t solve my
problem.
Here is my console :

[email protected]:/usr/share/gnuradio/examples/usrp#
./usrp_wfm_rcv_nogui.py
Using RX d’board A: Basic Rx

gr_fir_fff: using cortex_a8
Freq: 100.1M Volume:0.100000 Setting:FREQ
OK
aUaUaUaUaUaUaUaUuOaUaUaUaUaUuOaUaUaUaUaUuOaUaUaUaUaUuOaUaUaUaUaUuOaUaUaUaUaUuOaUaUaUaUuOaUaUaUaUaUuOaUaUaU

(No Sound Here goes like this )

On 03/16/2010 06:51 AM, halidziya yerebakan wrote:

gr_fir_fff: using cortex_a8
Freq: 100.1M Volume:0.100000 Setting:FREQ
OK
aUaUaUaUaUaUaUaUuOaUaUaUaUaUuOaUaUaUaUaUuOaUaUaUaUaUuOaUaUaUaUaUuOaUaUaUaUaUuOaUaUaUaUuOaUaUaUaUaUuOaUaUaU

(No Sound Here goes like this )

Run oprofile, find the code that takes all the time, optimize using
NEON, repeat :slight_smile:

The sample rate conversions will be the CPU hogs for this waveform. It
looks like you are using an optimized fir filter already, but work
through the sample rates at each step. It is possible the audio out is
doing another rate conversion. Also, the gnuradio block may create a
very long fir filter, you can adjust the filter design settings to
reduce the number of taps.

It will work, but you do not have many GHz of cpu to cover up
in-efficient design decisions :slight_smile:

Philip

Philip-

Using RX d’board A: Basic Rx
The sample rate conversions will be the CPU hogs for this waveform. It
looks like you are using an optimized fir filter already, but work
through the sample rates at each step. It is possible the audio out is
doing another rate conversion. Also, the gnuradio block may create a
very long fir filter, you can adjust the filter design settings to
reduce the number of taps.

It will work, but you do not have many GHz of cpu to cover up
in-efficient design decisions :slight_smile:

At what rates are the OMAP 3530 cores running on the Beagle board? The
web page says “up to” 600 MHz for the ARM A8
and up to 430 MHz for the C64x+ core. Sometimes TI eval/dsk boards
don’t always run at max rate…

Also, do you know if anyone has done work to port GNU radio functions
over to the C64x+ core? For example you mention
sample rate conversion, that would be very suitable to offload onto the
DSP.

-Jeff

My beagle board is clone and it is working in 200MHZ , but when I run
the
program it doesn’t consumes to much CPU time

Hi!

Since there seem to be some issues with sample rate etc… are there
any recommendations for sound cards for Linux?

Best,
a.

Halidziya-

My beagle board is clone and it is working in 200MHZ , but when I run the program
it doesn’t consumes to much CPU time

A Beagle board clone? The Beagle board already costs less than its
component BOM.
Did you alter the design in some way?

Also, why only 200 MHz? That’s way slow… what is the reason?

-Jeff

Any way , my cpu is not very busy when it is working problem is some
where
else acording to me ,
I don’t know how to use blocks in python but maybe we can create a block
between audio device and output device that converts 32 khz to 48 khz

    audio_decimation = 10
    audio_rate = demod_rate / audio_decimation  # 32 kHz

On 03/17/2010 03:15 PM, Jeff B. wrote:

Halidziya-

My beagle board is clone and it is working in 200MHZ , but when I run the program
it doesn’t consumes to much CPU time

A Beagle board clone? The Beagle board already costs less than its component BOM.
Did you alter the design in some way?

There is the EBV clone in Europe and possibly ones from India and China.
It is easy to clone :slight_smile: I don’t think the Beagle sells under material
cost, but I suspect the margin is not a sustainable business model.

Also, why only 200 MHz? That’s way slow… what is the reason?

That sounds wrong. Stock Beagles run at 500 MHz and can be turned up to
600 MHz. Newer Beagles run up to 720Mhz

Yes, using the DSP is very interesting. Approaches range in complexity
from wrapping a call to do the processing in the DSP from the existing
gnuradio block structure to integrating the DSP into the gnuradio block
scheduler.

Philip

Hi every one ;

I listen music in my beagle board now

I use file sink

    self.gr_wavfile_sink_0 = gr.wavfile_sink("dosya.wav", 1,32000 , 

than I play with alsa tools

aplay -t wav -c 2 -r 32000 -f S16_LE -v dosya.wav

On 03/18/2010 07:21 AM, halidziya yerebakan wrote:

Any way , my cpu is not very busy when it is working problem is some where
else acording to me ,
I don’t know how to use blocks in python but maybe we can create a block
between audio device and output device that converts 32 khz to 48 khz

When it underflows, I suspect there is idle time while the system
recovers. That drops the apparent CPU usage. Most likely the flowgraph
is waiting on the IO to notify you the underflow occurred.

     audio_decimation = 10
     audio_rate = demod_rate / audio_decimation  # 32 kHz

The fm demod already has a sample rate conversion in it, but it only
supports decimation, not resampling to an arbitrary rate. If you use an
external resampler to get the 32 kHz back to 48 kHz, you have two
different FIR filters running, when you really only need one.

Philip

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs