3.0.3 libusrp bug with usrp_basic_rx::start/stop

The last thread I posted had indicated problems related to overruns.

The problem turns out that start/stop weren’t consistent in how they
started and stopped things in gnuradio-3.0.3. It worked out that
roughly every 800000 samples in my test, we got an overrun (except if
the total was before the first stop()).

The problem lies in the start order:
d_ephandle->start() followed by set_rx_enable(true)

and the stop order of:
d_ephandle->stop() followed by set_rx_enable(false).

To fix the problem, the calls in stop() had to be flipped.

Here’s the patch:
*** usrp_basic.cc.orig 2007-05-30 10:30:10.000000000 +0000
— usrp_basic.cc 2007-05-30 10:23:11.000000000 +0000


*** 541,556 ****
— 541,565 ----
{
bool ok = usrp_basic::stop();

  • #if 1

  • if (!set_rx_enable(false)){

  • fprintf (stderr, "usrp_basic_rx: set_rx_enable(false) failed\n");
    
  • usb_strerror ();
    
  • ok = false;
    
  • }

  • #endif
    if (!d_ephandle->stop()){
    fprintf (stderr, “usrp_basic_rx: failed to stop end point
    streaming”);
    usb_strerror ();
    ok = false;
    }

  • #if 0
    if (!set_rx_enable(false)){
    fprintf (stderr, “usrp_basic_rx: set_rx_enable(false) failed\n”);
    usb_strerror ();
    ok = false;
    }

  • #endif
    return false;
    }

    Dave

On Wed, May 30, 2007 at 11:29:42AM -0700, Dave Gotwisner wrote:

and the stop order of:
{
fprintf (stderr, “usrp_basic_rx: failed to stop end point streaming”);
return false;
}

Dave

Hi Dave,

Thanks for your efforts on this. I’ll apply the patch to the trunk.

Glad to hear it’s working for you.

Eric

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs