[Discuss-gnuradio] Fractional Resampler discards samples

[Andrej Rode]

Hey everyone,

I'm trying to use the channel model block in between my transmitter and
receiver to test with AWGN Conditions. In the channel model block my tap is
one and epsilon also one. Now I recognised that the first three samples of my
stream are lost and the length tag is propagated to the now first but formerly
fourth tag.

I've noticed this 'problem' has its origin in the fractional resampler. The
fractional resampler (with a resampling rate of 1 and a phase offset) also
discards the first three samples and propagates the tag to the formerly fourth
tag. Also in the output are 8 samples less than in the input but thats due to
the 8-tap filter?

Is this intentional and the expected behaviour and did I miss something?

Help is very much appreciated.

Thanks,
Andrej

[Marcus Müller]

Hi Andrej,

Post by Andrej Rode
(with a resampling rate of 1 and a phase offset) also

I presume that's "... and a ZERO phase offset", right?

So I used the source, Luke, and

1. these are not the resamplers you're looking for (probably), unless
you're really going for non-rational ($\frac1\pi$) or really
really-close-to-1 ratios, and
2. the point where the phase delay is implemented is by using the MMSE
interpolator[1], which really is just a set of FIRs, from which the
right one is selected by definition of the µ to use.

So, point is that d_mu of the fractional resampler is always increased
by resample_ratio[2], which in your case is 1, which means that the MMSE
interpolator always uses the same set of taps[3]. Assuming your
phase_offset == 0, that's always going to be the 0th from [4]:

{ 0.00000e+00, 0.00000e+00, 0.00000e+00, 0.00000e+00, 1.00000e+00,
0.00000e+00, 0.00000e+00, 0.00000e+00 }, // 0/128

which immediately explains a certain delay; but not really a dropping of
samples.
I thing the stream tag behaviour might be a bug that Tom was actually
working on; maybe he can comment.

Cheers,
Marcus

[1]
https://github.com/gnuradio/gnuradio/blob/master/gr-filter/lib/fractional_resampler_cc_impl.cc#L87
, #L47
[2]
https://github.com/gnuradio/gnuradio/blob/master/gr-filter/lib/fractional_resampler_cc_impl.cc#L89
, #L46
[3]
https://github.com/gnuradio/gnuradio/blob/master/gr-filter/lib/mmse_fir_interpolator_cc.cc#L66
, #L72
[4]
https://github.com/gnuradio/gnuradio/blob/master/gr-filter/include/gnuradio/filter/interpolator_taps.h#L11

[Andrej Rode]

Thanks for the reply

Post by Marcus Müller

Post by Andrej Rode
(with a resampling rate of 1 and a phase offset) also

I presume that's "... and a ZERO phase offset", right?

Yes, you guessed right somehow I left the word zero out.

Post by Marcus Müller
So I used the source, Luke, and
1. these are not the resamplers you're looking for (probably), unless
you're really going for non-rational ($\frac1\pi$) or really
really-close-to-1 ratios, and
2. the point where the phase delay is implemented is by using the MMSE
interpolator[1], which really is just a set of FIRs, from which the
right one is selected by definition of the µ to use.

I have not selected this resampler by myself and just recognised some weird
behaviour in the channel model block.

I have just ran some tests and it seems there is not just a delay:
(again resampling rate=1.0 phase offset=0)

First five input samples:

[(1+0j), (0.9980267284282716+0.06279051952931337j),
(0.9921147013144779+0.12533323356430426j),
(0.9822872507286887+0.18738131458572463j),
(0.9685831611286311+0.2486898871648548j)]

First five output samples:

((0.9822872281074524+0.187381312251091j),
(0.9685831665992737+0.24868988990783691j),
(0.9510565400123596+0.30901700258255005j),
(0.9297764897346497+0.3681245446205139j),
(0.9048270583152771+0.4257792830467224j))

A delay would be something I expect but completely removing samples? Is it
possible the first 3 samples are used to initialize the filter? Maybe I can
also dig through the source but not until evening.

Regards,
Andrej

[Andrej Rode]

I've figured out why the samples are 'dropped'.

Using this set [0] of filter taps and performing a convolution with my input
sample stream. The first three samples are always multiplied with zero and are
ignored in the sum.

This behaviour seems inherent and not like a bug. But I think this behaviour
isn't not obvious if using the channel model block.

Regards,
Andrej

[0] { 0.00000e+00, 0.00000e+00, 0.00000e+00, 0.00000e+00, 1.00000e+00,
0.00000e+00, 0.00000e+00, 0.00000e+00 }, // 0/128