# Gr-lte vs gr::digital::ofdm\*

**URL:** <https://www.ruby-forum.com/t/gr-lte-vs-gr-ofdm/242449>\
**Category:** GNU Radio\
**Created:** [June 24, 2015, 5:49pm UTC](https://www.ruby-forum.com/t/gr-lte-vs-gr-ofdm/242449 "2015-06-24T17:49:28Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![Detlef\_R](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/58f4c7/32.png) [@Detlef\_R](https://www.ruby-forum.com/u/Detlef_R)\
**Post date:** [June 24, 2015, 5:49pm UTC](https://www.ruby-forum.com/t/gr-lte-vs-gr-ofdm/242449/1 "2015-06-24T17:49:28Z")

</div>

Hi all,

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?

I have been referencing the receive flowgraph here:  
[https://gnuradio.org/doc/doxygen/page\_ofdm.html](https://gnuradio.org/doc/doxygen/page_ofdm.html)

Thanks for any hints,  
-Doug

---

<div class="post-metadata">

**Author:** ![AndersonS\_Douglas\_J](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/53a042/32.png) [@AndersonS\_Douglas\_J](https://www.ruby-forum.com/u/AndersonS_Douglas_J)\
**Post date:** [June 24, 2015, 6:08pm UTC](https://www.ruby-forum.com/t/gr-lte-vs-gr-ofdm/242449/2 "2015-06-24T18:08:45Z")

</div>

On 24.06.2015 08:48, Anderson, Douglas J. wrote:

> 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

---

<div class="post-metadata">

**Author:** ![AndersonS\_Douglas\_J](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/53a042/32.png) [@AndersonS\_Douglas\_J](https://www.ruby-forum.com/u/AndersonS_Douglas_J)\
**Post date:** [June 25, 2015, 5:17pm UTC](https://www.ruby-forum.com/t/gr-lte-vs-gr-ofdm/242449/3 "2015-06-25T17:17:27Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![AndersonS\_Douglas\_J](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/53a042/32.png) [@AndersonS\_Douglas\_J](https://www.ruby-forum.com/u/AndersonS_Douglas_J)\
**Post date:** [June 29, 2015, 9:05pm UTC](https://www.ruby-forum.com/t/gr-lte-vs-gr-ofdm/242449/4 "2015-06-29T21:05:49Z")

</div>

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”:

([gr-lte/lib/sync\_frequency\_c\_impl.cc at master · kit-cel/gr-lte · GitHub](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(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+danderson=removed\_email\_address@domain.invalid  
[discuss-gnuradio-bounces+danderson=removed\_email\_address@domain.invalid] on behalf  
of Johannes D. [removed\_email\_address@domain.invalid]  
Sent: Thursday, June 25, 2015 9:15 AM  
To: removed\_email\_address@domain.invalid  
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

---

<div class="post-metadata">

**Author:** ![AndersonS\_Douglas\_J](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/53a042/32.png) [@AndersonS\_Douglas\_J](https://www.ruby-forum.com/u/AndersonS_Douglas_J)\
**Post date:** [June 30, 2015, 12:26am UTC](https://www.ruby-forum.com/t/gr-lte-vs-gr-ofdm/242449/5 "2015-06-30T00:26:13Z")

</div>

On Mon, Jun 29, 2015 at 2:19 PM, Anderson, Douglas J.  
[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> [https://github.com/kit-cel/gr-lte/blob/master/docs/lte\_cp\_ffo\_sync\_hier.grc.png](https://github.com/kit-cel/gr-lte/blob/master/docs/lte_cp_ffo_sync_hier.grc.png)
> 
> If I understand that right, it’s saying that I actually don’t need to retune  
> the USRP, it just pumps samples into the input of the FFO Sync hier block,  
> then the sync\_frequency\_c blocks mixes in a CW signal at the correct  
> frequency to adjust the samples from the USRP. Yes?

Yes. You can perform frequency offset tracking and compensation  
entirely on the host. There are some overhead advantages using DSP  
tuning on the FPGA for the translation, but mathematically you should  
end up with the same result.

-TT

---

<div class="post-metadata">

**Author:** ![AndersonS\_Douglas\_J](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/53a042/32.png) [@AndersonS\_Douglas\_J](https://www.ruby-forum.com/u/AndersonS_Douglas_J)\
**Post date:** [June 29, 2015, 11:20pm UTC](https://www.ruby-forum.com/t/gr-lte-vs-gr-ofdm/242449/6 "2015-06-29T23:20:46Z")

</div>

Okay I just ran into this link:

> <https://github.com/kit-cel/gr-lte/blob/master/docs/lte_cp_ffo_sync_hier.grc.png>

If I understand that right, it’s saying that I actually don’t need to  
retune the USRP, it just pumps samples into the input of the FFO Sync  
hier block, then the sync\_frequency\_c blocks mixes in a CW signal at the  
correct frequency to adjust the samples from the USRP. Yes?

-Doug

* * *

From: discuss-gnuradio-bounces+danderson=removed\_email\_address@domain.invalid  
[discuss-gnuradio-bounces+danderson=removed\_email\_address@domain.invalid] on behalf  
of Anderson, Douglas J. [removed\_email\_address@domain.invalid]  
Sent: Monday, June 29, 2015 1:04 PM  
To: Johannes D.; removed\_email\_address@domain.invalid  
Subject: Re: [Discuss-gnuradio] gr-lte vs gr::digital::ofdm\*

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”:

([gr-lte/lib/sync\_frequency\_c\_impl.cc at master · kit-cel/gr-lte · GitHub](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(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+danderson=removed\_email\_address@domain.invalid  
[discuss-gnuradio-bounces+danderson=removed\_email\_address@domain.invalid] on behalf  
of Johannes D. [removed\_email\_address@domain.invalid]  
Sent: Thursday, June 25, 2015 9:15 AM  
To: removed\_email\_address@domain.invalid  
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