On 09/26/2016 05:04 PM, Garver, Paul W wrote: > I'm a bit confused by your calculation. Nyquist for complex data is > equal to the analog bandwidth so you only need a sample rate of 25.6 > MSPS as stated. USB 3.0 will handle this without a problem on the B200. > If you use short (16 bit integers) IQ then you have 4 bytes/complex > sample so ~100MB/sec. > > I think solving your USB 3.0 woes and using GR on a general purpose > processor will save you significant development time over FPGA > implementations.
Amen. Typically, if you're having USB3 problems - assuming the laptop has a USB3 controller - and you're only using 1 USB3 port - it's the cable. > > Paul Garver > > > On Sep 26, 2016, at 7:53 PM, "[email protected] > <mailto:[email protected]>" <[email protected] > <mailto:[email protected]>> wrote: > >> duane> It seems like a perfect fit for a poly phase filter - however >> this is >> duane> something that I believe needs to be done in hardware (128 >> channels * >> duane> 200khz = about 60mhz sample rate this will not go over a USB >> cable, and >> duane> I doubt I can get this bandwidth into a laptop PC. >> >> sylvain> !?!? >> >> sylvain> 128 channels of 200 kHz = 25.6 MHz of bandwidth. You can >> totally get >> sylvain> that to a laptop. >> >> Nyquest requires 2x samples = 51.2mhz sample rate >> Assuming I/Q data 2x bytes = 102.4mbyte/second >> At 8bit bytes = 819.6 mbits per second is the bit rate. >> >> thats about 17% of the bandwidth of USB 3 (5gbit) however that does not >> account for framing overhead, and other related things. >> Figure another 10% loss for signaling over head. >> >> You are correct it is possible >> >> sylvian> B2xx or BladeRF will do that without issues given a >> sufficiently good laptop. >> >> You mean a USB 3 based solution possibly - but I have had very limited >> success with USB 3 - they always seem to fall back to USB 2 speeds, >> and/or - the data rate is not there - perhaps my experience is flawed >> due to cheap data sources {ie: hard drives} >> >> sylvian> If the transmission are "infrequent" you can even use the same >> trick >> sylvian> that researchers used a while back to listen to all of >> bluetooth and >> sylvian> deliberately alias the signal to fold the spectrum over itself. >> >> I understand that, after 'unfolding' I need to get the actual channel >> number. that's not possible if I do what you describe. >> >> duane> Am I going to have to do FPGA work on my own? >> >> sylvian> Very likely. >> >> duane> Or - is there some existing cook book solution with the FPGA >> duane> configuration pre-cooked? >> >> sylvian> Very unlikely to find something "all done". >> sylvian> Especially that if you don't want to ship the samples, a PFB is >> not >> sylvian> all you need. You'd need demod for each channel in the hardware >> as >> sylvian> well. >> >> That is well understood. >> >> duane> What I am looking for is the FPGA channelizer solution... >> hopefully an >> duane> existing one I could start with? >> >> sylvian> There is an embryon of one in the ettus rfnoc repo and AFAIK >> they >> sylvian> might also replace it with another version soon. >> >> sylvian> But it's written for RFNoC and Series-7 Xilinx fpga. It'll need >> quite >> sylvian> some adaptation to run on anything else. >> sylvian> Also, AFAIU, it's incomplete and non-tested currently so ... >> YMMV. >> >> Thanks for the pointer. >> >> -Duane. >> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> [email protected] <mailto:[email protected]> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
