Gr-lte chanel estimation

[musicdenotation]

Hi all,

I’m working at putting together a flowgraph based on gr-lte.

For the channel estimator hier block [1], it looks like there are two RS
map generators, one for each of 2 “antenna ports”.

I only have one antenna connected to my USRP N210. Is this a problem? Do
I still use 2 RS map generators with antenna port 0 and 1?

-Doug

[1]
https://raw.githubusercontent.com/kit-cel/gr-lte/master/docs/lte_estimator_hier.grc.png

[AndersonS_Douglas_J]

Hey Doug,

This particular part of the flowgraph deals with reception of a 2
antenna transmitter. That implies that an Alamouti code is applied
before transmission. Thus, for correct reception, it is necessary to
perform the inverse Alamouti code operation. This is generally called
Precoding. For data channels, some other schemes are used as well.
They all require to do an inverse operation. So, the flowgraph does
channel estimation for all antennas. Also, RS symbols are transmitted
differently for each antenna layer.
Without a second receiver antenna, this whole channel estimation,
precoding thing does not result in better reception. But you could use
a B210 or a similar device which offers to RX channels in order to
exploit this extra diversity.
Hope that sheds some light on why and how things are done. Also let me
know about specifics which are unclear in those blocks. So I’ll add
some doc.

Cheers
Johannes

[AndersonS_Douglas_J]

Thanks Johannes,

At some point I’d like to pick up a B210 and try out the MIMO flowgraph,
but for now I’m stuck with an N210.

So what I’ve got now is going straight from the LTE OFDM hier block into
Decode PBCH hier block.

I’ve run into just a couple snags in the PBCH hier block.

First one should be pretty easy for you: a couple of the blocks ask for
input “rxant”, and the pre-decoder asks for both rxant and N_ant. I
scanned the source and looks like “1” will be an okay value for both,
but just out of curiosity, what is actual different between rxant and
N_ant? I’m assuming one is the total number of antennas being used, and
one is the actual antenna being fed to that block, but it’s a little
unclear by the name of the variables which is which.

Second issue is this: in your example flowgraph [1], you show QPSK soft
demod taking a vector of 240 complex, and that block produces an output
vector 2x the input vector length, so 480 floats [2].

The next block that you show in the flowgraph is the PBCH descambler,
which takes 1920 floats, so it’s expecting 4 rather than 2 vectors from
QPSK soft demod.

I just wanted to double check with you that changing the vlen2 to
vlen4 throughout qpsk_soft_demod will be the appropriate fix for this,
or if there’s some subtlety I’m missing.

Again, thanks for taking the time to help me understand gr-lte, it’s
really impressive.

-Doug

[1]
https://raw.githubusercontent.com/kit-cel/gr-lte/master/docs/decode_pbch_37.grc.png
[2]
https://github.com/kit-cel/gr-lte/blob/master/lib/qpsk_soft_demod_vcvf_impl.cc#L48
[3]
https://github.com/kit-cel/gr-lte/blob/master/lib/pbch_descrambler_vfvf_impl.cc#L48

---

From: [email protected]invalid
[[email protected]invalid] on behalf
of Johannes D. [[email protected]]
Sent: Thursday, July 02, 2015 1:22 AM
To: [email protected]
Subject: Re: [Discuss-gnuradio] gr-lte chanel estimation

Hey Doug,

This particular part of the flowgraph deals with reception of a 2
antenna transmitter. That implies that an Alamouti code is applied
before transmission. Thus, for correct reception, it is necessary to
perform the inverse Alamouti code operation. This is generally called
Precoding. For data channels, some other schemes are used as well.
They all require to do an inverse operation. So, the flowgraph does
channel estimation for all antennas. Also, RS symbols are transmitted
differently for each antenna layer.
Without a second receiver antenna, this whole channel estimation,
precoding thing does not result in better reception. But you could use
a B210 or a similar device which offers to RX channels in order to
exploit this extra diversity.
Hope that sheds some light on why and how things are done. Also let me
know about specifics which are unclear in those blocks. So I’ll add
some doc.

Cheers
Johannes

On 01.07.2015 23:16, Anderson, Douglas J. wrote:

-Doug

[1]

https://raw.githubusercontent.com/kit-cel/gr-lte/master/docs/lte_estimator_hier.grc.png

---

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

[AndersonS_Douglas_J]

Hey Doug,

First one should be pretty easy for you: a couple of the blocks ask
for input “rxant”, and the pre-decoder asks for both rxant and
N_ant. I scanned the source and looks like “1” will be an okay
value for both, but just out of curiosity, what is actual different
between rxant and N_ant? I’m assuming one is the total number of
antennas being used, and one is the actual antenna being fed to
that block, but it’s a little unclear by the name of the variables
which is which.
Name choice was probably suboptimal here. ‘rxant’ represents the
number of actually used antennas. It was added after multi antenna
support was added. ‘N_ant’ represents the system configuration. Say,
the system is supposed to work with 2x2 MIMO, then N_ant=2.

Second issue is this: in your example flowgraph [1], you show QPSK
soft demod taking a vector of 240 complex, and that block produces
an output vector 2x the input vector length, so 480 floats [2].
The blocks are already configured correctly. PBCH descrambler is a
hier block. First thing it does is repeat every vector of size 480
four times and then process a vector of size 1920.
It is very specific to the LTE PBCH. PBCH is spread over 4 frames but
should be decodable with just one frame. In order to do correct
descrambling, this repetition and descrambling scheme must be applied.
Afterwards you can detect the 2 LSB of a frame number by the position
the correctly decoded PBCH frame had.

Hope that helps

Cheers
Johannes