On 2014-11-29 12:49, Isen I-Chun Chao wrote:
The long preamble should be the 320-sample one. right?
The short preamble is 160 samples (a 16-sample pattern that repeats 10 times) and the long preamble is 160 samples (a 64-sample pattern that repeats 2.5 times)
you might want to have a look at this paper for those questions http://www.ccs-labs.org/bib/bloessl2013ofdmreceiver/ Best, Bastian
/Best Regards, Isen I-Chun Chao/ On Sat, Nov 29, 2014 at 6:39 AM, Bastian Bloessl <bloe...@ccs-labs.org <mailto:bloe...@ccs-labs.org>> wrote: On 2014-11-29 12:34, Isen I-Chun Chao wrote: Okay, I got it. One more quick question. I have been pretty confused about what the sync long and sync short are, respectively, responsible for? Sync short is for frame detection and searches for the cyclic pattern of the short preamble (autocorrelation). Once a (potential) frame is detected, sync long correlates sync_length samples with the long preamble and searches for peaks to align OFDM symbols. Thanks. /Best Regards, Isen I-Chun Chao/ On Sat, Nov 29, 2014 at 6:29 AM, Bastian Bloessl <bloe...@ccs-labs.org <mailto:bloe...@ccs-labs.org> <mailto:bloe...@ccs-labs.org <mailto:bloe...@ccs-labs.org>>> wrote: On 2014-11-29 12:28, Isen I-Chun Chao wrote: Hi Bastian, Thanks for your reply. The peaks you mentioned is like the correlation result? Yes, exactly /Best Regards, Isen I-Chun Chao/ On Sat, Nov 29, 2014 at 6:21 AM, Bastian Bloessl <bloe...@ccs-labs.org <mailto:bloe...@ccs-labs.org> <mailto:bloe...@ccs-labs.org <mailto:bloe...@ccs-labs.org>> <mailto:bloe...@ccs-labs.org <mailto:bloe...@ccs-labs.org> <mailto:bloe...@ccs-labs.org <mailto:bloe...@ccs-labs.org>>>__> wrote: Hi Isen, On 2014-11-29 07:01, Isen I-Chun Chao wrote: Hi, I am using gr-ieee-802-11 and putting a custom block, which is responsible for adding a 90-sample preamble at the head of incoming sample stream, right after the output of WiFi PHY Hier, as attached figure, generator.png. So the sample stream is changed as attached figure, adding_preamble.png. However, in the case of use of transceiver.grc, I can still successfully decode received data, which is keep printing out "Hello World!". Does anyone know why adding extra samples at the head of transmission samples does not affect the receiving results? Does it because somewhere in Rx side detect the OFDM preamble so the payload can be normally processed without being affecting by the extra samples placed before OFDM preamble? The sync long block does matched filtering with the long preamble and searches for peaks in a configurable window (sync length parameter). Looks like even if you add 90 symbols the peak that the block is looking for is still in the window. Best, Bastian -- Dipl.-Inform. Bastian Bloessl Distributed Embedded Systems University of Paderborn, Germany http://www.ccs-labs.org/~____bloessl/ <http://www.ccs-labs.org/~__bloessl/> <http://www.ccs-labs.org/~__bloessl/ <http://www.ccs-labs.org/~bloessl/>> -- Dipl.-Inform. Bastian Bloessl Distributed Embedded Systems University of Paderborn, Germany http://www.ccs-labs.org/~__bloessl/ <http://www.ccs-labs.org/~bloessl/>
-- Dipl.-Inform. Bastian Bloessl Distributed Embedded Systems University of Paderborn, Germany http://www.ccs-labs.org/~bloessl/ _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
