[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] The ultimate SDR
From: |
Eric Blossom |
Subject: |
Re: [Discuss-gnuradio] The ultimate SDR |
Date: |
Mon, 22 Oct 2001 12:40:58 -0700 |
User-agent: |
Mutt/1.2.5i |
Hi Matt,
Welcome to the discussion!
On Fri, Oct 19, 2001 at 04:24:30PM -0700, Ettus, Matt wrote:
> I've been thinking about SDR for a while now, both as a HAM, and an EE in
> the communications profession. What I would like to build is the hardware
> for a generic SDR:
>
> at least 1 (up to 20) Msamples/sec, 4 to 16 bits per sample (obviously fewer
> bits per with higher rates)
> Tuning in 2 ranges, either from 0 to 1 GHz, or 800 to 2500 MHz
> Transmit and Receive full duplex, on different frequencies
> Connected to PC by a dedicated 100Mbit ethernet line, with raw Ethernet
> packets (i.e. no TCP, UDP, IP, etc.)
>
> I have a basic design for the RF, analog, and DSP downconversion. Its not
> that hard with Analog Devices products...
Great! We need more folks with a hardware bent looking at these
problems.
Philosophically, are you thinking about a single channel or
multichannel application? The multichannel stuff looks like the most
exciting area to me, but of course requires higher bandwidth and
dynamic range throughout most of the signal chain.
Are you planning on integrating a digital down converter and/or upconverter
(Analog Devices speak: RSP / TSP)? In my vision of the ultimate SDR,
they look like key items to have, since even using 100 Mbit ethernet,
you're pretty much i/o bound. Using quad parts, you should be able to
knock the data rate down to something doable and get up to four
separate channels across the bus.
Leading edge A/D (14-bit, but assume it's 16 bits wide for interface)
16 bit/sample * 65M sample/sec = 10^9 bit/sec
Ooops, doesn't even come close to fitting.
Taking a typical narrow band digital interface, IS-136, you've got a
30 kHz channel with a symbol rate of ~24k symbols/sec. Assume you
want 4 complex samples / symbol, this works out to:
24k symbols/sec * 16 bits/sample * 2 (I&Q) * 4 samples/symbol = 3M bit/sec
GSM: about 200k symbols/sec * 16 * 2 * 4 = 25M bit/sec
IS-95 CDMA: 1.2288M chip/sec * 2 samples/chip * 16 bit/chip = 40M bit/sec
Assume we can utilize 50Mbit/sec of 100Mbit/sec ethernet (Is this a
valid assuption? What kind of throughput can actually be sustained?),
then we could transfer:
50M / 3M = 16 channels of the narrow bandwidth signals
50M / 25M = 2 channels of the medium bandwidth signals
50M / 40M = 1 channel of the high bandwidth signal
Hence, my interest in integrating the digital down/up converter (I'm
probably preaching to the choir).
> The hard part is the Ethernet interface. Does anyone have suggestions for
> the ethernet interface? I haven't worked with any Ethernet MACs, nor have I
> embedded one on an FPGA. I'd rather avoid having an OS on the device, but a
> [fast] microcontroller might do the job.
Me neither, but I'll do some checking around. The usual suspects include
intel, SMCC. The trick is to find one that *doesn't* have a PCI
interface.
> The other option is Firewire, but support under linux seems sketchy, and I
> have no experience with it.
I've also considered Firewire, but I too know nothing about it, other
than that it's supposed to do 400Mb/sec and that none of my existing
machines have it ;-)
We can of course fix the "sketchy support" problem. Have you located
any interesting Firewire MACs (or whatever they call them)?
> Any ideas? Anyone interested in helping out?
Sure.
> Matt
> N2MJI
Eric