discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] GRC flow graph taking longer than I think it shou


From: Marcus D. Leech
Subject: Re: [Discuss-gnuradio] GRC flow graph taking longer than I think it should
Date: Mon, 06 Mar 2017 10:06:53 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0

On 03/06/2017 08:27 AM, Thomas Wright wrote:
Hi all,

I have a simple flowgraph:

usrp n210 -> low pass filter -> stream to vector decimator -> msg queue sink

with important parameters:
sample rate = .195312 MSps
vector length = 128
decimation rate = 16
msg queue length = 1

and my application is trying to capture samples of a given signal as fast as possible. I'm using a GRC generated python script that I'm editing, and looking at time stamps I'm creating with python's datetime.now(). My general code is:

TIMESTAMP1
flowgraph.usrp.set_center_freq(center freq)
TIMESTAMP2

flowgraph.set_sample_rate(samplerate)  #does usrp, filter, etc.
TIMESTAMP3

flowgraph.start()
TIMESTAMP4

flowgraph.msg_queue.delete_head()  #waits for there to be data in the queue
TIMESTAMP5

flowgraph.stop()

average difference between timestamps:
1 -> 2 = .5ms
2 -> 3 = 1ms
3 -> 4 = 4ms
4 -> 5 = 80ms

My issue is that I think the time between timestamps 4 and 5 should take about 10ms:

128 samp/vector * 16 vector * (1second / 195312 samp) =~ 10ms.

My questions that arise from this:
How much overhead SWIG/python introduce, could that be significantly hampering performance? Would a c++ version perform significantly better?
Would a higher end usrp perform significantly better?
How close I can expect to get to the theoretical minimum?

I appreciate any information anyone could provide. Thanks very much.

-Scott

This has nothing to do with your USRP.  You're likely looking at Gnu Radio's buffering mechanism, which at low sample rates can often
  produce considerable latency.



reply via email to

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