discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] Re: A low-budget SDR - Was: PCIe know-how?


From: Kim Toms
Subject: Re: [Discuss-gnuradio] Re: A low-budget SDR - Was: PCIe know-how?
Date: Mon, 5 Mar 2007 20:37:35 -0500

I for a long time wanted to design a device that was an ethernet jack on one side and an RS-232 DB-25 on the other (long story).  These devices exist, but they are large - I wanted one that I could screw onto the DB-25 avoiding the cost of the cabling.  TI made a small board that included the whole power supply.  A problem was that I needed an isolated supply, which took more stuff.  Since the interface here is an antenna, there is no need for an isolated supply, making the design simpler.  I was also planning on using the Dallas 80C400 8051 like ethernet controller.  See the TI http://focus.ti.com/docs/prod/folders/print/ptqa420050.html, for the isolated example.  Unfortunately, it is $35.

On 3/5/07, Brian Padalino <address@hidden> wrote:
On 3/5/07, address@hidden <address@hidden> wrote:
> (Found the Reply to All button!)
>
> A fellow calling himself Kim posted this link in a comment to the blog:
> http://tinyurl.com/3dhmb6
>
> Seems there's an option for adjustable voltage on some, but I'm not
> sure how useful that is unless we manage getting all components using
> the same voltage. I think it's best to defer judgment on the issue for
> now.

I believe the standard has -48VDC going out which then gets converted
to whatever voltage your regulators create for you.  The TPS23750 is
what I must have been thinking of - fully isolated 3.3v DC coming out
of the other side with auto negotiation of the PoE interface.

Then if you needed 1.8v or 2.5v - it wouldn't be as efficient but
throwing some regulator on there wouldn't be too bad.

> I suspect the best design method would be to look at the most
> expensive issues first, make those cheaper and then design the rest
> around that. The FPGA, ADC and PCB seem to be the most expensive parts
> right now. I can't say anything about the PCB yet, but the
> dimensioning of the ADC and FPGA would be an issue of what we can get
> away with and still have an SDR. The dimensioning of the FPGA depends
> on the ADC, so the ADC should be the first issue to be dealt with.
>
> A high SINAD and SNR value for the ADC seems to be important at any
> rate, regardless of bit-count, but those values still seem to be
> proportional to how many bits of accuracy it has. Low jitter is
> apparently also important. The LTC1742 seems attractive in that regard
> and the price isn't that terrible either, but it's a 14bit device.
> The ADC12C065 and ADC12DS065 are 12 bits, but I don't know National's
> price on those. They seem to support undersampling up to 1GHz. If we
> could use that, we'd have a pretty awesome radio.
> Analog Devices' AD9235 is really cheap and seems to support
> undersampling to 500MHz, which is pretty cool too. More than I need at
> any rate.

That Analog Devices AD9235-65 looks like it's good if you want to
sample at something like the USRP is doing right now - 64MHz.  So what
you'd be looking at is an oscope with a 500MHz bandwidth and a 64MSPS
sampling rate.  You could possibly double that if you did some
cascading of the ADCs and used the opposite edge of the clock to also
clock into a different ADC - giving you (effectively) double the
samples per second.

Which brings me to another important feature which is the clocking.
To get a good representation of your incoming signal, you should have
a pretty good reference clock with a VCXO or VCTCXO - especially if
you want to do that high IF sampling.  Those signals are moving so
quick, you really need a super stable reference to nab them at the
right time, otherwise your aliased image has a bit more noise.

> There are of course other manufacturers to consider, but I feel this
> is a good start at the very least. Gives an idea what we're dealing
> with.
>
>
> I think the step after deciding on the ADC  would be to dimension the
> FPGA by deciding what code it needs to run. It will have to deal with
> a bit of Ethernet, and stuffing all the data from the ADC into the
> frames. Of course that's not all, but right now it seems that will be
> its most taxing task, so it should be spec-ed to be able to deal with
> that. I have no idea what those specs are. Guess I'll have to learn
> Verilog before I can start guesstimating.

If all you want to do is take the ADC data and shove it off to the PC
to process, you need a really small FPGA that has just a few block
rams in it to store for FIFOs.

If you wanted to do more signal processing within the FPGA, you should
look more towards a mid-sized low-end FPGA (Spartan 3E, Cyclone II,
Lattice Semi) with embedded multipliers.  An XC3S500E should run you
around $20 and have a good amount of resources in there to run your
gigE interface state machine and do some filtering - possibly an FFT
or two as well.

Learning Verilog should take a back seat to understanding your receive
chain and how you want to process your incoming signals.  Are you
going to try to really process everything on the host side of things,
or would you like different FPGA loads to be able to reduce down that
massive data exchange and process less on your host?

Parts are available for all different prices - but be sure to solve
your problem and not just put together something that has a kitchen
sink.  You had wanted an oscope / spectrum analyzer / SDR.  Is 500MHz
bandwidth good enough for you?  Do you want more?  Is 64MSPS the
digitizing rate you want to hit?  What range and resolution bandwidths
do you want for your spectrum analyzer?  0-10MHz at 1kHz RBW?

Listing out your requirements / wish list might be a good idea before
just saying you want to build this generic cheap SDR board.

> Better post this in the blog too...
>
> Thanks for reading! =)
>
> --
> Nos

Brian


_______________________________________________
Discuss-gnuradio mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


reply via email to

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