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 _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
