USRP data rates

GNU Radio
1

The USRP sales brochure lists as a feature “Capable of processing
signals up
to 16 MHz wide”. I can only figure out how it can process signals up to
8
MHz wide. What am I missing?

Since samples sent across the USB are 16-bit signed integers (16-bit I
and
16-bit Q for complex samples) that makes each complex sample size 4
bytes.
Since the USB max is 32MB/s, we have a limit of 8MS/s which translates
to an
effective bandwidth of 8MHz wide.

I noticed that there is another method besides usrp.source_c() to
retrieve
data from the USRP, it is usrp.source_s(). Is this returning an even
smaller sample that would somehow get us to the 16 MHz wide bandwidth?
What
exactly is this method returning?

Thanks in advance.

2

Lisa-

The USRP sales brochure lists as a feature “Capable of processing signals up to 16
MHz wide”. I can only figure out how it can process signals up to 8 MHz wide. What
am I missing?

Since samples sent across the USB are 16-bit signed integers (16-bit I and 16-bit Q
for complex samples) that makes each complex sample size 4 bytes. Since the USB max
is 32MB/s, we have a limit of 8MS/s which translates to an effective bandwidth of
8MHz wide.

32 Mbyte/sec --> 16 Msample/sec --> 16 MHz bandwidth.

If you want to consider complex sampling, then divide into 8 MHz
positive
frequencies, 8 MHz negative.

-Jeff

3

Actually I believe 16MHz is only achieved by reducing the sample bit
depth from 16 to 8, which I’ve read somewhere can be done.

8 Mega complex samples per second -> 8MHz when the real and imaginary
parts of the complex sample are each 16 bits wide. (=32Mbytes/sec)
16 Mega complex samples per second -> 16MHz when I/Q are reduced to 8
bits each (=32Mbytes/sec)

Somebody correct me if I’m wrong but I’m pretty sure that’s right.

Cheers
Richard

Lisa Creer wrote:

retrieve data from the USRP, it is usrp.source_s(). Is this returning

=======================================================================
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.

4

On 8/9/07, Johnathan C. [email protected] wrote:

It is possible to retain only the upper eight bits of each sample and
pack these into two bytes such that the USB can carry 16 Msps complex;
this gives you more passband bandwidth at the expense of dynamic range.

Now that I know it can be done, how do I retain the upper eight bits of
each
sample?
Is there code already written to do this? I’d like to maximize the
passband
bandwidth.

Advanced applications of the USRP involve re-synthesizing the FPGA

firmware and performing DSP operations directly on the samples coming
from the ADCs before handing off the data to the USB. This
theoretically gives you access to the entire 64 MHz receive bandwidth;
however, there isn’t a great deal of space on the FPGA for custom code,
and the expertise/development time/debugging/pain involved is much
higher than just using GNU Radio on the host.

I’ll spare myself the pain and be content with a 16 MHz passband
bandwidth.

You have been most helpful. Thank you.

5

Hi,

I have an important suggestion:

The USRP ADC resolution is 12 Bits. These 12 Bits are converted to 32
bits
(16 bits I and 16 Bits Q) after being processed by the FPGA DDC.
However, if
we reduced the output bit width of the DDC to 12Bit I and 12 Bit Q (or
simply rotate right the resultant 16 bits I/Q by 4), then we packed and
transfered the resultant 24 bits into a 3 bytes only (instead of 4 in
the
case of 16bit complex), then we can have an instantaneous bandwidth of
10.67MHz (32M/3) with 12 bits I/Q which is in my opinion will be optimum
in
the sense of ADC resolution and the obtained instantenouse bandwidth.

Firas,

Lisa Creer wrote:

sample?

higher than just using GNU Radio on the host.
Discuss-gnuradio Info Page

–
View this message in context:
http://www.nabble.com/USRP-data-rates-tf4240371.html#a12086929
Sent from the GnuRadio mailing list archive at Nabble.com.

6

Lisa Creer wrote:

Now that I know it can be done, how do I retain the upper eight bits
of each sample? Is there code already written to do this? I’d like to
maximize the passband bandwidth.

There is a function call pair (make_format, set_format) which tells the
USRP to use 8-bit samples. You can see it’s use in some of the example
programs.

–
Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com

7

Lisa Creer wrote:

The USRP sales brochure lists as a feature “Capable of processing
signals up to 16 MHz wide”. I can only figure out how it can process
signals up to 8 MHz wide. What am I missing?

Since samples sent across the USB are 16-bit signed integers (16-bit I
and 16-bit Q for complex samples) that makes each complex sample size 4
bytes. Since the USB max is 32MB/s, we have a limit of 8MS/s which
translates to an effective bandwidth of 8MHz wide.

Your analysis is correct, for the default operation of the USRP. The
ADCs create 12-bit samples @ 64 Msps, and are represented as 16-bit
samples with the upper four bits zeroed. Two independent ADCs
coherently sample the down-converted I and Q signals from the
daughterboard at this rate and resolution.

The FPGA decimates and low pass filters these I and Q streams by a
minimum factor of 8, resulting in a maximum of 8 Msps on each
(alternatively described as 8 Msps complex). This represents at most 8
MHz of passband (the Nyquist rate for complex sampling = complex sample
rate.)

It is possible to retain only the upper eight bits of each sample and
pack these into two bytes such that the USB can carry 16 Msps complex;
this gives you more passband bandwidth at the expense of dynamic range.

In practice, the FPGA filter roll-off (it’s a CIC decimator) is
significant in the outer 25% or so of the passband, so depending on how
much attenuation your application can withstand, you might only get 6
MHz or so of usable bandwidth out of it (or 12 MHz using 8-bit samples.)

I noticed that there is another method besides usrp.source_c() to
retrieve data from the USRP, it is usrp.source_s(). Is this returning
an even smaller sample that would somehow get us to the 16 MHz wide
bandwidth? What exactly is this method returning?

The data over the USB is always in integer format, normally signed
16-bits each for I and Q. The usrp.source_c() source block converts
this to a stream of single precision complex floating point samples.
Most of GNU Radio signal processing blocks are designed to work with
floating point and many use highly optimized inner loops that take
advantage of SSE or 3DNow floating point hardware on Intel or AMD
processors. So this is the natural domain of DSP processing with GNU
Radio.

The usrp.source_s() data source provides access to the raw data stream
from the USRP (interleaved I and Q), but there aren’t many interesting
DSP blocks in GNU Radio that can work with this format. You may, of
course, write your own.

Advanced applications of the USRP involve re-synthesizing the FPGA
firmware and performing DSP operations directly on the samples coming
from the ADCs before handing off the data to the USB. This
theoretically gives you access to the entire 64 MHz receive bandwidth;
however, there isn’t a great deal of space on the FPGA for custom code,
and the expertise/development time/debugging/pain involved is much
higher than just using GNU Radio on the host.

–
Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com