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

Nir Eden nir.eden at gmail.com
Wed Oct 29 17:47:25 EDT 2014


Thank you Marcus,

I'm trying to understand what should be done in order to avoid data loss
and overflow. My receiver code is looking something like this:
while(true) {
     size_t num_rx_samps = rx_stream->recv(&buff.front(), buff.size(), md,
3.0, enable_size_map);
     // Do some number crunching
}

I do understand that the number crunching task can't take too long. So, how
long can it take before data loss? Should I implement double buffer?

On Wed, Oct 29, 2014 at 10:15 PM, Marcus Müller <usrp-users at lists.ettus.com>
wrote:

>  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 listUSRP-users at lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> 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/d5e17c68/attachment-0002.html>


More information about the USRP-users mailing list