Eric Blossom wrote:
> On Thu, Mar 29, 2007 at 05:16:45PM -0700, Dan Halperin wrote:
>
>> 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
>>
>
> Try applying this patch. It has the effect of preloading ntaps()-1
> zero's into the block's input stream.
>
> Eric
>
>
> --- gr_clock_recovery_mm_ff.cc 2006-12-20 10:40:57.000000000 -0800
> +++ /tmp/gr_clock_recovery_mm_ff.cc 2007-03-29 17:59:42.000000000 -0700
> @@ -61,6 +61,8 @@
> set_omega(omega); // also sets min and max omega
> set_relative_rate (1.0 / omega);
>
> + set_history(d_interp->ntaps());
> +
> if (DEBUG_CR_MM_FF)
> d_logfile = fopen("cr_mm_ff.dat", "wb");
> }
>
No; this appears to at least shift and likely corrupt the bits [I got
abba cdbc efde 01f0 2312 4534 6756 8878 instead of bbaa ddcc ffee 1100
3322 5544 7766 9988]. If I add an extra 0 byte at the end, these bits
come through, but then the last 5 of that next byte do not. Maybe the
flow graph needs to do something like:
At a disruption of continuity of the input (EOF, USRP goes into TX
mode, etc),
append enough 0 samples to clear the pipeline, reinitialize all (or
selected...) flow graph blocks
to their virgin state, and then continue.
The counter-argument is that when receiving symbols from a stream (like
off the USRP), this won't be a problem since the source is continuous -
even if it flips into TX mode, if all samples of the data are there, the
symbols will be recovered when the pipeline restarts. Maybe that means
file sources violate some GNU Radio invariant...
-Dan
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
