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

[Eric Blossom]

On Tue, Oct 21, 2008 at 11:01:51AM -0400, Ed Criscuolo wrote:
> I'm building a set of blocks to implement the HDLC link-layer
> functions for a spacecraft communication system.
> These blocks deal with IP packets from/to the stack on one side,
> and a bitstream to/from the modulator/demodulator on the other side.
>
> The receive block is already done and working. It takes a bitstream
> from the demodulator, finds the frame, un-bitstuffs it, extracts the
> IP packet payload and shoves it into the network stack. But I've run
> into a snag doing the transmit part.
>
> HDLC is a synchronous serial protocol.  It has to keep clocking bits
> out at a fixed rate no matter what.  When there are no packets to
> transmit, it outputs "flag" bytes (0x7E) continuously until there is
> more packet data to transmit.
>
> The problem is that this makes the output independent of the input.
> I'm struggling with how to implement a forecast method to deal
> with this.  The "how-to-write-a-block" tutorial states that complex
> forecast methods are possible, but gives no examples.  I've gone
> through the code of many forecast implementations, but all of them
> seem to be simple decimators (N:1) or interpolators (1:N).
>
> I need something more complicated.  When there is a packet of "N"
> bytes ready on the input, the number of output bits produced will
> be :
>
> ( Bytes x 8 x Bitstuffing_factor ) + header_size + crc_size
>
> but when there's NO packet data ready on the input, the number
> of output bits produced will simply be 8 (one flag byte).
>
> Is this sort of forecast method possible?  Where can I find
> some code examples of complicated forecast functions, or a
> more detailed description of the use of the forecast method?
>
> Or am I overthinking this, and the simple answer is to set
> ninput_items_required to Zero, since I always have something
> to output?

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.  Is the USRP the final sink for the modulated bits?

Eric