Re: [Discuss-gnuradio] loopback dropping final bits

[Dan Halperin]

Greg Troxel wrote:
> I wonder if there is data somewhere in the flowgraph that's less than
> the amount needed for the next block to run.   Perhaps there should
> be some sort of drain operation, or query for this (that adds over
> components), so one can find out what's going on.
>   

This appears to be the problem. For this configuration, the
gr_clock_recovery_mm_ff block requires at least 10 inputs - the
instrumented forecast method prints:

16382 inputs required for 8191 outputs
8194 inputs required for 4095 outputs
4100 inputs required for 2047 outputs
2053 inputs required for 1023 outputs
1030 inputs required for 511 outputs
518 inputs required for 255 outputs
262 inputs required for 127 outputs
134 inputs required for 63 outputs
70 inputs required for 31 outputs
38 inputs required for 15 outputs
22 inputs required for 7 outputs
14 inputs required for 3 outputs
10 inputs required for 1 outputs

Since this block initially starts with 0 inputs and is not filled with
other data following the run of the program, the last <10 samples are
left in the flow graph. This could well be the problem with the last
bits of the last packet always being dropped/corrupted, because if you
were using queues and enqueued a message followed by a close_queue
packet, they could well get shipped through the pipeline together.

This is where my expertise runs out; what's the right fix? Is it
block-specific (either pre-pend 0s or detect the end of data and append
0s), or more general?

-Dan