Re: [Discuss-gnuradio] Channel model - the identity channel

2016-06-29 Thread Martin Braun
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

Re: [Discuss-gnuradio] Channel model - the identity channel

2016-06-28 Thread Raj Bhattacharjea
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

Re: [Discuss-gnuradio] Channel model - the identity channel

2016-06-28 Thread Tom Rondeau
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

Re: [Discuss-gnuradio] Channel model - the identity channel

2016-06-28 Thread Andrej Rode
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

[Discuss-gnuradio] Channel model - the identity channel

2016-06-28 Thread Raj Bhattacharjea
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