[USRP-users] Processing time between successive uhd::rx_streamer::recv

Marcus Müller marcus.mueller at ettus.com
Wed Oct 29 16:15:06 EDT 2014


Hi Nir,

there is no "maximum delay" by nature. recv() returns as soon as the
host received the data by USB, so the frequency you'd effectively see
recv() return is f_sample/l_packet. The packet length is essentially
defined by USB, so on USB3 that iiiis puuh err 8192 - header. To get an
actual number for your system, you can call
uhd::rx_streamer::get_max_num_samps.

Greetings,
Marcus

On 29.10.2014 16:34, Nir Eden via USRP-users wrote:
> I'm using B200.
> uhd::rx_streamer::recv is blocking function. From my observations, its
> return time is depended on the sample rate. Calculating the time needed for
> nsamps_per_buff to be transmitted is good approximation for the blocking
> time. What is the data buffering mechanism (from ADC to &buffs) and what is
> the maximum delay time between two successive calls for
>  uhd::rx_streamer::recv?
>
> Best regards,
>              Nir Eden, 4Z7DEF
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141029/8944ec78/attachment-0002.html>


More information about the USRP-users mailing list