discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] Understanding tags_demo.cc example in gr-uhd


From: Martin Braun
Subject: Re: [Discuss-gnuradio] Understanding tags_demo.cc example in gr-uhd
Date: Fri, 22 Jul 2016 09:38:54 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0

A basic principle of GNU Radio flow graphs is the concept of
backpressure. Let's ignore the bursts for a second, and assume you set
your USRP to consume at a rate of 200 ksps (so, a very low value). At
its input, you have a signal source, and no other throttling mechanism
(which is the right thing to do).

Can you computer generate signal source samples at more than 200 ksps?
Well yes, easily and happily! So how doesn't it overwhelm the USRP? The
reason is, you can't actually send() data to the USRP if its input
buffer is already full. UHD simply won't let you do that.

When that happens, GNU Radio will eventually call the UHD sink's work()
function, and the work() function will return 0, saying "I can't handle
this data right now". GNU Radio knows now that it can't call work() on
the signal source, either, because if it would, that would generate data
with no buffer to put it. No samples are lost.
Maybe next time we call work() on the USRP sink again, the USRP has
created some space, and work() can consume. And so the flow continues.

Now, let's add the timed bursts again. In principle, nothing changes
w.r.t. the unbursty case. The only difference is when the USRP will
empty its own input buffer. If you transmit a signal that is tagged 10
seconds into the future, GNU Radio might try and call work() for 10
seconds without anything budging, but that's fine.

Hope this was clear!

Cheers,
M

On 07/21/2016 05:04 PM, Lakshay Narula wrote:
> Hello all,
> 
> I have been trying to understand the mechanics of stream tags and USRP.
> To this end, I am reading through the tags_demo.cc example found in
> gr-uhd/examples/c++.
> 
> The example provides two options for burst control: using SOB/EOB tags,
> and using tagged stream blocks. For clarity, let us assume that we
> choose to use SOB/EOB tags, that is, we pass an empty tsb_tag_name. This
> choice does not affect my question that follows later.
> 
> From the code it looks like the flowgraph does not stay idle at any
> point. It takes a bunch of samples, and stamps the SOB tag along with a
> time tag on the first sample. The flowgraph keeps running till the burst
> is on. Once the number of samples in a burst are exhausted, it stamps an
> EOB tag. At this point, it immediately starts a new burst with an SOB
> tag, but with a delayed time tag to accommodate for the idle period. In
> contrast, the USRP transmission must stay off during the idle period.
> 
> In this flowgraph the sample rate is clearly controlled by the USRP sink
> hardware. If the flowgraph produces samples at this rate and does not
> stay idle, then will it not eventually overwhelm the USRP sink? Assuming
> default values of sample rate (1e6) and burst and idle time (0.1 and
> 0.05, respectively), the flowgraph would produce 50,000 samples in each
> idle period. These samples will keep on accumulating endlessly.
> 
> I believe I am missing something here, because this example has been
> clearly reported to work just fine. Any comments?
> 
> Thanks,
> Lakshay.
> 
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 




reply via email to

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