discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] buffer sizes, timing and overflows


From: Johnathan Corgan
Subject: Re: [Discuss-gnuradio] buffer sizes, timing and overflows
Date: Tue, 18 Sep 2007 10:09:09 -0700
User-agent: Thunderbird 1.5.0.13 (X11/20070824)

Juha Vierinen wrote:

> I am writing a simple program that stores USRP sampled data and stores
> it on disk continuously in 1s sized files. I have made a new sink for
> this purpose, which is almost identical to gr_filesink, except that
> mine blocks in work() while the file is closed and a new one is
> created.

Blocking in work() is bad.  The current GNU Radio runtime scheduler is
single threaded, so while your filesystem call is blocking, you're not
reading from the USRP.  Depending on how long you're blocked, this could
result in dropped data.

> 1) I would like to get as accurate timestamp as possible to the
> beginning of the dump to make later analysis easier. What would be the
> best way to estimate the time delay between fg.run() and the moment
> when the first sample comes out of the down converter?

You'll have to find a way to empirically measure it.  Alternatively,
when the "in-band signaling" code is ready, the received data from the
USRP will be timestamped.

> 2) I have managed through trial and error  to get a fairly reliable
> 8MHz sampling system using the following parameters:
> fusb_nblocks=32768,fusb_block_size=1024. Is this a good way to make a
> large buffer or should I use some other gnuradio block to create a
> large buffer in RAM? I am hoping to write the data at 8MHz on a
> networked RAID array and this will cause even larger waiting times for
> my filesink, even though the average bandwidth is large enough.

While this may work, you're addressing a symptom, not the root problem,
which is calling fclose() in work().

Could you stream samples to a single file and cut it up into 1s samples
afterwards?

> 3) Another question: is there any way to query the driver if a buffer
> overflow has occurred and maybe throw an exception? I am going to
> sample continuously for long durations and it would be nice to be able
> to restart sampling automatically if an overflow is detected due to
> some reason.

You can call usrp.source_c.noverruns() to get a count.

> 4) What happens in an overflow situation? Do I still get the correct
> amount of samples, albeit with wrong samples, or are the missing
> samples just tossed away?

They are tossed away.

> Gnuradio and USRP is great! I really prefer your system to labview.

Thanks.

-- 
Johnathan Corgan
Corgan Enterprises LLC
http://corganenterprises.com




reply via email to

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