Hi,

> On 22 Feb 2016, at 10:54, Nasi <[email protected]> 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
 
<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 
> <[email protected]>:
> 
> 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 
> <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 <[email protected] 
>> <x-msg://e.mail.ru/compose/?mailto=mailto%[email protected]>> 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
>>  
>> <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
>>  
>> <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
>> [email protected] 
>> <x-msg://e.mail.ru/compose/?mailto=mailto%3adiscuss%[email protected]>
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio 
>> <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
> 
> 
> 
> -- 
> NE

_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to