Re: [Discuss-gnuradio] Equalization using channel estimates

[Johannes Demel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Mohammed,

I forgot to reply to the list in my previous mail, so I do this now.

On 05.02.2014 16:14, Mohammed Karmoose wrote:
> Hi Johannes
> 
> Thank you for your prompt reply. I'm just trying to get my hands
> as dirty as possible with Gnuradio. I'm trying to do some
> pre-equalization at the transmitter side, but right now I'm just
> trying to achieve a unity effective channel response, just to prove
> that I'm able to do something meaningful at the transmitter side.
> 
> I checked with the channel response that the USRPs exhibit at the 
> current setup I'm working on, and it seems that it does not change 
> across a relatively long period of time, so it might seem that this
> kind of equalization is possible. However, I noticed something
> which suggested that there is something "more" than just simply
> estimating the channel taps that is done at the receiver side.
> 
> I simply divide the samples that are transmitted by a constant
> value prior to transmission (I'm not using the channel coefficients
> in anything right now) and see the effective channel response: it
> seems that the effective channel response is reduced by the factor
> I'm dividing by. However, when the factor I'm dividing by is less
> than 0.8 (which means that the effective channel response in this
> case should be magnified), the effective channel response somehow
> is transformed back to the original (unaltered case) channel
> response.
An example flowgraph would be very helpful in this case. Where exactly
do your samples get "transformed back"?

> 
> Does any of that make sense to you? Please tell me if something is
> not clear in the previously mentioned details.
> 
> 
> On Wed, Feb 5, 2014 at 5:04 PM, Johannes Demel
> <address@hidden <mailto:address@hidden>> wrote:
> 
> Hi Mohammed,
> 
> what exactly do you want to achieve? Those channel estimates are 
> usually used to do equalization on the receive side. That's why a 
> system always transmits pilot symbols along with the data symbols. 
> If your system is meant to do some pre-equalization on the
> transmit side, make sure those channel estimates are still valid by
> the time you use them on the transmit side.
> 
>> Are these coefficients valid to use in equalization, i.e., can I 
>> divide the transmitted symbols by the corresponding channel 
>> coefficients, and therefore achieve an almost unity channel
>> taps?
> 
> Those coefficients should be valid. Nevertheless depending on the 
> channel quality and your chosen method of estimation your results
> may vary.
> 
> happy hacking Johannes
> 
> 
> 
> 
> -- *---------------------------------------------------* *Mohammed
> Hassan Karmoose* */Teaching Assistant, Electrical Engineering
> Dept./* */Faculty of Engineering, Alexandria University/* 
> /Al-Horeya Rd, El-Hadara,/ */Alexandria, Egypt - 21544/* */Tel:
> /*/*++203-592-1852*/ | */Fax: /**/++203-592-1853/* */Email: /m
> <mailto:address@hidden>.h.karmoose@ 
> <mailto:address@hidden>ieee.org <http://ieee.org>* */Website:
> /www.mkarmoose.com <http://www.mkarmoose.com/>* /"The people before
> you were ruined because when a noble person amongst them committed
> theft, they would leave him, but if a weak person amongst them
> committed theft, they would execute the legal punishment on him.
> By Allah, were Fatimah, the daughter of Muhammad, to commit the
> theft, I would have //executed the legal punishment on her//.'' -
> Prophet Muhammad (PBUH)/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJS8liXAAoJEO7fmkDsqywMKKsQAJ6nhLqd6UazvRONAl8afe98
uRmyZMJi7ktuaJ6DxMIY02AkLdXtAol60/cgdwmGQbsXuunDcP28HFOSN9JE216R
7zjPjYb58CrzQdzAY1NExDq+RphvCX3GeCExSgvPhZR3TIz3pniEnqpNT/ik42cJ
J1VGlu5nH2cRSov2qliPoFtX3jNeppOirAk51HUOKXe0ATQRTi+lcyFB4GMEuYJ2
6Rq39eVoT30IaZRWVMxdqhwDP2qhMQIXKHx3b7E1lZnjN3fltXaQX7h5ijnCftdh
FnimScpS4P6cXU/tSWRGk+brXLh26BVC+g+zG5BmrrZNuh+eNWtB0CAJjTaRlSre
eUqQAbrpbzh2CkQr9o/Lvbfzu8V6sSAGy9fb25bVLCSckhDoFVCDiuaDD4rC5cJY
BThqsUL9eMh6P2M+XRmTuerOk1u/kcuV7d4HD9nH+6XU3scdGCEgpL5qlcKc670W
9vfbtO5P8KNRE3SnjnLxLC3ERH5FAAyPuHR1DQsSwmrJEB7aYD7Kgl3mCaoTG1b6
gR3ae3D2Y5ppPmmeb42rEvlotJQqCF6CKgzZQo4WChsdEW7q6CbJxruRrBSI9lQi
yLDlvzaHtv+OEUvN1i8GIVvPdf2ZR4Hye9jHtJXW+TBX4qDM1pOSzkat2SkDKXwK
gAz40iS6WFC0ETg3Y8iq
=DRvG
-----END PGP SIGNATURE-----