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

[Alexander Bothe]

Hi Tom,

answers inline, cropped some lines to maintain readability:

On 22/08/14 16:34, Tom Rondeau wrote:
>> On Thu, Aug 21, 2014 at 5:34 PM, Alexander Bothe <address@hidden>
>> wrote:
>> Enabling the scheduler to update the rr with
>>   enable_update_rate(true);
>> fixes the issue of "dropped tags".
> 
> Which is exactly what the enable_update_rate function was designed to do.
> 

Ok, so I'll keep that as a fix.

>> 2) pfb_clock_sync_fff_impl.cc
>> 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.
> 

My mistake, it should have said _new_ inputs to make any sense. I think
it is related to II) & III) so please see below (III).

> 
>> 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.
> 

In the float implementation the equivalent lines are 398-407, but of
course the check is the same. My issue with those two loops is that the
count variable is in-/decremented multiple times. From the file:

// If we've run beyond the last filter, wrap around and go to next sample
while(d_filtnum >= d_nfilters) {
  d_k -= d_nfilters;
  d_filtnum -= d_nfilters;
  count += 1;
}

Depending on the loop, "count" might be incremented multiple times and
does not necessarily point to the next sample. A quick and dirty
proposal would be something along the following lines:

if(d_filtnum >= d_nfilters){
  while(d_filtnum >= d_nfilters) {
    d_k -= d_nfilters;
    d_filtnum -= d_nfilters;
  }
  count += 1;
}

Same goes for the second case, stuffing the previous sample by
decrementing "count".

> 
>> 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.
> 

As the "count" variable is also used for the consume_each() call it
seems that - in combination with multiple decrements in II) - to many
items might be created without consuming anything.

Adding those workarounds seems to improve the non deterministic
behavior, still it does not produce the same results every time.
Comparing the details in the md5 file created by the posted script, it
seems that all "wrong" results have additional samples (bigger file
sizes) compared to the "right" result.

> 
> 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.
>

Of course it is always a possibility that I'm just doing something
wrong. But if not, there might be cases the block produces usable, but
technically speaking incorrect data.

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

I tried my modifications and they fixed the tag propagation issue for
both clock recoveries. They also reduced the non deterministic behavior
of the pfb block. But as it is still not fully deterministic I did not
create a patch to test, yet.

> 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.
> 

Thanks for the hint, I'll definitely check out that example.

> Tom
> 

Regards
 Alexander