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

[Tom Rondeau]

On Thu, Aug 21, 2014 at 5:34 PM, Alexander Bothe <address@hidden> 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".

Which is exactly what the enable_update_rate function was designed to do.

 

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.

What? I don't think that I understand what you're saying. That block should not be producing anything if there are no inputs.

 

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.

It is. What line(s) are you referring to? Lines 435 - 444 of that file take care of this case.

 

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?

The forecast function provides a relationship between the number of input items and number of output items. I'm at a loss for why you are seeing this.

 

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

A number of us have successfully used this block to capture real, live, over-the-air data. Some of what you're suggesting here means that we wouldn't be able to get correct data with it in bursty transmissions, if I understand correctly.

Much like what Martin said about providing an example, have you tried your modifications? If yes, do you have a patch we could test?

Also, you are using a loop bandwidth value of 0.3, which is about an order of magnitude higher than it should be. Check out share/gnuradio/examples/digital/example_timing.py.

Tom