discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] how does Doppler shift increment in flat fading c


From: Bastian Bloessl
Subject: Re: [Discuss-gnuradio] how does Doppler shift increment in flat fading channel GNU radio
Date: Mon, 22 Feb 2016 09:54:01 -0800

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 <address@hidden> 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
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


reply via email to

[Prev in Thread] Current Thread [Next in Thread]