Martin, Thank you for your reply. Please, check my replies below.
>> Mohammed, >> >> you should also check the new OFDM implementation (see >> examples/ofdm/rx_ofdm.grc and python/digital/ofdm_txrx.py). Much more >> modular. >> >> On Wed, Aug 21, 2013 at 11:33:26AM +0200, Mohammed Karmoose wrote: >> > However, there are two differences in the implementation in relation to this >> > equation: 1) the block computes the inverse of the channel coefficient >> > (d_known_symbol/symbol), and 2) there is a frequency compensation term >> > (coasre_freq_comp) which basically rotates the complex samples by phase >> > corresponding to the frequency deviation and obtained via the preceding sync >> > block. One final note is that channel coefficient is obtained in every other >> > tab, and the coefficient in the inter-taps are obtained via linear >> > interpolation of the acquired channels. >> > >> > >> > Now, my questions are as follows: >> > >> > >> > 1) Does this explanation seems correct? >> >> Hm... coarse freq compensation deals with freq. offsets larger than one >> sub-carrier spacing. Interpolation is done in frequency direction (the >> Schmidl & Cox sync algo requires double sub-carrier spacing on the sync >> symbol). >> >> > 2) By modifying the VERBOSE variable to be equal to 1 in >> > digital_ofdm_frame_acquisition.cc, the block also plots the estimated channel >> > coefficients in the following order: transmitted symbol --> known symbol --> >> > estimated channel inverse --> output). I noticed that when using a file source/ >> > sink to store/receive packets from OFDM benchmark transmitter and receiver, the >> > channel coefficients are still not equal to 1, despite the fact that no receive >> > noise nor wireless fading occurs. What do these coefficients represent? >> >> Most likely phase rotation due to cyclic prefix and timing errors. Have >> you checked the magnitude? It's probably 1. I checked, and it was not 1. I can't seem to find a pattern in the obtained numbers. >> >> > 3) Are the obtained coefficients eligible to be used in further precoding of >> > transmitted packets, assuming that the channel between Tx/Rx is reciprocal, and >> > that a receiver can switch roles with the transmitter? >> >> That's more of a signal processing question, and as such the (annoying) >> answer is: Depends on your application. Are you attempting some kind of >> waterfilling algorithm? In any case, discard the phase before you do >> so, and make sure you have some kind of limiter. The main idea was to perform cooperative beamforming in order to null out transmission at certain locations. Based on the acquired channel estimates, a precoding matrix can be obtained to cancel the sum of transmitted signals at certain receiving nodes. However, a precise estimate of the channel coefficients (magnitude and phase) should be obtained. Therefore, I cannot simply discard the phase part. Is there some sort of uncompensated phase ambiguity in the hardware of the used USRP nodes? >> >> MB >> >> -- >> Karlsruhe Institute of Technology (KIT) >> Communications Engineering Lab (CEL) >> >> Dipl.-Ing. Martin Braun >> Research Associate >> >> Kaiserstra?e 12 >> Building 05.01 >> 76131 Karlsruhe >> >> Phone: +49 721 608-43790 >> Fax: +49 721 608-46071 >> www.cel.kit.edu <http://www.cel.kit.edu/> >> KIT -- University of the State of Baden-W?rttemberg and >> National Laboratory of the Helmholtz Association -- *---------------------------------------------------* *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 <firesit...@hotmail.com>_h_karmoose@a <h.karmo...@gmail.com> lexu.edu.eg*
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
