USRP underruns when attempting simultaneous receive and transmit

GNU Radio
1

Hi All,

summary: If I try and receive and transmit data from and to the USRP
simultaneously at the same data rate (no matter what it is, even as low
as 2MB/s each way) I always get usrp underruns.

Background

I have a simple cross band repeater type example running under Gnuradio
3.1.1. Basically I have configured an RFX400 to receive an FM type
modulated signal on one frequency (452.75MHz) and retransmit that same
signal either as complex baseband to an LFTX daughterboard, or an RF
signal at another frequency (440MHz) by the RFX400. Currently this
involves simultaneous reception and transmission of data across the
USB2.0 interface. I’ve typically been using usrp_decim values of 128
(i.e500Ks/s, complex = 2MB/s), and usrp_inter of 256, again giving a
nominal data rate to the usrp of 2MB/s.

I have verified the USB2.0 simplex performance of my PC (Pentium D
2.8GHz, 1GB RAM) by running standard gnuradio scripts such as
usrp_fft.py for testing the data throughput to the PC. I was able to set
the decimation rate of the fft scope to 8 (giving 8MS/s, complex, I
assume => 32MB/s) without any usrp over runs reported.Decimation value
below 8 start giving usrp over runs, as expected.

On the PC to USRP side: I’ve used usrp_siggen.py to generate a sine wave
on the PC and output it from the LFTX daughterboard. I kep reducing the
usrp interpolation rate until I started to see under runs reported. This
happened at an a value of 12, at 14 it was OK. I was expecting 16 would
be my lower limit (128MS/s / 16 = 8MS/s = 32MB/s over usb2.0) but it
would appear my PC USB controller is slightly better at sending data
than receiving.

Anyway, to get to the point. If I try and receive and transmit data
simultaneously at the same data rate (no matter what it is, even 2MB/s)
I always get usrp underruns.

Questions

  1. Do others see the same thing?
  2. Is this because any buffering that’s going at the PC end is
    insufficient to smooth out any slight differences in actual receive and
    transmit data rates, leading to the occasional starving of the USRP’s
    usb receive buffers?
  3. If I configure my application to receive samples from the usrp at a
    lower rate than I retransmit them (using the rational resampler to
    interpolate) this significantly reduces any under run’s reported. Is
    this the generally used method to get around this particular issue?
  4. Is it possible to configure the USRP to directly pass samples from
    the receive to the transmit, bypassing the PC altogether? Could be
    useful to me as a basic RF passband to complex baseband, cutting out PC
    latencies.

Thanks in advance for your responses.

Cheers
Richard

=======================================================================
This email, including any attachments, is only for the intended
addressee. It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
altered or corrupted during transmission.

2

On Thu, Jan 31, 2008 at 01:50:32PM +1300, Richard C. wrote:

Hi All,

summary: If I try and receive and transmit data from and to the USRP
simultaneously at the same data rate (no matter what it is, even as low as
2MB/s each way) I always get usrp underruns.

Which operating system and distribution are you using?

Questions

  1. Do others see the same thing?

Haven’t tried.

  1. Is this because any buffering that’s going at the PC end is insufficient
    to smooth out any slight differences in actual receive and transmit data
    rates, leading to the occasional starving of the USRP’s usb receive
    buffers?

You’re running the two daughterboards (the rx and tx) on a single
USRP, right? In that case, the input and output rates will be locked
to the same clock.

If you’re running under Linux, I’d try specifying the fusb buffering
parameters in the usrp.source_c and usrp.sink_c constructors.

Use identical values on the source and sink. E.g.,

fusb_block_size = 4096 # must be a multiple of 512
fusb_nblocks = 4

src = usrp.source_c(0, decim,
fusb_block_size=fusb_block_size,
fusb_nblocks=fusb_nblocks)
…

dst = usrp.sink_c(0, interp,
fusb_block_size=fsub_block_size,
fusb_nblocks=fusb_nblocks)

and I’d enable realtime scheduling (you’ll need to be root or holding
CAP_SYS_NICE):

# Attempt to enable realtime scheduling
r = gr.enable_realtime_scheduling()
if r == gr.RT_OK:
    realtime = True
else:
    realtime = False
    print "Note: failed to enable realtime scheduling"

for the simplest test case, just connect the sink and source
together and see how that works. No mod or demod, “cat < IF-in >
IF-out”

fg.connect(src, dst)

  1. If I configure my application to receive samples from the usrp at a
    lower rate than I retransmit them (using the rational resampler to
    interpolate) this significantly reduces any under run’s reported. Is this
    the generally used method to get around this particular issue?

No. You want the input and output rates exactly the same.

  1. Is it possible to configure the USRP to directly pass samples from the
    receive to the transmit, bypassing the PC altogether? Could be useful to me
    as a basic RF passband to complex baseband, cutting out PC latencies.

This is possible, but to my knowledge no one has written the verilog
to do it.

Eric

3

Hi,

I wrote a USRP based RF Repeater code
http://www.nabble.com/file/p15199195/repeater.py.tar.gz
repeater.py.tar.gz
before may be 8 months which is connecting source->Destination in IF
level.
Although the input parameters should be entered by hand and not from the
command line, the code was working at that time perfectly on ubuntu 7.04
and
I think it will work on 7.10. It frequency translates any 4MHZ RF
bandwidth
from any frequency to any frequency (tunable by the connected USRP
daughter
baords) using two USRP daughter boards.

Dear Eric , Jonhathan :

Is it possible to add this code to gnuradio-examples ?

Regards,

Firas

–
View this message in context:
http://www.nabble.com/USRP-underruns-when-attempting-simultaneous-receive-and-transmit-tp15195921p15199195.html
Sent from the GnuRadio mailing list archive at Nabble.com.

4

Hi Firas,

thank you for posting the link to your repeater code. I have that
running on my platform now to see if I still have issues with USRP under
runs. I modified it slightly to accomodate the Flex400 board I’m using.
It is working, though not the GUI side of things, a Gtk error is
flagged, “Gtk-CRITICAL **: gtk_window_resize: assertion ‘width > 0’
failed”. Not too important for my application but thought I’d mention
it. Apart from at the very start of the repeater code, so far I do not
appear to be getting USRP under runs. I’m not entirely sure yet as to
the difference between what I’ve been doing and what your code is doing
that might explain the different USRP data transfer behaviour.

Cheers
Richard

=======================================================================
This email, including any attachments, is only for the intended
addressee. It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
altered or corrupted during transmission.

5

OK thanks Eric. I should have mentioned I was using Ubuntu 7.10. My
application was effectively just passing the samples from the USRP Rx to
the USRP Tx via the PC, no actual demod/remod going on.

I’ll try your suggestions regarding fusb buffering parameters and see if
that makes a difference.

Thanks again.

Cheers
Richard

=======================================================================
This email, including any attachments, is only for the intended
addressee. It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
altered or corrupted during transmission.