Bandwidth for USRP

Hi everybody,
this is probably a silly question, but there’s one thing i cannot fully
understand.

Considering that the 2 ADCs per channel on the USRP allow complex
samping at 64Msps, and therefore a 64MHz Spectral Bandwidth, and that my
inexpensive PC just needs 45% of CPU calculation power in order to make
an 8MHz wide FFT of the 8 complex Msps allowed (as a maximum) by the USB
2.0 bus,

doesn’t it look like the USB 2.0 is a heavily constraining bottleneck?

And, if I’m not wrong about this, will it be possible in the future to
have a USRP <–> PC interface which doesn’t limit us so much.

thanks
(…and apologies in case this question doesn’t make much sense)

vincenzo pellegrini

doesn’t it look like the USB 2.0 is a heavily constraining bottleneck?

Yes, USB2.0 is the bottleneck.

And, if I’m not wrong about this, will it be possible in the future to
have a USRP <–> PC interface which doesn’t limit us so much.

Other than 802.11, there aren’t many applications that require more than
8 MHz of bandwidth. Radio astronomy is one, but you can use fewer bits
per sample with RA. It is not uncommon to use 1 or 2 bits per sample,
which would allow you to cover 128 and 64 MHz respectively.

There is an 8-bit per sample mode in the USRP which will allow you to
get 16 MHz of BW across the bus.

Matt

doesn’t it look like the USB 2.0 is a heavily constraining bottleneck?
Yes, USB2.0 is the bottleneck.
And, if I’m not wrong about this, will it be possible in the future to
have a USRP <–> PC interface which doesn’t limit us so much.

Would something like a dedicated PCI LVDS card be a viable option? My
exposure to FPGA’s is only with Virtex-2’s but do the Altera ones you
use on the USRP allow easy interfacing to LVDS signalling?

Other than 802.11, there aren’t many applications that require more than
8 MHz of bandwidth.

We’re building cards for channel sounding and other wireless
applications
that typically require sampling of bandwidths greater than 8 MHz. For
this
we’re using a PLX chip – 9054 (32-bit/33 MHz). With this chip we’re
expecting to achieve a throughput of about 90 MByte/second. You can try
the
9056 if this doesn’t meet your bandwidth requirements.

Cheers.
Nikhil

All this RA talk makes me curious about what a typical RA IF setup looks
like.

Do RA samplers usually employ quadrature sampling (I and Q) or do they
sample
a “real” signal at twice the desired bandwidth?
Also, if the big boys use 1GHz sample rates, what do the little boys
use? 10s or 100s of MHz?

If you only have one or two bits of dynamic range there must be a pretty
big AGC in the loop.
-DC

David Carr wrote:

All this RA talk makes me curious about what a typical RA IF setup
looks like.

Do RA samplers usually employ quadrature sampling (I and Q) or do they
sample
a “real” signal at twice the desired bandwidth? Also, if the big boys
use 1GHz sample rates, what do the little boys use? 10s or 100s of MHz?

They typically use quadrature sampling, with dual polarization, giving
you a total of 4 digital channels you need to
deal with.

Amateur RA types have typically, up until now, done sampling after a
hardware square-law detector and
analog integrator. That requires only very-modest sampling
bandwidth. But the pre-detection bandwidth
is usually on the order of a few Mhz, and sometimes only a few dozen
Khz, depending on observing
frequency, local RFI environment, etc.

But that is changing quickly with hardware like the SDR-14, and now the
USRP/Gnu Radio. I’ve been able to
compute continuum and spectral data at 8Msps on a 3.4Ghz
relatively-recent server-class box.

If you only have one or two bits of dynamic range there must be a
pretty big AGC in the loop.
-DC
Gain control is manual. RFI is mitigated, and because of the tremendous
bandwidths in use, you get
to “synthesize” extra bits of dynamic range. In Radio Astronomy,
you’re looking at random noise
buried below the noise floor of your equipment. A few bits is all you
need for this type of thing.
The system noise floor is integrated out, leaving fluctuations arising
from sources coming in and
out of the beam of the antenna. At least, ideally :slight_smile:

On Mon, 2006-06-26 at 17:12 -0700, Matt E. wrote:

8 MHz of bandwidth. Radio astronomy is one, but you can use fewer bits
For what it’s worth, here’s an simple 1st attempt to make a montage
of 8MHz plots to show a wide band (240MHz of Galaxy 10R at 123W,
Ku vertical):

http://webpages.charter.net/cswiger/123w_3.jpg (1MB)

The LNB lo is 10750M, so where it says “968” the actual f is 11718MHz,
etc. Using DBSRX.

–Chuck

Charles S. wrote:

–Chuck

There’s an astronomically-important spectral line at
12.178Ghz–Methanol. Which will come out of your
LNB at 1428Mhz. The M45 region of the sky produces Methanol masering
outbursts on a regular basis.
But you probably have one of those tiny little dishes…

Matt E. wrote:

I tried my radio astronomy application on a 3.4Ghz system from gateway,
and was unable to do more than 8Msps, despite
the fact that the CPU was relatively lightly loaded (30%) at 8Msps.

In radio astronomy, the sensitivity goes up with
SQRT(bandwidth*integration_time). There are practical limits to
the integration time you can use, but bandwidth well beyond 8Mhz is
routinely used for continuum observations.
At the higher radio astronomy frequencies, the “big boys” are now
routinely running their 1 or 2-bit samplers
at 1Gsps (which gives you 1Ghz complex bandwidth)! There are, of
course, practical limits in available bandwidth
at lower frequencies. For example, the area around 21cm only has
27Mhz of dedicated spectrum, but in reality,
that spectrum is being encroached upon both by deliberate
transmissions, and spurious emissions.

That’s why places like the Green Bank radio observatory (was there last
week) are in the middle of
100-mile-wide “radio quiet zones”. No deliberate radio transmissions
allowed, and no microwave
ovens allowed on-site, etc, etc. There’s no cellphone service in that
part of West Virginia for a reason :slight_smile:

On Tue, 2006-06-27 at 11:18 -0400, Marcus L. wrote:

There’s an astronomically-important spectral line at
12.178Ghz–Methanol. Which will come out of your
LNB at 1428Mhz. The M45 region of the sky produces Methanol masering
outbursts on a regular basis.
But you probably have one of those tiny little dishes…

Yes, and barely room for that. There’s still lots of C-band dishes
out there free for the taking, so I’ve heard.

I’ll try for 6MHz wide segments cut from 8MHz plots to smooth out
the curve next time, rain permitting. ImageMagick make automating
the cropping and montage creating from a bunch of xwd dumps possible.

–Chuck

On Tue, Jun 27, 2006 at 10:55:43AM -0400, Chuck Swiger wrote:

Other than 802.11, there aren’t many applications that require more than
etc. Using DBSRX.

–Chuck

Nice. You may want to try using the middle 6 or 7 MHz instead of the
whole 8 when pasting it together.

Eric

Charles S. wrote:

If you use the usrp_ra_receiver.py application that’s in the current
CVS, and use
the “numogate_ridge_observatory” calibration functions, the spectrum
is dumped
to an ASCII file every few seconds. You can make the knitting
together a whole
lot smoother, and do other things to it before producing your plots.

A thought, anyway.

On Tue, Jun 27, 2006 at 01:25:51PM -0400, Chuck Swiger wrote:

On Tue, 2006-06-27 at 11:18 -0400, Marcus L. wrote:

I’ll try for 6MHz wide segments cut from 8MHz plots to smooth out
the curve next time, rain permitting. ImageMagick make automating
the cropping and montage creating from a bunch of xwd dumps possible.

I wondered how you did it. Thanks for saying :wink:

Eric