Data Capture Problems

I’m trying to capture some data into a file and I’m having a problem.
My setup is very simple:

usrp_source–±->complex_to_ishort—>file_sink
|
–>fft_sink

My usrp_source has it’s decimation set to 200, so I should be getting
320000 samples/sec. With two 16-bit values per sample, this works out
to 1.2 MByte/sec.

The flow graph runs fine for about 10 seconds, then data just stops
flowing. No activity on the fft display, and the file stops growing.
The controls on the fft spectrum display remain active, and the app
still responds to a ‘kill’ command, just no data flow. I get about
12 to 15 MBytes captured in the file. There are no “overrun” messages,
or any kind of error reported at all. The captured data (an AM broadcast
station) is valid and plays back fine (what little there is!).

I then repeated the experiment without the fft_sink and got the same
results.

I then modified the experiment to record complex values instead:

usrp_source–±->file_sink
|
–>fft_sink

This also ran for about 10 seconds, then data flow stopped. But in this
case the captured file size was around 36 MBytes. Since the floats in
a complex stream are bigger than the short ints, this makes sense. But
it also seems to indicate that the filesystem is not the bottleneck, as
it was able to record three times the amount of data in about the same
time.

Next, I disconnected the file_sink and just ran the usrp_source into
the fft spectrum display. This ran forever, as it should.

Lastly, I benchmarked my USB connection, and it was able to keep up
with the full 32 MBytes/sec rate.

My setup is:
Mac OSX 10.4.10
Intel MacBook Pro - dual cpu, 2.33 GHz, 2GB mem
USRP rev 4
GNU Radio 3.0.3 (from tarball)
GNU Radio Companion 0.65 (from tarball)

So, my questions are:

  1. Has anyone else seen anything like this?
  2. If so, is it related to OSX, GNURadio 3.0.3, or the USRP rev 4?
  3. Any ideas on how to diagnose or fix it?

@(^.^)@ Ed

Ed Criscuolo wrote:

  1. Any ideas on how to diagnose or fix it?

If this were happening to me, I’d be curious about how many samples got
written to disk. Was it an whole number of samples? Was it an “even”
number like 10^6 or 2^10.

Chris

  1. If so, is it related to OSX, GNURadio 3.0.3, or the USRP rev 4?
  2. Any ideas on how to diagnose or fix it?

Ed - Please try the latest SVN trunk or both GNU Radio and GRC, then
report back to the list. This might be due to some bugs I fixes in
the some GNU Radio OSX code recently. Or it might not … but trying
the latest SVN trunk is always wise with an issue like this. - MLD

Chris S. wrote:

If this were happening to me, I’d be curious about how many samples got
written to disk. Was it an whole number of samples? Was it an “even”
number like 10^6 or 2^10.

I ran it a bunch of times. Numbers all over the place. Never any
even powers of anything. The only constant is that the file sizes
are always multiples of 4 bytes (one sample of interleaved shorts).

@(^.^)@ Ed

Michael D. wrote:

Ed - Please try the latest SVN trunk or both GNU Radio and GRC, then
report back to the list. This might be due to some bugs I fixes in the
some GNU Radio OSX code recently. Or it might not … but trying the
latest SVN trunk is always wise with an issue like this. - MLD

Mike,

I tried. After the svn checkout, ./bootstrap produced the following
errors but completed:

configure.ac:77: error: possibly undefined macro: AC_LIBTOOL_WIN32_DLL
If this token and others are legitimate, please use
m4_pattern_allow.
See the Autoconf documentation.
configure.ac:79: error: possibly undefined macro: AC_ENABLE_SHARED
configure.ac:80: error: possibly undefined macro: AC_DISABLE_STATIC
configure.ac:81: error: possibly undefined macro: AC_PROG_LIBTOOL
configure:12027: error: possibly undefined macro: AC_PROG_LD

There were also a lot of later warnings about LIBTOOL being undefined

I then ran

./configure --with-boost-include-dir=/opt/local/include/boost-1_33_1

which halted with the following error:

config.status: error: cannot find input file: omnithread/Makefile.in

@(^.^)@ Ed

Ed - I believe from your reply that your computer doesn’t have the
required libraries, includes, and applications already installed, or
they are not being accessed correctly.

Please check out my install script and guide for GR on OSX at <
http://www.nd.edu/~mdickens/GNURadio/ >. Since you’re using an Intel-
Mac and a USRP, you’ll also want the SDCC from that location; this
issue is “known” and described on the GR Wiki < http://gnuradio.org/
trac/wiki/MacInstall >. There are a lot of issues to cover, so I
won’t go into them here. Please let me know how it goes (off list).

  • MLD

Michael D. wrote:

Ed - Please try the latest SVN trunk or both GNU Radio and GRC, then
report back to the list. This might be due to some bugs I fixes in the
some GNU Radio OSX code recently. Or it might not … but trying the
latest SVN trunk is always wise with an issue like this. - MLD

With a lot of patience and help from Mike I was able to straighten out
my OSX build environment so the latest SVN trunk would build.

For some strange reason, even though I had GNU libtool 1.5 installed
and named glibtool (and glibtoolize) the ./bootstrap script wasn’t
happy until I used MacPorts to install it. Then the ./bootstrap
and the rest of the build worked.

And the best news is that it fixed the data capture problem. I
made several runs at 320 ksamples/sec for 12 min (a 1GB file!) without
a problem.

@(^.^)@ Ed

Hi,

Are you using gr.head block in your code ?

Firas

Ed Criscuolo wrote:

even powers of anything. The only constant is that the file sizes


View this message in context:
http://www.nabble.com/Data-Capture-Problems-tf4426114.html#a12629428
Sent from the GnuRadio mailing list archive at Nabble.com.

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