# Gr-lte chanel estimation **URL:** \ **Category:** GNU Radio\ **Created:** [July 1, 2015, 11:18pm UTC](https://www.ruby-forum.com/t/gr-lte-chanel-estimation/242547 "2015-07-01T23:18:09Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![musicdenotation](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/ea666f/32.png) [@musicdenotation](https://www.ruby-forum.com/u/musicdenotation)\ **Post date:** [July 1, 2015, 11:18pm UTC](https://www.ruby-forum.com/t/gr-lte-chanel-estimation/242547/1 "2015-07-01T23:18:09Z")
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) ](https://raw.githubusercontent.com/kit-cel/gr-lte/master/docs/lte_estimator_hier.grc.png) ---
**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:** [July 2, 2015, 9:24am UTC](https://www.ruby-forum.com/t/gr-lte-chanel-estimation/242547/2 "2015-07-02T09:24:31Z")
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 ---
**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:** [July 2, 2015, 8:49pm UTC](https://www.ruby-forum.com/t/gr-lte-chanel-estimation/242547/3 "2015-07-02T20:49:15Z")
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 vlen_2 to vlen_4 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) ](https://raw.githubusercontent.com/kit-cel/gr-lte/master/docs/decode_pbch_37.grc.png) [2] > [3] > * * * From: [discuss-gnuradio-bounces+danderson=removed\_email\_address@domain.invalid](mailto: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, July 02, 2015 1:22 AM To: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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) ](https://raw.githubusercontent.com/kit-cel/gr-lte/master/docs/lte_estimator_hier.grc.png) > * * * Discuss-gnuradio mailing list [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) > **[Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio)** ---
**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:** [July 3, 2015, 2:25pm UTC](https://www.ruby-forum.com/t/gr-lte-chanel-estimation/242547/4 "2015-07-03T14:25:34Z")
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