Hi Eugene:
On Wed, 2017-12-27 at 16:18 -0500, Andy Walls wrote:
> Hi Eugene
>
> > From: Eugene Grayver
> > Date: Thu, 9 Nov 2017 19:52:35 +0000
> >
> > There is a major problem with the way tags are propagated in blocks
> > with non-integer relative rate. If the ratio is not a power of two,
> > the numerical accuracy of the floating point will cause the output
> > tags to diverge from the input tags. Consider the fractional
> > resampler. It accumulates the timing offset in the range of 0 to 1.
> > However tag propagation multiplies the ratio by the sample number.
> > As
> > the sample number grows the LSB accuracy of the ratio gets scaled
> > by
> > the ever larger value. For a ratio of 1.001 we saw divergence of
> > 1000s of samples over a few minutes at 10msps.
>
> Could you please test the following branch to see if it fixes the
> problem? Maybe test something simple first, like an FIR filter
> decimating by 5 or 3?
>
> https://github.com/awalls-cx18/gnuradio.git branch: tag_fix3
Don't bother testing. See below.
> Or if you have a GRC or python script I can use myself for testing,
> that would be great.
>
> > I rewrote tag propagation for the resampler but did not rework the
> > generic logic. I think the key point is to use the delta between
> > read
> > and written items to take out the large integer difference and then
> > apply the scaling to a local delta within the current window.
> >
>
> The fix that I have made stores the relative_rate as an integer
> numerator and an integer denominator, and it uses integer arithmetic
> to
> propagate tags. (Except if enable_update_rate() is True, in which
> case,
> precision tag placement was abandonded by the block author anyway.)
So this fix makes the fraction resampler tag propagation actually
perform worse. The reason appears to be that, at least for
resamp_ratios very close to 1.0, the fractional resampler isn't really
running at the requested rate, but some rounded (in binary) rate.
So I have a test flowgraph with a single fractional respampler in it,
with a resample ratio of 1.001 specified. Here are the parameters
reported by my patched GNURadio:
[ andy@pinto grcs]$ ./tag_prop_test.py
Fractional Resampler resamp ratio: 1.00100004673
Block relative rate: 0.999000952364
Block relative rate i: 1000
Block relative rate d: 1001
So we can see that the block is really running with a resampling ratio
of 1.00100004673. The relative rate of 0.999000952364 does appear to
be the correct reciprocal of 1.00100004673. My patch's back-figuring
of a relative rate of 1000/1001 (= 0.999000999 = 1/1.001) is in fact
what the user wanted. But when propagating tags using those integers,
tags start sliding very soon, since 0.999000999 is not the
0.999000952364 that the block is actually operating at.
I'll have to think about how to deal with this sort of situation.
Regards,
Andy
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
