Forum: GNU Radio USRP overruns

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Jonathan G. (Guest)
on 2007-05-25 17:11
(Received via mailing list)
Hi all



We're doing some data collection with the USRP and a basic rx daughter
board
but we're getting those pesky u0 characters appearing.



I know that these are generated in response to buffer overruns on the
FPGA
but we are running at pretty low transfer speeds (around 8 Mbyte/s), are
these same characters used elsewhere in the software to indicate other
problems - it would be a bit of a bind to find out later that we're
looking
in the wrong place for a problem.



We're using a modified version of the usrp_rx_cfile.py script and have
two
inputs to the daughter board going through a single DDC, the problem
arises
on long data collection runs (>10M data points), also were using the
(now
officially deprecated) usrp.source_s



Thanks for your help



Jon Gill
Chris S. (Guest)
on 2007-05-25 22:25
(Received via mailing list)
Jonathan G. wrote:
> FPGA but we are running at pretty low transfer speeds (around 8

I have that problem when recording ~5 seconds or more of 4e6 complex
samples/sec data.  I fixed it by writing to a different hard drive.

Chris
Eric B. (Guest)
on 2007-05-27 01:09
(Received via mailing list)
On Fri, May 25, 2007 at 02:12:26PM +0100, Jonathan G. wrote:
> Hi all
>
>
>
> We're doing some data collection with the USRP and a basic rx daughter board
> but we're getting those pesky u0 characters appearing.

There's only one place they are output.

> I know that these are generated in response to buffer overruns on the FPGA
> but we are running at pretty low transfer speeds (around 8 Mbyte/s), are
> these same characters used elsewhere in the software to indicate other
> problems - it would be a bit of a bind to find out later that we're looking
> in the wrong place for a problem.

You've probably got a disk throughput and/or latency problem.

If you're running Linux and have the target file system mounted as
ext3, try mounting it as ext2 instead.  Things pretty much die when the
ext3 journal is posted.

If you're running on a laptop, your drive performance is most likely
pretty lame.  Try running on something with a modern 7200 RPM drive.

> We're using a modified version of the usrp_rx_cfile.py script and have two
> inputs to the daughter board going through a single DDC, the problem arises
> on long data collection runs (>10M data points), also were using the (now
> officially deprecated) usrp.source_s
>
> Thanks for your help
>
> Jon Gill

Eric
This topic is locked and can not be replied to.