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 _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
