[Discuss-gnuradio] Dropped stream tags with mm & pfb clock recovery/sync blocks

[Alexander Bothe]

Hi,

I've got some issues with two of the clock sync/recovery blocks shipped
in the gr-digital package (maint) regarding stream tag propagation/non
deterministic behavior.

I use a file_source block to read previously captured traces and tag
some of the samples before the stream is handled by the clock
recovery/sync block. After the clock block, only a few (the first)
samples remain tagged. I tried to use a throttle block but that did not
fix the issue. As a custom clock recovery block works fine, I tried to
find the cause and potential workarounds.

I share my findings, so that someone with more knowledge of the clock
recovery blocks might find real fixes.

1) clock_recovery_mm_ff_impl
In this block the relative rate (rr) is set by:
  set_relative_rate (1.0 / omega);

Enabling the scheduler to update the rr with
  enable_update_rate(true);

causes it to deviate slightly (4th/5th decimal) from the set rate but
fixes the issue of "dropped tags".


2) pfb_clock_sync_fff_impl.cc
This one proved to be a little tricky. I think there are two issues with
this block:

a) Producing outputs without input
The block produces many, many samples without input. Thus, the scheduler
controlled rr goes through the roof (>70.0) for quite a couple of calls
to the work function. This really messes up the tag propagation.

b) Non deterministic behavior:
Some smaller tests consisting of the following topology:
 same file -> file source -> pfb -> file sink
with multiple iterations result in different outputs, thus the block
itself seems to be non deterministic. A throttle blocks helps most of
the time, but in my opinion should not be needed.

Potential causes and workarounds follow. They fix the tag propagation
issue but do not fully fix the non deterministic behavior:

I) The "in" pointer should be initialized to the first new tag, not the
beginning of the history, as count+d_out_idx might become negative. Thus:
out[i+d_out_idx] = d_filters[d_filtnum]->filter(&in[count+d_out_idx]);
might produce bad results.

II) After skimming through a paper on pfb [1], imho the counter "count"
should only be in-/decremented once per over-/underflow using the 1/N
architecture.

III) Is there really a (maybe indirect) check that there are no samples
produced, if no input is available? Both checks which break the main
loop are against noutput_items?

Regards,
 Alexander

[1] Harris, F.J. and Rice, M., "Multirate digital filters for symbol
timing synchronization in software defined radios", IEEE Journal on
Selected Areas in Communications,  Vol. 19, No. 12, 2001