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: Sun, 17 Jul 2016 13:05:45 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0

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

Best Regards,
Piotr Krysik



reply via email to

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