First, let's change the topic. This is overdue.
Agreed
You need the decimation on the device side of the USB connection to
reduce the amount of data sent over it. The absolute limit isbetween 32
an about 40MiByte/sec. Divided by 16bit=2byte per sample is 16-20MSPS
real-valued or 8-10MSPS complex-valued. Either you reduce the sampling
rate or you decimate. That rate should be more than sufficient for all
but the most demanding experiments. The only common interesting signals
that need more bandwidth are TV (6-8MHz), GPS (2-20MHz?), WLAN (20MHz),
All of them in higher bands, where mixing the signal down into the ADC
frequency range would be needed.
For certain classes of high-bandwidth applications, you're willing to
sacrifice
number of bits for bandwidth.
My application (radio astronomy, in particular in-the-noise-floor
radiometry) can easily get away
with 4 bits I and 4 bits Q. Which means that you might be able to
squeeze 40MHz of bandwidth
out of a USB interface using reduced sample sizes. I think it's
worth doing right from the outset,
rather than hacked-in later on. Bit reduction doesn't need to be
fancy, just grab the high order N
bits of the samples and pack them into a byte stream, and chuck that
bytestream out the interface
packaged appropriately. User gets to say what N is, with N perhaps
being chosen from {2,4,8,16},
in order to make the byte-packing easier/cheaper.
the FX2 has an external FIFO interface, intended to handle storage
devices, but interfacing to a high-speed
dual-channel-simultaneously-sampled ADC shouldn't be that hard--might
require an uber-cheap CPLD to
handle some of the handshaking.
An other way would be to change the interface, which would very likely
be Gigabit-Ethernet.
I haven't found a "cheap" way of doing GiGe. Not nearly as cheap as
USB-2.0 chips capable of
doing storage-class transfer rates (like the FX2 used on the USRP1).
Most of the GigE controller
chips are designed for PCI, very few are designed for embedded, which
is why most embedded
applications use a GiGE MAC "hard macro" (or soft) in an FPGA
implementation, with an external
PHY. One project I worked on had 4 instances of the Xilinx TEMAC in
our Virtex 5 FPGA, and a
hideously-complex Broadcom 4-port PHY. Shudder. I need a drink :-) :-)
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
