Re: [Discuss-gnuradio] "Open-Hardware"

[Marcus D. Leech]

> 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