Re: [Discuss-gnuradio] Poly phase channelizing in Blade Or USRP

[Cinaed Simson]

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, "address@hidden
> <mailto:address@hidden>" <address@hidden
> <mailto:address@hidden>> 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
>> address@hidden <mailto:address@hidden>
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>