discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Low-cost hardware options


From: Brian Padalino
Subject: Re: [Discuss-gnuradio] Low-cost hardware options
Date: Sat, 15 Jan 2011 23:02:50 -0500

On Sat, Jan 15, 2011 at 9:56 PM, John Gilmore <address@hidden> wrote:
>> Also upgraded to the next speed-grade of the ADC, to give 40Msps...
>
> You spec'd only a 12-bit ADC.  In my naive view, resolution seems like
> it's more important to SDR than samples per second.  Resolution is how
> you avoid losing weak signals when you are of necessity sampling a
> wide band.  Can we improve on this to get a 14- or 16-bit ADC, perhaps
> with a lower sampling rate, at a reasonable price?

It's all about power, right?  So you may sacrifice sample rate for
accuracy, but you can gain those bits back in the digital domain via
filtering.  Only if you really want to see more than the 72dB of
dynamic range the ADC supplies do you somewhat get screwed, I think.
I've heard of people recovering very narrowband signals with
narrowband blockers where the desired signal is below the dynamic
range at their fastest sample rate, but through digital filtering were
able to bring the signal out of that noise floor.  I haven't done it
myself.

In my opinion, being able to play with emerging wireless standards in
the 1MHz to 20MHz or even 40MHz bandwidth area is more appealing than
being able to pull them from the muck.  I was reading about the WHDI
wireless HD technology and thought it would be very interesting to
read about and sample.  Link here:

    http://www.whdi.org/Technology/

I know plenty of people will disagree with me so it's just an opinion.

> As I recall from early USRP days, clock jitter makes a real mess of
> doing anything important with an SDR.  If you can't trust your clock,
> you don't know when your samples happened, which makes all the
> computation a lot fuzzier.  That's why the USRP didn't synthesize its
> sampling clock -- nobody back then built a synthesized clock that had
> low enough jitter.  Does this ADF4351 qualify?  And what kinds of
> interactions are there between that clock and the clock on the ADC?
> Shouldn't the downsampler and the digitizer both be using the same
> clock, or a clock that's derived from the same clock?

Clock jitter is pretty detrimental with a high IF, but with baseband
sampling, I can't imagine even the clock an FPGA synthesizes to be too
terrible.  You may not be able to do 1024-QAM, but for modest
modulations I am sure it should be fine.  On the other hand, Silicon
Labs seems to make some pretty spectacular clock synthesis chips with
single-digit picosecond RMS or even sub picosecond RMS jitter numbers.

> Is there a way to use i2c programmable width filters instead of the 20
> MHz lowpass filters, to narrow the bandwidth of the signal being
> digitized down to just the range of interest?  This would help
> ameliorate the low-res ADC by filtering out nearby
> loud-yet-uninteresting signals.

By that time, there's a good chance the damage has been done with the
RF mixing.  The real way, on the RX side of things, would be to use
preselector filters so mixing products and other bad things don't get
in the way.  This is especially true for direct conversion receivers
where you have DC, gain and phase imbalances coming into the ADC.
When you have large blockers or jammers, they replicate themselves
through those imbalances and it just becomes a huge mess to try to
deal with.

But, back to your point about I2C programmable width filters, Skyworks
makes some that are SPI.  The SKY73202-364LF is one for direct
conversion receivers or for reconstruction filters for DACs.  Link
here:

    http://www.skyworksinc.com/Product.aspx?ProductID=400

Relatively inexpensive as well.

> Finally, don't assume that a USB3 chip will easily support downgrading
> to a USB2 connection.  It ought to be that way, but might not be.  The
> EZ-FX2 chip does support both USB1 and USB2, but in the last ten
> years, nobody ever got around to programming the USRP firmware to
> actually make it work with USB1.  That became somewhat moot as USB2
> became standard in everything.

Superspeed USB explicitly states that there are two connections - the
superspeed wires and the USB2 wires.  When superspeed is present, both
methods of communication must be supported.  In fact, it even states
that they can be used in tandem.

> Similarly, the GigE interface on the USRP2 has never supported
> downgrading to 100 Mbit Ethernet, even though that's part of the GigE
> spec.  However, now that they've switched to using a UDP-based
> protocol rather than an Ethernet-frame-based protocol (finally -
> hooray!), you can plug the USRP2 into a switch.  Switches all allow
> 10, 100, and 1000 Mbit/sec Ethernet to communicate.  If you're going
> to put 1GE on this device rather than USB2 or USB3, I suggest
> including a switch chip too, so it will transparently talk to any
> speed of Ethernet.  GigE is still too uncommon on laptops these days.
>
>        John

Brian



reply via email to

[Prev in Thread] Current Thread [Next in Thread]