Solving u0u0 problems

GNU Radio
1

Based on different fft-sizes I am getting u0u0u0u0 output.
The strange thing is an “unregular” fft-size of 1088 doesnt produce
the error but fft-size 1024 does
also a smaller fft-size of 544 does produce the error.

So what is causing this kind of error and which approaches can I use
to debug this?

2

On 05/07/2011 12:31 PM, Johannes S. wrote:

Based on different fft-sizes I am getting u0u0u0u0 output.
The strange thing is an “unregular” fft-size of 1088 doesnt produce
the error but fft-size 1024 does
also a smaller fft-size of 544 does produce the error.

So what is causing this kind of error and which approaches can I use
to debug this?

What type of sample rates? What compute platform?

FFTW performance is often counter-intuitive.

Are you using the default TPB scheduling?

What else is in your flow-graph?

3

Hi Marcus,

What type of sample rates? What compute platform?
We are running on Ubuntu 10.10 64bit. What do you mean with type of
sample rates? Maybe USRP decimation rate? I am changing fft-size based
on this.
So for 4MHz i am using 1088 fft-size and for 2MHz i am using 544MHz
and I am getting the problem when running with 2MHz.

FFTW performance is often counter-intuitive.
Can you explain this?

Are you using the default TPB scheduling?
What is TPB scheduling? How can I find out more about scheduling? I
never found something like this in the documentation.

What else is in your flow-graph?
First block is a stream to vector conversion. Then I am doing a number
of operations on this vectors using standard GNUradio blocks as well
as some custom made blocks.

I still don’t know what this u0u0 means and from which part of
GNUradio it comes from. Is suppose it is some kind of buffer overflow
between the blocks or something like that?

Regards,
Johannes

4

We are running on Ubuntu 10.10 64bit. What do you mean with type of
sample rates? Maybe USRP decimation rate? I am changing fft-size based
on this.
So for 4MHz i am using 1088 fft-size and for 2MHz i am using 544MHz
and I am getting the problem when running with 2MHz.

I mean what sample rates–it sounds like 2Msps and 4Msps.

FFTW performance is often counter-intuitive.

Can you explain this?

FFTW uses a dynamic optimizer based on the FFT size. If you’re using an
FFT size that
isn’t a power of 2, it’s rather hard to predict whether the resulting
FFT will be optimal
or not.

Are you using the default TPB scheduling?

What is TPB scheduling? How can I find out more about scheduling? I
never found something like this in the documentation.

If you haven’t touched it, then you’re using TPB (Thread Per Block)
scheduling.

First block is a stream to vector conversion. Then I am doing a number
of operations on this vectors using standard GNUradio blocks as well
as some custom made blocks.

I still don’t know what this u0u0 means and from which part of
GNUradio it comes from. Is suppose it is some kind of buffer overflow
between the blocks or something like that?

uO means USRP overrun–the USRP is delivering data at a rate that is
faster than your flow-graph
can keep up with, causing overruns. The only way to cure this is to
reduce your sample rates,
reduce your flow-graph computational complexity, or use a
higher-performance computer.

–
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

5

Hey Marcus,
I used oprofile to get a better idea where the problem is located.
I found that it is indeed a problem with libfftw3.
Besides the gnuradio fft block I am calculating a crosscorrelation
using the fft. That means fft-size will be 2*N-1 with vectorlength N.
So for 1024 vectorlength I will be calculating an fft of size 2047.
Maybe this is the problem.

Now my idea is to pad the fft input to a power of 2 size or use a
cyclic cross correlation instead.

Any other suggestions?

Johannes

6

Having the FFT size being 2**N will certainly help, but given your
relatively low data rate, it shouldn’t be a problem
anyway. Are you calculating the cross-correlation in Python code, or C++
code? That will make a large difference.

I am calculating it in C++. I couldn’t find a gnuradio block who did
this so I had to write it on my own.
By the way is there a possibility to suggest new blocks to be added to
gnuradio?
If you want I can post the code for the block in the mailing list.

Also, are you using an audio port in this anywhere, and are you properly
rate-matching?
What do you mean with properly rate matching? I don’t use any audio
port.

Johannes

7

Hi Marcus,

Tom R., on the mailing list, is the guy to talk to about adding new
blocks. There is a correlator block already.
Ok, maybe I will contact Tom.
Which block do you mean exactly?
I am looking for a block that acts like xcorr() in matlab. There is no
such block.

I refer to sample-rate matching. For example, audio devices often run at a
sample rate of 44.1Ksps, which is obviously
different than the sample rate you’re using in your flow-graph. So if your
flow-graph ends up (for example) sending output
to an audio sink, the sample stream has to be decimated or interpolated to
the rate of the audio sink. Sometimes, people forget
this when using the audio sinks, and get into the types of trouble you’re
observing.
I am not doing something like this. We are working with USRP’s.

By the way I was able to fix the initial problem using a cyclic cross
correlation function with power of 2 fft-size.