discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Fractional resampler eats stream tags on changes


From: Piotr Krysik
Subject: Re: [Discuss-gnuradio] Fractional resampler eats stream tags on changes on the "ratio" input
Date: Thu, 1 Oct 2015 14:46:45 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0

W dniu 25.09.2015 o 23:23, Tom Rondeau pisze:
> On Wed, Sep 23, 2015 at 4:06 PM, Piotr Krysik <address@hidden
> <mailto:address@hidden>> wrote:
>
>     Hi all,
>
>     Fractional resampler has additional "rate" signal input for supplying
>     resampling ratio for each input signal sample.
>     Changes of the signal on the "ratio" input might result in loss of
>     tags
>     that are close in time to these changes.
>
>     I observed the problem when I was implementing frequency offset
>     corrector (attached flowgraph screenshot).
>     Short description what is going on there:
>     -when message comes to ppm_in port of the block "Controlled const
>     source" changes value of constant at the output,
>     -when Controlled rotator observe this change on its input, it emits
>     stream tag,
>     -for changes of about +/-50ppm (and above) on the 'ratio' input of the
>     Fractional Resampler, tags coming from the Controlled rotator are not
>     going through.
>
>     Just by looking at the Fractional Resampler implementation
>     
> (https://github.com/gnuradio/gnuradio/blob/master/gr-filter/lib/fractional_resampler_cc_impl.cc#L104)
>     I'm not able to locate source of the problem.
>
>     I can implement minimal working example if needed.
>
>     Best Regards,
>     Piotr Krysik
>
>
> Piotr,
>
> Looking at the block, I was hoping it was as easy as putting a
> set_relative_rate call in the set_resamp_rate to adjust how the tags
> are being propagated. But it's not that simple. See Issue #846
> (http://gnuradio.org/redmine/issues/846) for details on the problem.
>
> Tom
>  
Hi Tom,

Thank you for the response and time spent on debugging this issue. Now
when I know what is going on I can try to prepare some workaround for my
purposes (i.e. single C++ block for frequency offset correction).

Best Regards,
Piotr



reply via email to

[Prev in Thread] Current Thread [Next in Thread]