Dan Halperin wrote:
> This is the final state of the flow graph:
>
> <gr_block clock_recovery_mm_ff (5)> regular 2:1
> max_items_avail = 9
> noutput_items = 8191
> BLKD_IN
> were_done
I realized that the other two flow graph elements with max_items_avail >
0 have the same max_items_avail at initialization; this makes sense
since e.g. the filters may have more taps than data. However, the
clock_recovery_mm_ff block had max_items_avail=0 at program start. Also,
there was one step where it violated the correct 2:1 in/out by doing
31:15 instead; these two combine to 10 missing inputs on a 2:1 block, or
5 missing outputs. Aha!
[*** 48 items in, 15 out -> 18 left ***]
<gr_block clock_recovery_mm_ff (5)> regular 2:1
max_items_avail = 48
noutput_items = 8191
general_work: noutput_items = 15 result = 15
...
[*** 30 items in, 18 already -> 48 left ***]
<gr_block quadrature_demod_cf (4)> regular 1:1
max_items_avail = 31
noutput_items = 8174
general_work: noutput_items = 30 result = 30
[*** Only 47 available??? ***]
<gr_block clock_recovery_mm_ff (5)> regular 2:1
max_items_avail = 47
noutput_items = 8191
general_work: noutput_items = 15 result = 15
Does this analysis make sense? Delving deeper into clock recovery now..
-Dan
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
