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:
- Has anyone else seen anything like this?
- If so, is it related to OSX, GNURadio 3.0.3, or the USRP rev 4?
- Any ideas on how to diagnose or fix it?
@(^.^)@ Ed