[USRP-users] Processing time between successive uhd::rx_streamer::recv
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:
size_t num_rx_samps = rx_stream->recv(&buff.front(), buff.size(), md,
// 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>
> 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.
> 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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the USRP-users