Re: [Discuss-gnuradio] USRP data rates

[Johnathan Corgan]

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 Corgan
Corgan Enterprises LLC
http://corganenterprises.com