Re: [Discuss-gnuradio] how does Doppler shift increment in flat fading channel GNU radio

[Bastian Bloessl]

Hi Tim,

> On 08 Mar 2016, at 19:07, Bastian Bloessl  wrote:
> 
> Anyhow, I think that we should, at least, wait for an opinion of one of the 
> developers, otherwise you might waste time implementing a new model and 
> nobody cares.
> 

as far as I understand, you implemented and now maintain this part of GNU 
Radio. Therefore, it would be very interesting to hear your opinion about that 
topic (it came up several times in the last months).

In particular, it would be good to know whether you also see the problem and if 
you can remember why the block was implemented like that. Given the reference 
to a “Table 2”, I guess you followed a paper or book.

Best,
Bastian
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] how does Doppler shift increment in flat fading channel GNU radio

[Bastian Bloessl]

Hi Stephan,

thanks for your reply. I’m very happy that this is going forward.


> On 08 Mar 2016, at 05:16, Ludwig Stephan (CR/AEH4) 
>  wrote:
> Just to make it clear (to myself):
> alpha_n changes randomly.
> BUT: alpha_n depends on theta, which in turn does a random walk in the code

Yes, theta does a random walk back and forth between [-pi; pi]. Since alpha_n 
is calculated as

float alpha_n = (2*M_PI*n - M_PI + d_theta)/4*d_N;

it is oscillating in a segment/part of the spectrum not the complete [-pi; pi] 
interval. But, that leads to the same amplified effect described earlier.
I don’t know when you checked my IPython notebook. I added another plot, to 
show how (i think that) the variables behave

https://www.bastibl.net/rayleigh-autocorrelation/#Values-over-time 



>  
> > "Efficient Simulation of Rayleigh Fading with Enhanced De-Correlation 
> > Properties” by  Alenka G. Zajic  and Gordon L. Stüber
> > http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=1673098 
> > 
> > the authors refer to the paper, stating that:
>  
> Ahh, that is a very good reference. Actually I was searching for that in my 
> literature database but did not find it again.
>  
> > "To improve on previously reported models, Zheng and Xiao proposed several 
> > new statistical models [14]-[16]. By allowing all
> > three parameter sets (amplitudes, phases, and Doppler frequencies) to be 
> > random variables, Zheng and Xiao’s models obtain
> > statistical properties similar to ones required by the reference model. 
> > However, the models are no longer ergodic."
> > 
> > To me it looks like the model was _fixed_ by introducing this random walk 
> > that is supposed to make the model great ergodic 
> > again. I guess this follows some paper or book since the code mentions a 
> > table
> > d_step( powf(0.00125*fDTs, 1.1) ),  // max step size approximated from 
> > Table 2
>  
> No, the model of Zajic/Stüber is ergodic. But yes, they fixed the previous 
> model by choosing the parameters randomly – but constant over time and not 
> updating for every sample. And Table II does definitely not refer to the one 
> in their paper


That was maybe a bit confusing. I cited how Zajic/Stüber are talking about the 
GNU Radio model, to highlight that it is by default non-ergodic. I was not 
talking about the Zajic/Stüber model.


>  
> I try to summarize all the efforts
> · Use sin and cos in the factors for getting (almost) uncorrelated I 
> and Q shares of the complex random variable
> · Introduce a random phase (but constant) argument into every 
> cos(f_D*t) term in order to make the system WSS
> · In order to make the signals ergodic (ever draw of parameters has 
> the equal statistics, which also yield uncorrelated processes) let sin(f_D*t) 
> and cos(f_D*t) have different random (but constant) phases, but thake the 
> cos/sin factors from identical angles of arrival
> · MEDS method produces WSS process of intended auto-correlation 
> function, but introduces correlation between different random process.
> · The Zheng/Xiao model combines all previous advantages: still 
> constant but different phases
> · The Zajic/Stüber model combines all previosu advantages, especially 
> it has a random but constant phase (-> WSS), is ergodic, has uncorrelated I/Q 
> and uncorrelated processes, while converging faster (requires smaller N).

As far as I understand it’s either ergodic, but has suboptimal autocorrelation; 
or it’s non-ergodic. 

>  
> => In conclusion and because nobody remembers why this code was written like 
> that, I vote for adapting the model to Zajic/Stüber by removing the 
> update_theta function and their call (and then unused variables like d_step). 
> Their implementation is one of the best-known ones.
>  

Sounds reasonable to me, but I’m not an expert.

I think that when creating a TDL channel with multiple independent faders, one 
would have to set the parameters of all sinusoids in a special way, i.e., one 
would have to adapt the interface to the flat fader block, too.
…or in other words, the implementation would, at least, not be trivial :-) 
Would you be interested to work on that?

AFAIS, another option would be to remove theta and change the docs to state 
that the model should not be used with one long simulation run, but with 
multiple repetitions.

In general, I think that the current random walk is a pretty cool idea. In the 
best case we would find a paper that describes this method. Maybe, we wait some 
more time to see if someone knows about that.

Anyhow, I think that we should, at least, wait for an opinion of one of the 
developers, otherwise you might waste time implementing a new model and nobody 
cares.

Best,
Bastian









___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org

Re: [Discuss-gnuradio] how does Doppler shift increment in flat fading channel GNU radio

[Ludwig Stephan (CR/AEH4)]

Hi Bastian,

I thought being a bit more thorough on the SOS method never harms ;-)

Aah, I got the point: alpha_n depends on theta and theta increases. I mixed it 
up and thought we were talking about psi and phi.

> It does not grow, but change over time. alpha_n depends on theta, which is 
> updated after each sample. Through theta, alpha_n is
> doing a random walk in the interval [- pi;  pi]  so that the term
>
> d_fDTs *sin(alpha_n)
>
> is a random walk through the Doppler spectrum.

Just to make it clear (to myself):
alpha_n changes randomly.
BUT: alpha_n depends on theta, which in turn does a random walk in the code

Bastian, you are right. In all the papers theta is a randomly chosen constant. 
And it should remain constant – at least for a certain time. After some time, 
the difference between actual process and intended process might run away such 
that a re-initialization might be appropriate. In this case you have to do 
something, which keeps the samples of previous calls continuous with the call 
using new parameters. By alternating the sign of the random variable, someone 
is trying to keep theta “in lanes”. Maybe the random walk of theta is an (I 
think inappropriate, because it does not work, because all other parameters get 
changed independently) way of achieving this.
In fact, the code should not use update_theta for every new output sample, 
because I fear that this makes successive samples non-continuous – and your 
iPython notebook backs this.
And theta should not saturate at +/- pi, either. I do not have a clue, where 
the step size is taken from. It is definitely not Table II in the Zajic/Stüber 
paper.

[…]

> "Efficient Simulation of Rayleigh Fading with Enhanced De-Correlation 
> Properties” by  Alenka G. Zajic  and Gordon L. Stüber
> http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=1673098
> the authors refer to the paper, stating that:

Ahh, that is a very good reference. Actually I was searching for that in my 
literature database but did not find it again.

> "To improve on previously reported models, Zheng and Xiao proposed several 
> new statistical models [14]-[16]. By allowing all
> three parameter sets (amplitudes, phases, and Doppler frequencies) to be 
> random variables, Zheng and Xiao’s models obtain
> statistical properties similar to ones required by the reference model. 
> However, the models are no longer ergodic."
>
> To me it looks like the model was _fixed_ by introducing this random walk 
> that is supposed to make the model great ergodic
> again. I guess this follows some paper or book since the code mentions a table
> d_step( powf(0.00125*fDTs, 1.1) ),  // max step size approximated from Table 2

No, the model of Zajic/Stüber is ergodic. But yes, they fixed the previous 
model by choosing the parameters randomly – but constant over time and not 
updating for every sample. And Table II does definitely not refer to the one in 
their paper.

I try to summarize all the efforts

· Use sin and cos in the factors for getting (almost) uncorrelated I 
and Q shares of the complex random variable

· Introduce a random phase (but constant) argument into every 
cos(f_D*t) term in order to make the system WSS

· In order to make the signals ergodic (ever draw of parameters has the 
equal statistics, which also yield uncorrelated processes) let sin(f_D*t) and 
cos(f_D*t) have different random (but constant) phases, but thake the cos/sin 
factors from identical angles of arrival

· MEDS method produces WSS process of intended auto-correlation 
function, but introduces correlation between different random process.

· The Zheng/Xiao model combines all previous advantages: still constant 
but different phases

· The Zajic/Stüber model combines all previosu advantages, especially 
it has a random but constant phase (-> WSS), is ergodic, has uncorrelated I/Q 
and uncorrelated processes, while converging faster (requires smaller N).

=> In conclusion and because nobody remembers why this code was written like 
that, I vote for adapting the model to Zajic/Stüber by removing the 
update_theta function and their call (and then unused variables like d_step). 
Their implementation is one of the best-known ones.


Best regards

Stephan Ludwig

Communication Technology (CR/AEH4)
Robert Bosch GmbH | Renningen | 70465 Stuttgart | GERMANY | 
www.bosch.com
Tel. +49(711)811-8809 | Mobile +49(172)5630639 | Fax +49(711)811-5187845 | 
stephan.ludw...@de.bosch.com

Registered Office: Stuttgart, Registration Court: Amtsgericht Stuttgart, HRB 
14000;
Chairman of the Supervisory Board: Franz Fehrenbach; Managing Directors: Dr. 
Volkmar Denner,
Dr. Stefan Asenkerschbaumer, Dr. Rolf Bulander, Dr. Stefan Hartung, Dr. Markus 
Heyn, Dr. Dirk Hoheisel,
Christoph Kübel, Uwe Raschke, Dr. Werner Struth, Peter Tyroller



___
Discuss-gnuradio mailing list

Re: [Discuss-gnuradio] how does Doppler shift increment in flat fading channel GNU radio

[Bastian Bloessl]

ide-sense stationary. 
> Paetzold’s method (or Jake’s sum-of-sinoids method in general) does not 
> procude (wide-)sense stationary (simulated) random processes. [2] adds the 
> possibility of generating several such processes, which should be 
> uncorrelated for a uncorrelated scattering frequency-selective fading 
> channel. In general they are correlated, because the randomness is taken from 
> the very same random number generator. But with proper choice of the 
> parameters one can achieve uncorrelated processes. There exist further 
> improvements of the group around Zheng and Beaulieu [2,3,4], which all 
> correct some second or higher order statistical properties.
> As a conclusion, the GNU Radio should be preferred over the one of IT++, 
> because of its WSS property.
>  
> From my point of view, I cannot see, why the correlation could increase over 
> time. To make it clear, N sinusoid have to be added up for building one 
> single time sample of the process.
>  
> I cannot go much into your iPython notebook sheet, but maybe there is a 
> misinterpretation of N?
>  
> Cheers,
> Stephan
>  
> [1] Pätzold: “Mobile Fading Channels”
> [2] "Improved Models for the Generation of Multiple Uncorrelated Rayleigh 
> Fading Waveforms”  by Yahong R. Zheng and Chengshan Xiao, 
> http://web.mst.edu/~xiaoc/Pub/Zheng_Xiao_CommLett.pdf
> [3] http://web.mst.edu/~xiaoc/Pub/Xiao_Zheng_Beaulieu_TWireless.pdf
> [4] 
> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.333.217&rep=rep1&type=pdf
> [5] http://itpp.sourceforge.net/4.3.1/channel_8cpp_source.html
>  
>  
> Mit freundlichen Grüßen / Best regards 
> 
> Stephan Ludwig
> 
> Communication Technology (CR/AEH4) 
> Robert Bosch GmbH | Renningen | 70465 Stuttgart | GERMANY | www.bosch.com 
> Tel. +49(711)811-8809 | Mobile +49(172)5630639 | Fax +49(711)811-5187845 | 
> stephan.ludw...@de.bosch.com 
> 
> Registered Office: Stuttgart, Registration Court: Amtsgericht Stuttgart, HRB 
> 14000;
> Chairman of the Supervisory Board: Franz Fehrenbach; Managing Directors: Dr. 
> Volkmar Denner,
> Dr. Stefan Asenkerschbaumer, Dr. Rolf Bulander, Dr. Stefan Hartung, Dr. 
> Markus Heyn, Dr. Dirk Hoheisel,
> Christoph Kübel, Uwe Raschke, Dr. Werner Struth, Peter Tyroller 
> 
> 
> Von: discuss-gnuradio-bounces+stephan.ludwig2=de.bosch@gnu.org 
> [mailto:discuss-gnuradio-bounces+stephan.ludwig2=de.bosch@gnu.org]Im 
> Auftrag von Bastian Bloessl
> Gesendet: Montag, 7. März 2016 01:12
> An: discuss-gnuradio@gnu.org
> Betreff: Re: [Discuss-gnuradio] how does Doppler shift increment in flat 
> fading channel GNU radio
>  
> …looks like this topic isn’t too popular : -)
> Anyhow, I wanted to make another attempt as I would really appreciate if 
> someone could comment on this thread or the threads at [1] or [2].
>  
> Unfortunately, I still fail to understand the implementation of the flat 
> fader and particularly these lines [3]
>  
> float s_i = scale_sin*cos(2*M_PI*d_fDTs*d_m*cos(alpha_n)+d_psi[n]);
> float s_q = scale_sin*cos(2*M_PI*d_fDTs*d_m*sin(alpha_n)+d_phi[n]);
> 
> As far as I see, alpha_n is changing from sample to sample, which produces an 
> amplified effect over time that changes autocorrelation properties.
> (It behaves as if the instantaneous Doppler frequency would have been present 
> since the start and, thus, produces larger and larger phase shifts between 
> subsequent samples.)
>  
> I tried to show the effect with an iPython notebook
> https://www.bastibl.net/rayleigh-autocorrelation/
>  
> It would be great if someone could point me to a paper/book with the 
> algorithm that is implemented here. The only thing I could find is 
>  
> "Improved Models for the Generation of Multiple Uncorrelated Rayleigh Fading 
> Waveforms”  by Yahong R. Zheng and Chengshan Xiao
> http://web.mst.edu/~xiaoc/Pub/Zheng_Xiao_CommLett.pdf
>  
> which proposes the parameter set, but not the random walk through the Doppler 
> spectrum that seems to be an attempt to make simulations ergodic.
>  
> Best,
> Bastian
>  
>  
> [1] http://lists.gnu.org/archive/html/discuss-gnuradio/2016-02/msg00254.html 
> [2] http://lists.gnu.org/archive/html/discuss-gnuradio/2016-02/msg00305.html
> [3] 
> https://github.com/gnuradio/gnuradio/blob/next/gr-channels/lib/flat_fader_impl.cc#L76
>  
>  
> On 23 Feb 2016, at 08:35, Bastian Bloessl  wrote:
>  
> 
> On 23 Feb 2016, at 02:35, Kelvin Augustin  wrote:
>  
> Hi Bastian
>  
> What I don’t get (and what I asked in the other thread) is why this is 
> multiplied with d_m. I think that, per sample, the current Doppler Frequency 
> should be used to calculate an incremental angle to the previous value.
>  
> To answ

Re: [Discuss-gnuradio] how does Doppler shift increment in flat fading channel GNU radio

[Ludwig Stephan (CR/AEH4)]

uth, Peter Tyroller


Von: discuss-gnuradio-bounces+stephan.ludwig2=de.bosch@gnu.org 
[mailto:discuss-gnuradio-bounces+stephan.ludwig2=de.bosch@gnu.org] Im 
Auftrag von Bastian Bloessl
Gesendet: Montag, 7. März 2016 01:12
An: discuss-gnuradio@gnu.org
Betreff: Re: [Discuss-gnuradio] how does Doppler shift increment in flat fading 
channel GNU radio

…looks like this topic isn’t too popular : -)
Anyhow, I wanted to make another attempt as I would really appreciate if 
someone could comment on this thread or the threads at [1] or [2].

Unfortunately, I still fail to understand the implementation of the flat fader 
and particularly these lines [3]

float s_i = scale_sin*cos(2*M_PI*d_fDTs*d_m*cos(alpha_n)+d_psi[n]);
float s_q = scale_sin*cos(2*M_PI*d_fDTs*d_m*sin(alpha_n)+d_phi[n]);

As far as I see, alpha_n is changing from sample to sample, which produces an 
amplified effect over time that changes autocorrelation properties.
(It behaves as if the instantaneous Doppler frequency would have been present 
since the start and, thus, produces larger and larger phase shifts between 
subsequent samples.)

I tried to show the effect with an iPython notebook
https://www.bastibl.net/rayleigh-autocorrelation/

It would be great if someone could point me to a paper/book with the algorithm 
that is implemented here. The only thing I could find is

"Improved Models for the Generation of Multiple Uncorrelated Rayleigh Fading 
Waveforms”  by Yahong R. Zheng and Chengshan Xiao
http://web.mst.edu/~xiaoc/Pub/Zheng_Xiao_CommLett.pdf

which proposes the parameter set, but not the random walk through the Doppler 
spectrum that seems to be an attempt to make simulations ergodic.

Best,
Bastian


[1] http://lists.gnu.org/archive/html/discuss-gnuradio/2016-02/msg00254.html
[2] http://lists.gnu.org/archive/html/discuss-gnuradio/2016-02/msg00305.html
[3] 
https://github.com/gnuradio/gnuradio/blob/next/gr-channels/lib/flat_fader_impl.cc#L76


On 23 Feb 2016, at 08:35, Bastian Bloessl 
mailto:bloe...@ccs-labs.org>> wrote:


On 23 Feb 2016, at 02:35, Kelvin Augustin 
mailto:kelvin.che...@gmail.com>> wrote:

Hi Bastian

What I don’t get (and what I asked in the other thread) is why this is 
multiplied with d_m. I think that, per sample, the current Doppler Frequency 
should be used to calculate an incremental angle to the previous value.

To answer this, I would consider of the correspondence (via a Fourier 
Transform) of a Doppler shift in the time domain; A shift in frequency 
corresponds to a "time" dependant phase shift in the time domain. Thus a 
Doppler shift of Fd in the time domain corresponds to exp(j*2*pi*Fd*t). And 
since Dynamic channel model(flat_fader to be precise) in GNURadio models the 
Doppler in the time domain, the d_m could be a way to model the time.

Yes, I understand that d_m is like time here, and it would be perfectly fine if 
fD would stay constant during the whole simulation.

But as fD changes over time, the phase change from one sample to another (due 
to the same change in dopplers shift) will be amplified over time. AFAIS, this 
changes the autocorrelation properties over time.

I would have expected something like

tap[n+1] = tap[n] exp(2*pi*i*fD*cos(alpha))

Best,
Bastian



I would also ask a supplementing question that I am having problems 
understanding. I would expect the Doppler shift to be modelled by a complex 
exponential(cos[2*pi*Fd*t*cos(alpha)] + i sin [2*pi*Fd*t*cos(alpha)]) which 
corroborates what we know from the Fourier correspondence of a Doppler shift. 
Why then, in the Dynamic channel model in GNURadio (flat_fader to be precise), 
the Doppler is modelled by (cos[2*pi*Fd*t*cos(alpha)] + i cos 
[2*pi*Fd*t*sin(alpha)]) ?? I.e why is the imaginary part a cos ? Any hints?



On 22 Feb 2016, at 06:41, Nasi mailto:nesaz...@mail.ru>> 
wrote:

Hello,

The question is about how does the given Doppler shift progress, or how is the 
Doppler induced phase shift implemented.

I select a simple frequency selective fading block and feed in it some 
gr_complex(1, 0) values. For simplicity I run one fader (num of sinusoids).
in file:
https://github.com/osh/gnuradio.old/blob/master/gr-channels/lib/flat_fader_impl.cc
in the code below,
#elif FASTSINCOS == 2



float s_i = 
scale_sin*d_table.cos(2*M_PI*d_fDTs*d_m*d_table.cos(alpha_n)+d_psi[n+1]);



float s_q = 
scale_sin*d_table.cos(2*M_PI*d_fDTs*d_m*d_table.sin(alpha_n)+d_phi[n+1]);







#else

 d_m shows that the Doppler shift must progress sequencially. However, the 
value of "2*M_PI*d_fDTs*d_m*d_table.cos(alpha_n)" as a whole, produces floating 
point numbers which results in kind of random values out of d_table.cos() 
function in file
https://github.com/osh/gnuradio.old/blob/master/gr-channels/lib/sincostable.h

Some more explanation:
the value: 2*M_PI*d_fDTs*d_m*d_table.cos(alpha_n) gets in as x below (in file 
.../lib/sincostable.h)
(((int)(x*d_scale)) + d_sz) % d_sz; - this is a random integer value (

Re: [Discuss-gnuradio] how does Doppler shift increment in flat fading channel GNU radio

[Bastian Bloessl]

…looks like this topic isn’t too popular : -)
Anyhow, I wanted to make another attempt as I would really appreciate if 
someone could comment on this thread or the threads at [1] or [2].

Unfortunately, I still fail to understand the implementation of the flat fader 
and particularly these lines [3]

float s_i = scale_sin*cos(2*M_PI*d_fDTs*d_m*cos(alpha_n)+d_psi[n]);
float s_q = scale_sin*cos(2*M_PI*d_fDTs*d_m*sin(alpha_n)+d_phi[n]);

As far as I see, alpha_n is changing from sample to sample, which produces an 
amplified effect over time that changes autocorrelation properties.
(It behaves as if the instantaneous Doppler frequency would have been present 
since the start and, thus, produces larger and larger phase shifts between 
subsequent samples.)

I tried to show the effect with an iPython notebook
https://www.bastibl.net/rayleigh-autocorrelation/

It would be great if someone could point me to a paper/book with the algorithm 
that is implemented here. The only thing I could find is 

"Improved Models for the Generation of Multiple Uncorrelated Rayleigh Fading 
Waveforms”  by Yahong R. Zheng and Chengshan Xiao
http://web.mst.edu/~xiaoc/Pub/Zheng_Xiao_CommLett.pdf 


which proposes the parameter set, but not the random walk through the Doppler 
spectrum that seems to be an attempt to make simulations ergodic.

Best,
Bastian


[1] http://lists.gnu.org/archive/html/discuss-gnuradio/2016-02/msg00254.html 
[2] http://lists.gnu.org/archive/html/discuss-gnuradio/2016-02/msg00305.html
[3] 
https://github.com/gnuradio/gnuradio/blob/next/gr-channels/lib/flat_fader_impl.cc#L76


> On 23 Feb 2016, at 08:35, Bastian Bloessl  wrote:
> 
>> 
>> On 23 Feb 2016, at 02:35, Kelvin Augustin > > wrote:
>> 
>> Hi Bastian
>> 
>> What I don’t get (and what I asked in the other thread) is why this is 
>> multiplied with d_m. I think that, per sample, the current Doppler Frequency 
>> should be used to calculate an incremental angle to the previous value.
>> 
>> To answer this, I would consider of the correspondence (via a Fourier 
>> Transform) of a Doppler shift in the time domain; A shift in frequency 
>> corresponds to a "time" dependant phase shift in the time domain. Thus a 
>> Doppler shift of Fd in the time domain corresponds to exp(j*2*pi*Fd*t). And 
>> since Dynamic channel model(flat_fader to be precise) in GNURadio models the 
>> Doppler in the time domain, the d_m could be a way to model the time. 
> 
> Yes, I understand that d_m is like time here, and it would be perfectly fine 
> if fD would stay constant during the whole simulation.
> 
> But as fD changes over time, the phase change from one sample to another (due 
> to the same change in dopplers shift) will be amplified over time. AFAIS, 
> this changes the autocorrelation properties over time.
> 
> I would have expected something like
> 
> tap[n+1] = tap[n] exp(2*pi*i*fD*cos(alpha))
> 
> Best,
> Bastian
> 
>> 
>> I would also ask a supplementing question that I am having problems 
>> understanding. I would expect the Doppler shift to be modelled by a complex 
>> exponential(cos[2*pi*Fd*t*cos(alpha)] + i sin [2*pi*Fd*t*cos(alpha)]) which 
>> corroborates what we know from the Fourier correspondence of a Doppler 
>> shift. Why then, in the Dynamic channel model in GNURadio (flat_fader to be 
>> precise), the Doppler is modelled by (cos[2*pi*Fd*t*cos(alpha)] + i cos 
>> [2*pi*Fd*t*sin(alpha)]) ?? I.e why is the imaginary part a cos ? Any hints?
>>  
>> 
>> 
>>> On 22 Feb 2016, at 06:41, Nasi mailto:nesaz...@mail.ru>> 
>>> wrote:
>>> 
>>> Hello,
>>> 
>>> The question is about how does the given Doppler shift progress, or how is 
>>> the Doppler induced phase shift implemented.
>>> 
>>> I select a simple frequency selective fading block and feed in it some 
>>> gr_complex(1, 0) values. For simplicity I run one fader (num of sinusoids).
>>> in file:
>>> https://github.com/osh/gnuradio.old/blob/master/gr-channels/lib/flat_fader_impl.cc
>>>  
>>> 
>>>  
>>> in the code below,
>>> #elif FASTSINCOS == 2
>>> float s_i = 
>>> scale_sin*d_table.cos(2*M_PI*d_fDTs*d_m*d_table.cos(alpha_n)+d_psi[n+1]);
>>> float s_q = 
>>> scale_sin*d_table.cos(2*M_PI*d_fDTs*d_m*d_table.sin(alpha_n)+d_phi[n+1]);
>>>  
>>> #else
>>>  d_m shows that the Doppler shift must progress sequencially. However, the 
>>> value of "2*M_PI*d_fDTs*d_m*d_table.cos(alpha_n)" as a whole, produces 
>>> floating point numbers which results in kind of random values out of 
>>> d_table.cos() function in file 
>>> https://github.com/osh/gnuradio.old/blob/master/gr-channels/lib/sincostable.h
>>>  
>>> 
>>> 
>>> Some more explanation:
>>> the value: 2*M_PI*d_fDTs*d_m*d_table.cos(alpha_n) gets in as x below (in 
>>> file .../lib/sincostable.h)
>>> (((int)

Re: [Discuss-gnuradio] how does Doppler shift increment in flat fading channel GNU radio

[Bastian Bloessl]

> On 23 Feb 2016, at 02:35, Kelvin Augustin  wrote:
> 
> Hi Bastian
> 
> What I don’t get (and what I asked in the other thread) is why this is 
> multiplied with d_m. I think that, per sample, the current Doppler Frequency 
> should be used to calculate an incremental angle to the previous value.
> 
> To answer this, I would consider of the correspondence (via a Fourier 
> Transform) of a Doppler shift in the time domain; A shift in frequency 
> corresponds to a "time" dependant phase shift in the time domain. Thus a 
> Doppler shift of Fd in the time domain corresponds to exp(j*2*pi*Fd*t). And 
> since Dynamic channel model(flat_fader to be precise) in GNURadio models the 
> Doppler in the time domain, the d_m could be a way to model the time. 

Yes, I understand that d_m is like time here, and it would be perfectly fine if 
fD would stay constant during the whole simulation.

But as fD changes over time, the phase change from one sample to another (due 
to the same change in dopplers shift) will be amplified over time. AFAIS, this 
changes the autocorrelation properties over time.

I would have expected something like

tap[n+1] = tap[n] exp(2*pi*i*fD*cos(alpha))

Best,
Bastian

> 
> I would also ask a supplementing question that I am having problems 
> understanding. I would expect the Doppler shift to be modelled by a complex 
> exponential(cos[2*pi*Fd*t*cos(alpha)] + i sin [2*pi*Fd*t*cos(alpha)]) which 
> corroborates what we know from the Fourier correspondence of a Doppler shift. 
> Why then, in the Dynamic channel model in GNURadio (flat_fader to be 
> precise), the Doppler is modelled by (cos[2*pi*Fd*t*cos(alpha)] + i cos 
> [2*pi*Fd*t*sin(alpha)]) ?? I.e why is the imaginary part a cos ? Any hints?
>  
> 
> 
>> On 22 Feb 2016, at 06:41, Nasi mailto:nesaz...@mail.ru>> 
>> wrote:
>> 
>> Hello,
>> 
>> The question is about how does the given Doppler shift progress, or how is 
>> the Doppler induced phase shift implemented.
>> 
>> I select a simple frequency selective fading block and feed in it some 
>> gr_complex(1, 0) values. For simplicity I run one fader (num of sinusoids).
>> in file:
>> https://github.com/osh/gnuradio.old/blob/master/gr-channels/lib/flat_fader_impl.cc
>>  
>> 
>>  
>> in the code below,
>> #elif FASTSINCOS == 2
>>  float s_i = 
>> scale_sin*d_table.cos(2*M_PI*d_fDTs*d_m*d_table.cos(alpha_n)+d_psi[n+1]);
>>  float s_q = 
>> scale_sin*d_table.cos(2*M_PI*d_fDTs*d_m*d_table.sin(alpha_n)+d_phi[n+1]);
>>   
>>  #else
>>  d_m shows that the Doppler shift must progress sequencially. However, the 
>> value of "2*M_PI*d_fDTs*d_m*d_table.cos(alpha_n)" as a whole, produces 
>> floating point numbers which results in kind of random values out of 
>> d_table.cos() function in file 
>> https://github.com/osh/gnuradio.old/blob/master/gr-channels/lib/sincostable.h
>>  
>> 
>> 
>> Some more explanation:
>> the value: 2*M_PI*d_fDTs*d_m*d_table.cos(alpha_n) gets in as x below (in 
>> file .../lib/sincostable.h)
>> (((int)(x*d_scale)) + d_sz) % d_sz; - this is a random integer value (may be 
>> not, can you please help me with that?)
>> therefore it returns a random cos value as: return d_cos[idx];
>> 
>> The issue arises when that floating point values inside cos() function is 
>> converted to integers as given above.
>> 
>> Now, my question is, did you do that random phase shift/Doppler shift on 
>> purpose? If yes, what is the reasoning behind that.
>> As far as I know, the Doppler shift should be somehow linear progressive.
>> 
>> -- 
>> NE
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org 
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio 
>> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio 
> 
> 
> 
> 
> 
> -- 
> Ph.D. scholar: Kelvin Chelli
> OFDM based wireless systems
> Telecommunications Lab, Uni Saarland
> Campus C6 3, Room  10.07
> 66123 Saarbrücken, Germany.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] how does Doppler shift increment in flat fading channel GNU radio

[Kelvin Augustin]

Hi Bastian,



>
> The Doppler Frequency per sinusoid is distributed according to that
> U-shaped thing you see everywhere.
> Now, instead of rolling the dice once during initialisation and sticking
> to that Doppler frequency forever, this implementation is doing something
> like a random walk through the Doppler Spectrum.
>
> alpha_n is going back and forth between -pi and pi (plus some initial
> phase offset), so fDTs * cos(alpha_n), the normalised Doppler Frequency,
> follows this U-distribution.
>

Exactly. The dynamic channel in GNURadio models the Doppler spectrum
accurately.

What I don’t get (and what I asked in the other thread) is why this is
> multiplied with d_m. I think that, per sample, the current Doppler
> Frequency should be used to calculate an incremental angle to the previous
> value.
>
> To answer this, I would consider of the correspondence (via a Fourier
Transform) of a Doppler shift in the time domain; A shift in frequency
corresponds to a "time" dependant phase shift in the time domain. Thus a
Doppler shift of Fd in the time domain corresponds to exp(j*2*pi*Fd*t). And
since Dynamic channel model(flat_fader to be precise) in GNURadio models
the Doppler in the time domain, the d_m could be a way to model the time.

I would also ask a supplementing question that I am having problems
understanding. I would expect the Doppler shift to be modelled by a complex
exponential(cos[2*pi*Fd*t*cos(alpha)] + i sin [2*pi*Fd*t*cos(alpha)]) which
corroborates what we know from the Fourier correspondence of a Doppler
shift. Why then, in the Dynamic channel model in GNURadio (flat_fader to be
precise), the Doppler is modelled by (cos[2*pi*Fd*t*cos(alpha)] + i cos
[2*pi*Fd*t*sin(alpha)]) ?? I.e why is the imaginary part a cos ? Any hints?


>
>
> On 22 Feb 2016, at 06:41, Nasi  wrote:
>
> Hello,
>
> The question is about how does the given Doppler shift progress, or how is
> the Doppler induced phase shift implemented.
>
> I select a simple frequency selective fading block and feed in it some
> gr_complex(1, 0) values. For simplicity I run one fader (num of sinusoids).
> in file:
>
> https://github.com/osh/gnuradio.old/blob/master/gr-channels/lib/flat_fader_impl.cc
>
> in the code below,
> #elif FASTSINCOS == 2
>   float s_i = scale_sin*d_table.cos(2*M_PI*d_fDTs*d_m*d_table.cos
> (alpha_n)+d_psi[n+1]);
>   float s_q = scale_sin*d_table.cos(2*M_PI*d_fDTs*d_m*d_table.sin
> (alpha_n)+d_phi[n+1]);
>
>   #else d_m shows that the Doppler shift must progress sequencially.
> However, the value of "2*M_PI*d_fDTs*d_m*d_table.cos(alpha_n)" as a
> whole, produces floating point numbers which results in kind of random
> values out of d_table.cos() function in file
>
> https://github.com/osh/gnuradio.old/blob/master/gr-channels/lib/sincostable.h
>
> Some more explanation:
> the value: 2*M_PI*d_fDTs*d_m*d_table.cos(alpha_n) gets in as x below (in
> file .../lib/sincostable.h)
> (((int)(x*d_scale)) + d_sz) % d_sz; - this is a random integer value (may
> be not, can you please help me with that?)
> therefore it returns a random cos value as: return d_cos[idx];
>
> The issue arises when that floating point values inside cos() function is
> converted to integers as given above.
>
> Now, my question is, did you do that random phase shift/Doppler shift on
> purpose? If yes, what is the reasoning behind that.
> As far as I know, the Doppler shift should be somehow linear progressive.
>
> --
> NE
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


-- 
Ph.D. scholar: Kelvin Chelli
OFDM based wireless systems
Telecommunications Lab, Uni Saarland
Campus C6 3, Room  10.07
66123 Saarbrücken, Germany. 
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] how does Doppler shift increment in flat fading channel GNU radio

[Bastian Bloessl]

Hi,

> On 22 Feb 2016, at 10:54, Nasi  wrote:
> 
> d_m is incrementation or index after initialization, which is correct thing 
> there.

This is what I don’t get. d_m is the absolute sample index. Let’s say you have 
a slight change in Doppler Frequency, then, from the first to the second sample 
this results in a slight phase change d_m * delta_f.
Now assume the same delta_f after the 10e6 sample. AFAIS, this will just go 
crazy and maybe result in seemingly random accesses to your sincostable.

> Yes, as you also said that is per sample.
> cos(alpha_n) is constant there,

alpha_n is not constant. It depends on d_theta, which is updated after each 
sample
https://github.com/gnuradio/gnuradio/blob/master/gr-channels/lib/flat_fader_impl.cc#L67
 


Best,
Bastian


> I checked that. cos table looks like just cosine values, which must be there 
> somehow.
> 
> But the value are selected out of cos table kind of randomly. I think there 
> is a "bug" in the code. Otherwise, let someone explain it better. The Doppler 
> shift cannot jump from sample to sample randomly. If I make a mistake please 
> correct it.
> 
> 
> P.S.: In matlab that thing is not random. After some samples that changes a 
> little bit depending on the max Doppler shift.
> 
> -
> Nasimi
> 
> Понедельник, 22 февраля 2016, 9:54 -08:00 от Bastian Bloessl 
> :
> 
> Hi,
> 
> I posted a question about the very same lines of code four days ago, but did 
> not get a reply yet
> 
> http://lists.gnu.org/archive/html/discuss-gnuradio/2016-02/msg00254.html 
> 
> 
> I’m not sure whats going on there, but some wild guesses:
> 
> The Doppler Frequency per sinusoid is distributed according to that U-shaped 
> thing you see everywhere.
> Now, instead of rolling the dice once during initialisation and sticking to 
> that Doppler frequency forever, this implementation is doing something like a 
> random walk through the Doppler Spectrum.
> 
> alpha_n is going back and forth between -pi and pi (plus some initial phase 
> offset), so fDTs * cos(alpha_n), the normalised Doppler Frequency, follows 
> this U-distribution.
> 
> This has the advantage that you can start the block once and your results 
> will converge to the mean. (Otherwise, you would have to do a lot of 
> repetitions to get a lot of random initialisations.)
> 
> What I don’t get (and what I asked in the other thread) is why this is 
> multiplied with d_m. I think that, per sample, the current Doppler Frequency 
> should be used to calculate an incremental angle to the previous value.
> 
> (I guess the sincostable is just a lookup table for sin and cos values for 
> speed optimisation.)
> 
> I hope that didn’t confuse even more...
> 
> Best,
> Bastian
> 
> 
> 
>> On 22 Feb 2016, at 06:41, Nasi > > wrote:
>> 
>> Hello,
>> 
>> The question is about how does the given Doppler shift progress, or how is 
>> the Doppler induced phase shift implemented.
>> 
>> I select a simple frequency selective fading block and feed in it some 
>> gr_complex(1, 0) values. For simplicity I run one fader (num of sinusoids).
>> in file:
>> https://github.com/osh/gnuradio.old/blob/master/gr-channels/lib/flat_fader_impl.cc
>>  
>> 
>>  
>> in the code below,
>> #elif FASTSINCOS == 2
>>  float s_i = 
>> scale_sin*d_table.cos(2*M_PI*d_fDTs*d_m*d_table.cos(alpha_n)+d_psi[n+1]);
>>  float s_q = 
>> scale_sin*d_table.cos(2*M_PI*d_fDTs*d_m*d_table.sin(alpha_n)+d_phi[n+1]);
>>   
>>  #else
>>  d_m shows that the Doppler shift must progress sequencially. However, the 
>> value of "2*M_PI*d_fDTs*d_m*d_table.cos(alpha_n)" as a whole, produces 
>> floating point numbers which results in kind of random values out of 
>> d_table.cos() function in file 
>> https://github.com/osh/gnuradio.old/blob/master/gr-channels/lib/sincostable.h
>>  
>> 
>> 
>> Some more explanation:
>> the value: 2*M_PI*d_fDTs*d_m*d_table.cos(alpha_n) gets in as x below (in 
>> file .../lib/sincostable.h)
>> (((int)(x*d_scale)) + d_sz) % d_sz; - this is a random integer value (may be 
>> not, can you please help me with that?)
>> therefore it returns a random cos value as: return d_cos[idx];
>> 
>> The issue arises when that floating point values inside cos() function is 
>> converted to integers as given above.
>> 
>> Now, my question is, did you do that random phase shift/Doppler shift on 
>> purpose? If yes, what is the reasoning behind that.
>> As far as I know, the Doppler shift should be somehow linear progressive.
>> 
>> -- 
>> NE
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org 
>> 
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio 
>> 

Re: [Discuss-gnuradio] how does Doppler shift increment in flat fading channel GNU radio

[Nasi]

 Hi,

(I was not in the mailing list for a long time) yes, you are right.
d_m is incrementation or index after initialization, which is correct thing 
there. Yes, as you also said that is per sample.
cos(alpha_n) is constant there, I checked that. cos table looks like just 
cosine values, which must be there somehow.

But the value are selected out of cos table kind of randomly. I think there is 
a "bug" in the code. Otherwise, let someone explain it better. The Doppler 
shift cannot jump from sample to sample randomly. If I make a mistake please 
correct it.


P.S.: In matlab that thing is not random. After some samples that changes a 
little bit depending on the max Doppler shift.

-
Nasimi

>Понедельник, 22 февраля 2016, 9:54 -08:00 от Bastian Bloessl 
>:
>
>Hi,
>
>I posted a question about the very same lines of code four days ago, but did 
>not get a reply yet
>
>http://lists.gnu.org/archive/html/discuss-gnuradio/2016-02/msg00254.html
>
>I’m not sure whats going on there, but some wild guesses:
>
>The Doppler Frequency per sinusoid is distributed according to that U-shaped 
>thing you see everywhere.
>Now, instead of rolling the dice once during initialisation and sticking to 
>that Doppler frequency forever, this implementation is doing something like a 
>random walk through the Doppler Spectrum.
>
>alpha_n is going back and forth between -pi and pi (plus some initial phase 
>offset), so fDTs * cos(alpha_n), the normalised Doppler Frequency, follows 
>this U-distribution.
>
>This has the advantage that you can start the block once and your results will 
>converge to the mean. (Otherwise, you would have to do a lot of repetitions to 
>get a lot of random initialisations.)
>
>What I don’t get (and what I asked in the other thread) is why this is 
>multiplied with d_m. I think that, per sample, the current Doppler Frequency 
>should be used to calculate an incremental angle to the previous value.
>
>(I guess the sincostable is just a lookup table for sin and cos values for 
>speed optimisation.)
>
>I hope that didn’t confuse even more...
>
>Best,
>Bastian
>
>
>
>>On 22 Feb 2016, at 06:41, Nasi < nesaz...@mail.ru > wrote:
>>Hello,
>>
>>The question is about how does the given Doppler shift progress, or how is 
>>the Doppler induced phase shift implemented.
>>
>>I select a simple frequency selective fading block and feed in it some 
>>gr_complex(1, 0) values. For simplicity I run one fader (num of sinusoids).
>>in file:
>>https://github.com/osh/gnuradio.old/blob/master/gr-channels/lib/flat_fader_impl.cc
>>  
>>in the code below,
>># elif FASTSINCOS == 2
>>  float s_i = scale_sin*d_table. cos ( 2 *M_PI*d_fDTs*d_m*d_table. cos 
>>(alpha_n)+d_psi[n+ 1 ]);
>>  float s_q = scale_sin*d_table. cos ( 2 *M_PI*d_fDTs*d_m*d_table. sin 
>>(alpha_n)+d_phi[n+ 1 ]);
>>   
>>  # else   d_m shows that the Doppler shift must progress sequencially. 
>>However, the value of " 2 *M_PI*d_fDTs*d_m*d_table. cos (alpha_n) " as a 
>>whole, produces floating point numbers which results in kind of random values 
>>out of  d_table. cos () function in file 
>>https://github.com/osh/gnuradio.old/blob/master/gr-channels/lib/sincostable.h
>>
>>Some more explanation:
>>the value:  2 *M_PI*d_fDTs*d_m*d_table. cos (alpha_n) gets in as x below (in 
>>file .../ lib/sincostable.h )
>>((( int )(x*d_scale)) + d_sz) % d_sz; - this is a random integer value (may 
>>be not, can you please help me with that?)
>>therefore it returns a random cos value as: return d_cos[idx];
>>
>>The issue arises when that floating point values inside cos() function is 
>>converted to integers as given above.
>>
>>Now, my question is, did you do that random phase shift/Doppler shift on 
>>purpose? If yes, what is the reasoning behind that.
>>As far as I know, the Doppler shift should be somehow linear progressive.
>>
>>-- 
>>NE ___
>>Discuss-gnuradio mailing list
>>Discuss-gnuradio@gnu.org
>>https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>


-- 
NE
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] how does Doppler shift increment in flat fading channel GNU radio

[Bastian Bloessl]

Hi,

I posted a question about the very same lines of code four days ago, but did 
not get a reply yet

http://lists.gnu.org/archive/html/discuss-gnuradio/2016-02/msg00254.html 


I’m not sure whats going on there, but some wild guesses:

The Doppler Frequency per sinusoid is distributed according to that U-shaped 
thing you see everywhere.
Now, instead of rolling the dice once during initialisation and sticking to 
that Doppler frequency forever, this implementation is doing something like a 
random walk through the Doppler Spectrum.

alpha_n is going back and forth between -pi and pi (plus some initial phase 
offset), so fDTs * cos(alpha_n), the normalised Doppler Frequency, follows this 
U-distribution.

This has the advantage that you can start the block once and your results will 
converge to the mean. (Otherwise, you would have to do a lot of repetitions to 
get a lot of random initialisations.)

What I don’t get (and what I asked in the other thread) is why this is 
multiplied with d_m. I think that, per sample, the current Doppler Frequency 
should be used to calculate an incremental angle to the previous value.

(I guess the sincostable is just a lookup table for sin and cos values for 
speed optimisation.)

I hope that didn’t confuse even more...

Best,
Bastian



> On 22 Feb 2016, at 06:41, Nasi  wrote:
> 
> Hello,
> 
> The question is about how does the given Doppler shift progress, or how is 
> the Doppler induced phase shift implemented.
> 
> I select a simple frequency selective fading block and feed in it some 
> gr_complex(1, 0) values. For simplicity I run one fader (num of sinusoids).
> in file:
> https://github.com/osh/gnuradio.old/blob/master/gr-channels/lib/flat_fader_impl.cc
>  
> 
>  
> in the code below,
> #elif FASTSINCOS == 2
>   float s_i = 
> scale_sin*d_table.cos(2*M_PI*d_fDTs*d_m*d_table.cos(alpha_n)+d_psi[n+1]);
>   float s_q = 
> scale_sin*d_table.cos(2*M_PI*d_fDTs*d_m*d_table.sin(alpha_n)+d_phi[n+1]);
>
>   #else
>  d_m shows that the Doppler shift must progress sequencially. However, the 
> value of "2*M_PI*d_fDTs*d_m*d_table.cos(alpha_n)" as a whole, produces 
> floating point numbers which results in kind of random values out of 
> d_table.cos() function in file 
> https://github.com/osh/gnuradio.old/blob/master/gr-channels/lib/sincostable.h
> 
> Some more explanation:
> the value: 2*M_PI*d_fDTs*d_m*d_table.cos(alpha_n) gets in as x below (in file 
> .../lib/sincostable.h)
> (((int)(x*d_scale)) + d_sz) % d_sz; - this is a random integer value (may be 
> not, can you please help me with that?)
> therefore it returns a random cos value as: return d_cos[idx];
> 
> The issue arises when that floating point values inside cos() function is 
> converted to integers as given above.
> 
> Now, my question is, did you do that random phase shift/Doppler shift on 
> purpose? If yes, what is the reasoning behind that.
> As far as I know, the Doppler shift should be somehow linear progressive.
> 
> -- 
> NE
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio