I’m trying to re-tune a daughterboard, while acquiring samples, and I
seem to get an overrun every time. (This is in C++.)
Before I start investigating really hackish ways to make this work,
has anyone had any success getting this to work?
I don’t actually care about the data I get while tuning, but I don’t
want to lose track of the exact time, so I’d be happy with a way to
ask the USRP to pause for a specified number of samples, as well, or
even just to know how many samples I lost due to the overrun.
On Fri, May 08, 2009 at 03:43:34PM -0400, Andrew L. wrote:
Hi all-
I’m trying to re-tune a daughterboard, while acquiring samples, and I
seem to get an overrun every time. (This is in C++.)
Before I start investigating really hackish ways to make this work,
has anyone had any success getting this to work?
I’m assuming this is on a USRP2.
Whoops, should’ve mentioned. This is a USRP1.
I don’t actually care about the data I get while tuning, but I don’t
want to lose track of the exact time, so I’d be happy with a way to
ask the USRP to pause for a specified number of samples, as well, or
even just to know how many samples I lost due to the overrun.
My current thought is to add a new FPGA register FR_SKIP_SAMPLES.
Writing a number N to that register would cause the next N samples
that would otherwise be written to USB to be skipped. The sequence
would be:
Write 1000000 to FR_SKIP_SAMPLES. (I suspect that just a few ms
worth of samples would be plenty.)
Tune the USRP.
Hope that tuning finishes before the full batch of samples have been
skipped.
Alternatively, I could try to modify the firmware to do i2c
asynchronously, but that sounds a lot more painful.
On Fri, May 08, 2009 at 03:43:34PM -0400, Andrew L. wrote:
Hi all-
I’m trying to re-tune a daughterboard, while acquiring samples, and I
seem to get an overrun every time. (This is in C++.)
Before I start investigating really hackish ways to make this work,
has anyone had any success getting this to work?
I’m assuming this is on a USRP2.
The current firmware stops the streaming, does the tune, and restarts
streaming. This produces a discontinuity of varying length, but
doesn’t underrun.
I don’t actually care about the data I get while tuning, but I don’t
want to lose track of the exact time, so I’d be happy with a way to
ask the USRP to pause for a specified number of samples, as well, or
even just to know how many samples I lost due to the overrun.
If you’re using the libusrp2 interface, you can check the timestamp in
the metadata passed to your rx_sample_handler.
If you’re using the usrp2_source_* interface there’s currently no way to
know. This will be possible when we implement the “stream annotation”
feature.