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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
