[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] UHD USRP Source for B2x0 overflows File Sink

From: Murphy, John
Subject: Re: [Discuss-gnuradio] UHD USRP Source for B2x0 overflows File Sink
Date: Thu, 7 May 2015 14:01:31 -0400

On Thu, May 7, 2015 at 1:01 PM,  <address@hidden> wrote:

> If you want high file-write performance, leave it in buffered mode.

> Also, a 175-tap filter, running at 16Msps is going to chew up a lot of CPU.
> How about a simple low-pass filter, decim=2?  Make the transition bandwidth
> fairly sloppy.

> Or alternatively, just run the USRP at your desired sample-rate into the
> file-sink.

I presume you mean buffered mode on the File Sink? With the wording of
the param, I can not understand wether buffered mode is "Unbuffered =
off" or "Unbuffered = on". Do you know which it is? Also the doc page
indicates this param is not passed to the make function, so I am not
even sure it is really used.

Transition bandwidth is sloppy, double the (sample rate minus
two-sided passband width), or in this case something on the order of
1/4 the input sample rate.
CPU usage is 7% (total for all processes on the machine) with this
whole flowgraph running. It is a polyphase filter which is more
efficient, although with decim only 2 my guess is there are only two
polyphase arms so the FIR decim only used a CPU of about 9% for the
same set of taps. And same buffer overrun problem with the FIR decim
as the PFB. But still.

I and my co-wrokers have all these same issues every time we try this
for the past year with flowgraphs with just the two blocks... USRP
Source and File Sink. So I am not sure the filter or the CPU usage is
an issue at all here.
To find out, I just now tried it again, disabled everything but the
USRP Source and the File Sink, changing the USRP output format to
complex int16, and within 90 seconds I got an overrun. The CPU usage
in this mode is about 3% or 4% total.

Also note I am talking about the flowgraph running fine for a minute
or so then getting a handful (1, maybe 3 or 4) 'O's. Then another
minute or so with another burst of O's. Etc. It is not a huge thing
but when you are doing stuff like testing synchronizers or signal
recovery it is enough to be a problem. On something like GPS playback
for a test bench the hiccups make it completely unworkable.

- John

> How would I best set up a UHD Source block for USRP B2x0 devices to
> output to a flowgraph that uses a File Sink block to write to disk
> without overflows (and how would I best set up the File Sink block)?
> This is the attached system hardware, dedicated to GR...
> Gigabyte GB-BXi7-4770R Brix Pro PC
> Crucial Ballistix Sport 2x8=16GB RAM DDR3L-1600 (PC3L-12800) CL9 Timing
> 9-9-9-24
> Samsung 840 EVO 250GB SATA-III internal 2.5" SSD
> ...so a lot of overkill on hardware resources, but no knowledge on how
> to set up the UHD Source block or File Sink block to take advantage of
> this.
> I am attempting to record data at 16Ms/s on the USRP and 8Ms/s to the
> disk but I would like to take this even higher (perhaps as high as 28
> Ms/s on the USRP or as fast as I can get it) if possible with a fast
> enough system.
> Fedora 20 with LXDE (uname -r is 3.18.9-100.fc20.x86_64)
> UHD is 3.8.1
> GR is
> My flowgraph has:
> a. UHD USRP Source with master clock 32M, sample rate 16M, wire format
> auto, output type complex float32, and a device argument of
> num_recv_frames=512.
> b. Polyphase Decimator with decim 2, 175 taps from
> firdes.low_pass_2(), FFT rotator and filters.
> c. Constant multiply by 32768 with type complex.
> d. Complex to IShort with vector output yes.
> e. File Sink with input type short, vector length of 2, unbuffered on
> (there's a confusing parameter name, which I am not sure actually does
> anything), and append file overwrite.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]