Re: [Discuss-gnuradio] forecast method for HDLC transmit block

[Eric Blossom]

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