Hi Tom, Just correct my mail. I retest the case, it is found that my matlab code has some errors which cause this confusion. Sorry for the incorrect result.
On Tue, Apr 3, 2012 at 12:43 AM, Alex Zhang <cingular.a...@gmail.com> wrote: > Hi Tom, > > To dig the details of the current ofdm receiver synchronization, i did > some experiments by the benchmark_rx.py. But I see something strange > regarding the Preamble correlation plateau width, although the data packet > is communicated as expected. > > My command is as: > > ./benchmark_tx.py -f 1.4G --fft 256 --occ 240 --log > ./benchmark_rx.py -f 1.4G --fft 256 --occ 240 --log > > Please see the attached pictures, I analyzed the data file > "ofdm_sync_pn-theta_f.dat" which is generated by ofdm_sync_pn.py. But I > found the plateau width is half of the cp length(128), which is shown in > 1.jpg. > So I continue to analyze the data file "ofdm_sync_pn-input_c.dat" > generated in the same time, by manually doing the correlation on the input > data of the ofdm_sync_pn.py and find that the plateau is correct as > cp_length (128), which is shown in 2.jpg. > So I guess, are there any operations like the decimation to decrease the > sample number by half, when generating the normalized metric for the > preamble correlation plateau in ofdm_sync_pn.py. > > I know it is long time for you to have looked this piece of code. But it > is really appreciated if you can give a help. > > > On Sat, Mar 31, 2012 at 9:36 AM, Tom Rondeau <t...@trondeau.com> wrote: > >> On Tue, Mar 27, 2012 at 10:29 PM, Alex Zhang <cingular.a...@gmail.com> >> wrote: >> > Hi Tom, >> > >> > Thanks for the reply. >> > In the ofdm_sync_pn.py, I see that a matched filter is used, after the >> > timing metric is obtained based on the correlation of the two halves of >> the >> > preamble. I understand this matched filter is trying to find the end of >> the >> > plateau of the metric and get the smooth peak. But I am a little >> confused >> > with the length of this matched filter. >> > In the code, the length of this matched filter is set as equal to >> cp_length. >> > But in T.M.Schmidl's paper(page 1615), the plateau length is equal to >> the >> > cp_length minus the channel impulse response length. I am thinking, >> without >> > counting the channel response length, can we get the peak accurately, >> > especially in multipath environment? >> >> It's been so long since I've looked closely at that. You could be >> right. Test it and see and let us know the results. >> >> Tom >> >> >> >> > On Sun, Mar 25, 2012 at 12:40 PM, Tom Rondeau <t...@trondeau.com> wrote: >> >> >> >> On Sat, Mar 24, 2012 at 8:52 PM, Alex Zhang <cingular.a...@gmail.com> >> >> wrote: >> >> > Hi Gurus, >> >> > >> >> > I just want to make sure how the current gnuradio ofdm exampel is >> >> > doing synchronization. >> >> > According to T. M. Schmidl and D. C. Cox, "Robust Frequency and >> >> > Timing Synchonization for OFDM," IEEE Trans. Communications, vol. >> >> > 45, no. >> >> > 12, 1997. >> >> > When, estimating the carrier frequency offset at the receiver, if the >> >> > phase >> >> > difference between the two halves of the 1st training symbol is >> >> > guaranteed >> >> > to be less than PI, then the frequency offset estimate can derived by >> >> > Phi/(Pi*T). In this situation, the even PN sequencies of the second >> >> > training >> >> > symbol would not be needed. Otherwise, the actual frequency offset >> would >> >> > be >> >> > >> >> > Phi/(Pi*T) + 2*z/T >> >> > and the z can be estimated by some optimization algorithm, using >> both >> >> > of >> >> > the training symbols. Also, the paper mentioned that the odd >> frequencies >> >> > of >> >> > the second training symbol can be used to measure the sub-channels. >> >> > >> >> > However, I find that only one training symbol is generated to act as >> >> > preamble at the ofdm transmitter. And on the receiver, it seems that >> >> > only >> >> > one preamble is used to estimate the timing peak and the frequency >> >> > offset. >> >> > Is the current implementation assuming that the frequency is less >> than >> >> > PI? >> >> > Or anything I missed? >> >> > >> >> > Looking forward to your input! >> >> > -- >> >> > >> >> > Alex, >> >> > Dreams can come true – just believe. >> >> >> >> >> >> Alex, >> >> >> >> Take a look at the presentation we put together here: >> >> http://gnuradio.org/redmine/projects/gnuradio/wiki/Wireless >> >> >> >> It explains the synchronization process. Basically, the single >> >> preamble is made up of two identical sections, so the correlation is >> >> done between those two sections to get the timing and fine frequency >> >> estimate. Since this preamble is known, we also use it to handle the >> >> coarse frequency (number of bins) offset. >> >> >> >> Tom >> > >> > >> > >> > >> > -- >> > >> > Alex, >> > Dreams can come true – just believe. >> > >> > > > > -- > > Alex, > *Dreams can come true – just believe.* > > -- Alex, *Dreams can come true – just believe.*
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
