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

[Martin Braun]

Alexander,

once every year or so a message pops up with someone describing
non-deterministic behaviour using file sources, but it never gets
followed up because it's so hard to reproduce.

Any chance you could provide the actual source files and flow graphs, so
other people can try this and see for themselves?

M

On 08/21/2014 11:34 PM, Alexander Bothe wrote:
> 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
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>