Re: [Discuss-gnuradio] gr-lte vs gr::digital::ofdm*

[Anderson, Douglas J.]

Johannes,

I really appreciate the response, I know you're busy with your SOCIS project.

I'm actually struggling with sync_freq_c_impl.cc, the CP-based FFO sync block.

I've tried to do some reading on FFO techniques, but I'm kind of spinning my tires.

I've modified the block to take a usrp_source pointer, but I'm struggling to understand "the fancy stuff":

(https://github.com/kit-cel/gr-lte/blob/master/lib/sync_frequency_c_impl.cc#L157)

// The next line does the fancy stuff -> calculate the frequency offset.
float f_off = arg(corr_val[pos]) * float(float(d_samp_rate)/(2*M_PI*float(d_fftl) ) );
d_f_av=d_f_av - (0.01 * f_off);

//f_vec.push_back(d_f_av);

(*d_sig).set_frequency((-1)*double(d_f_av) );

So right now I have something like this:

// The next line does the fancy stuff -> calculate the frequency offset.
float phase = std::arg(corr_val[pos]);
float f_off = phase * float(float(d_samp_rate)/(2*M_PI*float(d_fftl) ) );
d_f_av = d_f_av - (0.01 * f_off);

float new_tune_freq = -1 * static_cast<float>(d_f_av);
printf("%s tuning new frequency: %f, LO offset: %f\n", name().c_str(), new_tune_freq, d_lo_offset);

::uhd::tune_request_t tune_req(new_tune_freq, d_lo_offset);
d_tune_result = d_usrp->set_center_freq(tune_req);

Obviously I should be using DSP-only tuning, but right now my confusion is in the value I'm getting for "new_tune_freq". I'm getting lines like this:

sync_frequency_c tuning new frequency: -289.257874, LO offset: 7680000.000000
sync_frequency_c tuning new frequency: -296.508209, LO offset: 7680000.000000
sync_frequency_c tuning new frequency: -303.749878, LO offset: 7680000.000000

Goes up by about 7 hertz (?) each time. Is this an offset from my original tuned frequency (~751000000 Hz) or what? Just not sure how to use this.

Any help/hints/pointers-to-required-reading much appreciated.

-Doug
________________________________________
From: discuss-gnuradio-bounces+address@hidden [discuss-gnuradio-bounces+address@hidden on behalf of Johannes Demel address@hidden
Sent: Thursday, June 25, 2015 9:15 AM
To: address@hidden
Subject: Re: [Discuss-gnuradio] gr-lte vs gr::digital::ofdm*

Hey Doug,

there are a few differences between gr-ofdm and gr-lte. When I started
the project, gr-ofdm wasn't available. Later on I tried to use an API
as similar as possible to gr-ofdm. Though, gr-lte is designed for FDD
mode. That being said, it is quite a difference to gr-ofdm which is
primarily designed for bursty transmissions.
Also the LTE standard includes a few tricky parts. Those include
different CP lengths in every slot, different sync symbols which carry
further system information and dependencies between those parts. e.g.
you need to detect the correct PSS symbol first in order to be able to
do anything useful with the SSS. Also, there are always 2 different
SSS symbols depending on the position within each frame. And their
position in a frame is not right at the beginning of a frame.
If you have specific questions about parts of the flowgraph, just ask.

Cheers
Johannes

On 24.06.2015 18:07, Martin Braun wrote:
> On 24.06.2015 08:48, Anderson, Douglas J. wrote:
>> Lately I've been working with gr-lte and trying to use some of
>> those blocks in my own application (not grc).
>>
>> I'm still in the learning phase about ofdm/lte, and I'm
>> struggling with the lack of documentation or comments in gr-lte.
>>
>> I think I would prefer to use GNU Radio's built-in OFDM blocks
>> for time/freq sync, CP removal, etc, and then lean on gr-lte
>> blocks for decode/unpack operations.
>>
>> My question is, is that practical? gr-lte uses a flowgraph like:
>>
>> source -> cp-based timing sync -> lte PSS sync -> cp-based freq
>> sync -> LTE SSS sync -> lte esimator -> decode stuff...
>>
>> Are the gr::digital::ofdm* blocks too generic to understand
>> things like LTE's primary and secondary sync symbols?
>
> Hi Doug,
>
> that's a big part of it. However, another part was that Johannes
> was writing gr-lte while the OFDM subsystem was still maturing. I'm
> sure at this point we could achieve more synergy between the
> projects.
>
> Johannes hopefully has more insight he can provide.
>
> Cheers, M
>
> _______________________________________________ Discuss-gnuradio
> mailing list address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>

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