On Sat, Sep 4, 2010 at 12:19 AM, Marcus D. Leech <mle...@ripnet.com> wrote: > On 09/03/2010 11:52 PM, Eric Blossom wrote: > Thought about that, as well. So replaced the graphical FFT sink with a > file sink, and set the > "unbuffered" flag. That file fills up in "fits and starts'--that is, > it spends quite a while with > zero bytes in it, then really a lot of bytes, then no more bytes for > quite some time, then > another lump of bytes, etc. I confirmred that the "producer" end of > the FIFO was producing > bytes at the correct rate. > > So when I'm sending "real" data to an actual USRP (f'rexample), the > symbols will get clocked out at the right rate, provided > that I issue those bits in sufficiently large lumps to prevent the > USRP from underrun on transmit. > > But what about situations where you might have a source of bits that's > running in "real time" (like my little test case with the > external FIFO), and you'd like the resulting symbols to be "clocked > out" at something resembling "real time"? My test case > was just a test case, but I can certainly imagine situations where it > actually matters.
Remember that GNU Radio runs stuff through each signal processing block in "chunks." These chunk sizes can be around 100 to 32000 items in size, more when there is time to spare and less when the system is trying to operate quickly. When you're running with a sample rate of 4800, that's going to pass 4800 samples each second. At this rate, the GNU Radio scheduler is likely using very large block sizes (you could print out the value of noutput_items in one of the work functions to see for sure). Let's say that, generally, each block is given an noutput_items=8192. That's almost 2 seconds worth of data. I just created a simple flowgraph in GRC with a noise source, throttle, and scope sink. With varying rates on the throttle, you can get see this happening. With such a simple flowgraph, the noutput_items is always either 4095 or 4096, so it's pretty regular. With a rate of 4800, you get a scope update about every second. I've seen something like what you were observing with more complicated flowgraphs with very small sample rates; when the scheduler doesn't produce the same number of items each time through, it runs in "fits and starts" as you said. Conversely, when running with a source like the USRP, the USRP source is being run at a minimum of 250 ksps, so the flow graph has to work to keep up with that and therefore runs data through the whole graph "faster" but only because the sinks are being updated with new data more quickly. Like Eric said, remove the throttle or at least change the rate and that should clean things up. Tom _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
