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 > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
