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: Wed, 3 Oct 2018 08:22:47 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

W dniu 17.07.2016 o 13:05, Piotr Krysik pisze:
> W dniu 07.06.2016 o 13:30, Piotr Krysik pisze:
>> W dniu 01.10.2015 o 14:46, Piotr Krysik pisze:
>>> W dniu 25.09.2015 o 23:23, Tom Rondeau pisze:
>>>
>>>
>>>
>>> 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,
>>
>> I'm writing to let everyone know that resampling blocks after changing
>> the resampling rate in the run-time is still eating stream tags. This
>> makes some designs impossible to implement currently.
>>
>> For example - it would be great if it was possible to implement a clock
>> offset frequency correction like I have drawn on the attached image:
>> -there are two blocks that do the correction: resampler and frequency
>> shifting block,
>> -they change their parameters (resamp_rate, frequency_shift) on stream tags,
>> -there is a block that does clock frequency offset measurements that is
>> connected at the end (putting it in different place is not practical in
>> many circumstances),
>> -these measurements are sent to frequency offset control block which
>> turns them into control messages addressed for both resampler and
>> frequency shifter,
>> -msg to tag blocks adds a tag containing a control message to a stream,
>> -the information about changes of settings of the resampler and rotator
>> are interpreted also by the measurement block, that adjusts measurements
>> based on this information.
>>
>> But currently it not possible to do this due to the issue with the
>> resampling blocks.
>>
>> Did you Tom or anyone found the source of the problem?   
>>
>>
> Hi Tom and others,
>
> I implemented fractional resampling block that can have resampling rate
> changed.
>
> When doing this I learned what is the source of the issue #846. The
> mistake is following:
>
> transformation of tag offset by resampling block that changes its
> resample rate is not a linear function, so in this case you can't use
> such simple linear conversion, like it is done in GNU Radio's runtime:
> https://github.com/gnuradio/gnuradio/blob/master/gnuradio-runtime/lib/block_executor.cc#L143
>
> However, transformation is linear from one resample rate change to
> another. So if you know input and output sample number for which
> resample rate was the same as for the moment when a tag came - you can
> use this as reference point to compute the tag's offset at the output of
> the resampling block.
>
>
> My proposed solution: modification of tags offsets processing in
> gnuradio runtime so it includes case when you have resampling blocks
> with dynamically changing resample rate doesn't seem resonable. If would
> complicate things too much because the runtime would have to track
> resample rate changes inside of every block that can do that. Resampling
> blocks that can have resample rate changed dynamically should implement
> tags propagation themselves.
>
> Current fractional resampler block doesn't do that and it is incorrect.
> The input for dynamic resample rate control should be removed as it can
> cause problems to the users OR users should be warned that if they use
> this input they shouldn't expect tags to work correctly.
>
> The block implemented by me is available here:
> https://github.com/ptrkrysik/gr-gsm/blob/master/lib/misc_utils/controlled_fractional_resampler_cc_impl.cc
>
> It uses a pmt pair ("set_resamp_ratio",value) tag to set resample ratio
> precisely at the moment of tag occurrence.
> It wasn't tested in all possible conditions yet, so I'm still a bit
> cautious regarding it. But it presents how such a block can be
> implemented and in tests performed by me it worked (it is also now used
> to correct sample frequency offset in gr-gsm).
>
Hi all,

Little update in this old but still valid thread. I created two issues
regarding it:

1. what is wrong in the runtime in the context changing relative rate
and tag propagation:
https://github.com/gnuradio/gnuradio/issues/2055

2. other things regarding tag propagation that are wrong in
mmse_resampler (new name of fractional_resampler):
https://github.com/gnuradio/gnuradio/issues/2056


Best Regards,
Piotr Krysik




reply via email to

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