This is not the first time this has come up, and yes, patches are
welcome. The simplest fix might be to add a factory-time argument that
disables the resampler entirely -- this will guarantee no sample
offsets, ever, but of course will not allow to change the timing offset
at runtime.
M
On
Thanks for the hints for where to look and why this happens from a code
perspective. I don't think it makes sense from a semantic perspective (if
the user says taps=1, she should get the unity gain delay free channel) but
I'm guessing "patches are welcome" is the appropriate response to this
minor
On Tue, Jun 28, 2016 at 6:14 PM, Raj Bhattacharjea wrote:
> Consider the identity channel that passes through it's input to its
> output. This is an idealization of a very short run of high quality cable
> between synchronized systems. Using GNURadio's channels_channel_model, I
Hey Raj,
> introduces a delay that can be corrected by applying the taps [0,0,0,1].
> See the attached flowgraph that subtracts the signals before and after
> the channel model; if you let taps = 1, the two signals don't cancel. If
> you use taps = [0,0,0,1], they do.
The delay you are seeing
Consider the identity channel that passes through it's input to its output.
This is an idealization of a very short run of high quality cable between
synchronized systems. Using GNURadio's channels_channel_model, I expect
that the following provides the identity channel:
Noise voltage: 0