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

Nir Eden nir.eden at gmail.com
Thu Oct 30 15:44:32 EDT 2014


Indeed your examples are self-explanatory and very informative.

Thanks,
Nir

On Thu, Oct 30, 2014 at 12:16 PM, Martin Braun via USRP-users <
usrp-users at lists.ettus.com> wrote:

> On 10/29/2014 10:47 PM, Nir Eden via USRP-users wrote:
> > 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
> > }
>
> It looks like you're copying the code from our examples, so you're
> probably fine, but make sure that buff.size() does not exceed
> get_max_num_samps().
>
> > 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?
>
> ...what Marcus said. Ideally, one thread to pull the data and another to
> process it. Of course, you can still run into overruns this way.
>
> Cheers,
> M
>
> >
> > On Wed, Oct 29, 2014 at 10:15 PM, Marcus Müller
> > <usrp-users at lists.ettus.com <mailto: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 list
> >>     USRP-users at lists.ettus.com <mailto:USRP-users at lists.ettus.com>
> >>     http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
> >
> >     _______________________________________________
> >     USRP-users mailing list
> >     USRP-users at lists.ettus.com <mailto:USRP-users at lists.ettus.com>
> >     http://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
> >
>
>
> _______________________________________________
> 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/20141030/544791b2/attachment-0002.html>


More information about the USRP-users mailing list