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

GNU Radio
1

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

Thanks for any hints,
-Doug

2

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

3

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

4

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)

// The next line does the fancy stuff → calculate the frequency offset.
float f_off = arg(corr_val[pos]) *
float(float(d_samp_rate)/(2M_PIfloat(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)/(2M_PIfloat(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. [[email protected]]
Sent: Thursday, June 25, 2015 9:15 AM
To: [email protected]
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

5

On Mon, Jun 29, 2015 at 2:19 PM, Anderson, Douglas J.
[email protected] wrote:

gr-lte/docs/lte_cp_ffo_sync_hier.grc.png at master · kit-cel/gr-lte · GitHub

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

6

Okay I just ran into this link:

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. [[email protected]]
Sent: Monday, June 29, 2015 1:04 PM
To: Johannes D.; [email protected]
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)

// The next line does the fancy stuff → calculate the frequency offset.
float f_off = arg(corr_val[pos]) *
float(float(d_samp_rate)/(2M_PIfloat(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)/(2M_PIfloat(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. [[email protected]]
Sent: Thursday, June 25, 2015 9:15 AM
To: [email protected]
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