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?
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.
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.
Hi Bastian,
Thanks for your reply.
The peaks you mentioned is like the correlation result?
Yes, exactly
On 2014-11-29 07:01, Isen I-Chun Chao wrote:
decode received data, which is keep printing out "Hello World!".
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 B.
Distributed Embedded Systems
University of Paderborn, Germany
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.
/Best Regards,
in Rx side detect the OFDM preamble so the payload can
parameter). Looks like even if you add 90 symbols the peak
Distributed Embedded Systems
University of Paderborn, Germany
http://www.ccs-labs.org/~__bloessl/ <http://www.ccs-labs.org/~bloessl/>
–
Dipl.-Inform. Bastian B.
Distributed Embedded Systems
University of Paderborn, Germany
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)
frame is detected, sync long correlates sync_length samples with the
<[email protected] <mailto:[email protected]>
<mailto:[email protected]> <mailto:[email protected]
which is
samples does not affect the receiving results?
block is looking for is still in the window.
http://www.ccs-labs.org/~____bloessl/
http://www.ccs-labs.org/~__bloessl/ <http://www.ccs-labs.org/~bloessl/>
–
Dipl.-Inform. Bastian B.
Distributed Embedded Systems
University of Paderborn, Germany