On Thu, Oct 23, 2008 at 04:56:04PM -0400, Ed Criscuolo wrote: > Eric Blossom wrote: >> >> Ed, >> >> The problem is that you need to know when the output is about to >> underrun, and only then insert flags. >> >> Is there any external reference clock or other way to tell when the >> external stream needs data? In general, GR has no tie to an external >> timebase, except indirectly through sinks or sources that consume data >> at a fixed rate (e.g., USRP, audio card, etc). If there is some way >> to tell when the external world is ready for more data, we can solve >> this problem. > > The data stream needs to be at a fixed rate. I was planning to add > a throttle block to insure this.
You definitely don't want to use a throttle block for this purpose. It's only reason for existence is so that file driven GUI test code doesn't suck down all the CPU available. >> Is the USRP the final sink for the modulated bits? >> > > Yes, after it's upsampled and modulated, the USRP is the final sink. Good. > I realize that this should pace things, but I figured the throttle > block would be a good idea in that it would allow me to test > without a USRP hooked up, just a spectrum display. I strongly suggest not using the throttle block. Definitely don't use it if the USRP is in the graph. There should be only a single clock in the system. > At this point, I think I'll embed all the packet reading AND > hdlc processing into a single source block with no flow > inputs. This way the block can check for packets on the TUN > device, read them, bitstuff and hdlc frame them, and put them > into an internal ring buffer. Then it would return as many bits > as requested, or flags if the ring buffer was empty. OK. The only problem that I can see with this is that the scheduler will run this block whenever there is space available in the downstream buffer. If your data rate is low (100's of b/s) we could be adding a serious amount of latency to the system. If this is a deep space probe, no problem :-) otherwise we may need to cookup some way to limit the amount of buffer used between the blocks. The default is ~32KB. If the data rate is relatively high, the 32KB of buffering may not be an issue. > I'm assuming that the scheduler would keep asking for enough bits > from this source block to keep the flow going at the throttled rate. > (assuming I have enough CPU power to keep up). Yes. > Does this approach sound like it will work? Yes. Let us know how it works out! Eric _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
