discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GRC max sample rate


From: Koyel Das (Vehere)
Subject: Re: GRC max sample rate
Date: Sat, 25 Jul 2020 08:22:34 +0000

Hi Paul,

Thanks for your help. Can you please give an example? Like if usrp source outputs 16 bit complex as I Q I Q I Q I Q for 4 IQ samples where I and Q are 16 bit complex then what will be the change in the format after vector to stream conversion? I understood that usrp source block already gives binary file where I and Q are written alternately as above or interleaved. So I am unable to understand when you say vector to stream will interleave I and Q samples. 

Regards,
Koyel 


From: Discuss-gnuradio <discuss-gnuradio-bounces+koyel.das=vehere.com@gnu.org> on behalf of Paul Boven <p.boven@xs4all.nl>
Sent: Saturday, July 25, 2020 1:31:20 PM
To: discuss-gnuradio@gnu.org <discuss-gnuradio@gnu.org>
Subject: Re: GRC max sample rate
 
Hi Koyel,

On 7/25/20 9:19 AM, Koyel Das (Vehere) wrote:
> Will there be packet drops if USRP source is set at 32 bit complex float
> in grc when receiving at 100 MSPS each from two channels? That makes
> 2*100e6*64 (32 bit I and 32 bit Q) = 12800e6 or 12.8 gbps. I am unable
> to set usrp source block to 16 bit complex as then the usrp source block
> is not compatible with file sink which doesn’t have option for 16 bit
> complex.

The USRP block is (as far as I could find) the only block in all of GNU
Radio that uses the 'Complex Int16' type. Which is a bit confusing, but
it is just a vector with a length of 2, alternating the I and Q channels
as 16 bit shorts.

You can simply convert it to interleaved int16 by using a 'Vector to
Stream' block, with these settings:

io_type: short
num_items: 2
vec_length: 1

These 16 bit integers can then be written to disk (if it can keep up),
memory, transferred over the network, or turned into floats for further
processing.

We use this to efficiently stream raw samples over the internet using a
ZMQ Pub Sink.

Regards, Paul Boven.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]