USB transfers speeds with USRP 1

GNU Radio
1

Can anyone please help me with something?

I have an application using 2 tv tuner modules that I need to capture
samples from. The code that explains what the setup follows.

self.u = usrp.source_c(decim_rate = options.decim, nchan = 2)

self.skiphead0 = gr.skiphead(gr.sizeof_gr_complex, 1000)
self.skiphead1 = gr.skiphead(gr.sizeof_gr_complex, 1000)
self.head0 = gr.head(gr.sizeof_gr_complex, int(options.nsamples ))
self.head1 = gr.head(gr.sizeof_gr_complex, int(options.nsamples ))

self.di = gr.deinterleave(gr.sizeof_gr_complex)
self.dst0 = gr.file_sink(gr.sizeof_gr_complex, filename0)
self.dst1 = gr.file_sink(gr.sizeof_gr_complex, filename1)

self.connect(self.u, self.di)

self.connect((self.di,0), self.skiphead0, self.head0, self.dst0)
self.connect((self.di,1), self.skiphead1, self.head1, self.dst1)

self.u.set_mux(gru.hexint(0xf2f0f2f0))

After this I set the gains of the tv tuners and the ddc and tuner
frequencies. When I use a decimation of 16 (resulting in two IQ
channels at 4Msps each) and try to capture 10seconds of data, I get a
lot of ‘uO’ messages on the console. When I use a decimation of 32, I
still get some ‘uO’ messages on the console. Only when using a
decimation of 64 (two 1Msps IQ channels) do I not get any ‘uO’
messages when capturing 10s of data.

Now, the funny thing is that when I run test_usrp_standard_rx in
/usrp/host/apps using sudo ./test_usrp_standard_rx -D 8 -M 900, I get
noverruns=0. So with my PC and USRP I can actually get a transfer
rate of 32MB/s which leads me to believe that something in the setup
of my application might cause the problems with the USB transfer rate.

Does anyone have any ideas to what might be happening?

Thank you in advance.

Sebastiaan

–
Sebastiaan H.
Radar Remote Sensing Group, University of Cape Town, South Africa
Tel: +27 83 305 5667

2

Now, the funny thing is that when I run test_usrp_standard_rx in
/usrp/host/apps using sudo ./test_usrp_standard_rx -D 8 -M 900, I get
noverruns=0. So with my PC and USRP I can actually get a transfer
rate of 32MB/s which leads me to believe that something in the setup
of my application might cause the problems with the USB transfer rate.

Does anyone have any ideas to what might be happening?

I’ve run into similar issues and it probably has more to do with your
hard drive than your processor. test_usrp_standard_rx only tests the
usrp(usb) transfer rates, your flow graph probably chokes at the disk
writes.

A simple way to test this is to have the samples go to a null sink, if
you have no problems, then it’s your disk. You can test the speed
capabilities of your disk by setting up a signal source (or two, in
your case) of a specified rate and writing it to disk until you find a
good rate that you can sustain (hdparm will give you a good idea of
overall rates, but by testing with gnuradio directly you will have a
better idea of your capabilities in real world scenarios).

Jason

3

On Mon, Jul 27, 2009 at 1:10 PM, Jason U. [email protected] wrote:

I’ve run into similar issues and it probably has more to do with your
better idea of your capabilities in real world scenarios).

Jason

I’ve run into similar problems as well. Here is what helped me get past
this
problem:

  1. Enable Realtime mode (grc can do this for you). You might need to run
    as
    root
  2. Increasing fusb_nblocks and fusb_block_size. fusb_nblocks = 4096 and
    fusb_block_size=4096 seemed to work for me.
  3. Remounting my etx3 harddisk as ext2.

Hope this helps.
Karthik

4

Thanks, I managed to sort the problem out. Firstly, I enabled
realtime scheduling by looking at usrp_spectrum_sense.py. Next I used
the RAMdisk in Ubuntu /dev/shm to run my application in (thanks
Jason).

Result is that I am able to sample two channels at 4Msps IQ each and
write it to disk afterwards.

Sebastiaan