[prev in list] [next in list] [prev in thread] [next in thread]
List: gnuradio-discuss
Subject: Re: [Discuss-gnuradio] OFDM Packet lost
From: Aditya Dhananjay <aditya () cs ! nyu ! edu>
Date: 2014-01-29 14:45:51
Message-ID: CAEiFAxaGhbn8mPANViZKEBiXx994750oA4HYSfh+L1HmgfKtWg () mail ! gmail ! com
[Download RAW message or body]
Hi Piotr,
I was facing the same issue, and the issue is caused by Schmidl-Cox
sometimes detecting the packet boundaries a little late. This cannot really
be helped, as channel noise may force the correlator to detect a
peak/plateau later than it should. I have found a couple of ways to
overcome this problem:
a) After every packet, send a stream of maybe 10 "0"s. This ensures that
even if one packet is detected a symbol late, the subsequent packet has
enough room to be detected. The way to implement this is by having another
tagged stream of "0"s, the tag being packet_length. At the transmitter
side, pass the symbols from the TX block into one input of a
tagged-stream-mux, and the tagged stream of "0"s into the other input of
the tagged stream mux.
b) In the header-payload demux, 'consume' a few symbols lesser than you
need to. That way, you won't accidentally eat up the peak trigger from the
next packet. As was discussed in a different thread, this is an unclean
solution -- a hack!
Hope that helps, and happy hacking!
Best regards,
Aditya
On Wed, Jan 29, 2014 at 8:24 AM, Piotr Potocki <Piotr.L.Potocki@gmail.com>wrote:
> Hi all,
>
> I am trying to create OFDM transmission on USRP 2. I am using two URSP's
> (XVCR 2450) which are close to each other. To do that I am using Gnu radio
> 3.7.2 with slightly modify OFDM_benchmark_receiver (see img 1) and
> transmitter.
> But the problem is that I am still receiving packet lost around 1.73 - 2.2
> %. Even when I am using direct cable between USRP's the packet lost is the
> same (around 1.73 - 2.0 % newer below). I don't think it can be frequency
> offset (I checked exactly what offset i have and corrected it manually).
> 1) So my first question is how to improve packet lost (my guess is the
> timing synchronization) and is this packet lost a normal thing in this
> scenario (without FEC) ?
> 2) Second question is what methods of timing synchronization (auto
> correlation function, ?) are used in this OFDM example and where to find
> them ?
>
> My specs of system:
> FFT length = 64
> Sample rate = 2M
> Packet length = 40 ( i tried with different packet length and 40 gave the
> best results)
> Modulation = BPSK
> Carrier frequency = 2.4 Ghz
> Occupied carriers = 52
>
> Best regards,
> Piotr Potocki
>
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
[Attachment #3 (text/html)]
<div dir="ltr"><div class="gmail_default" style="font-family:courier \
new,monospace">Hi Piotr,</div><div class="gmail_default" style="font-family:courier \
new,monospace"><br></div><div class="gmail_default" style="font-family:courier \
new,monospace">
I was facing the same issue, and the issue is caused by Schmidl-Cox sometimes \
detecting the packet boundaries a little late. This cannot really be helped, as \
channel noise may force the correlator to detect a peak/plateau later than it should. \
I have found a couple of ways to overcome this problem:</div>
<div class="gmail_default" style="font-family:courier new,monospace"><br></div><div \
class="gmail_default" style="font-family:courier new,monospace">a) After every \
packet, send a stream of maybe 10 "0"s. This ensures that even if one \
packet is detected a symbol late, the subsequent packet has enough room to be \
detected. The way to implement this is by having another tagged stream of \
"0"s, the tag being packet_length. At the transmitter side, pass the \
symbols from the TX block into one input of a tagged-stream-mux, and the tagged \
stream of "0"s into the other input of the tagged stream mux.</div>
<div class="gmail_default" style="font-family:courier new,monospace"><br></div><div \
class="gmail_default" style="font-family:courier new,monospace">b) In the \
header-payload demux, 'consume' a few symbols lesser than you need to. That \
way, you won't accidentally eat up the peak trigger from the next packet. As was \
discussed in a different thread, this is an unclean solution -- a hack!</div>
<div class="gmail_default" style="font-family:courier new,monospace"><br></div><div \
class="gmail_default" style="font-family:courier new,monospace">Hope that helps, and \
happy hacking!</div><div class="gmail_default" style="font-family:courier \
new,monospace">
<br></div><div class="gmail_default" style="font-family:courier new,monospace">Best \
regards,</div><div class="gmail_default" style="font-family:courier \
new,monospace">Aditya</div><div class="gmail_default" style="font-family:courier \
new,monospace">
<br></div><div class="gmail_default" style="font-family:courier \
new,monospace"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On \
Wed, Jan 29, 2014 at 8:24 AM, Piotr Potocki <span dir="ltr"><<a \
href="mailto:Piotr.L.Potocki@gmail.com" \
target="_blank">Piotr.L.Potocki@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div \
dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div>Hi \
all,<br><br></div>I am trying to create OFDM transmission on USRP 2. I am using two \
URSP's (XVCR 2450) which are close to each other. To do that I am using Gnu radio \
3.7.2 with slightly modify OFDM_benchmark_receiver (see img 1) and transmitter. <br>
</div>But the problem is that I am still receiving packet lost around 1.73 - 2.2 %. \
Even when I am using direct cable between USRP's the packet lost is the same \
(around 1.73 - 2.0 % newer below). I don't think it can be frequency offset (I \
checked exactly what offset i have and corrected it manually).<br>
1) So my first question is how to improve packet lost (my guess is the timing \
synchronization) and is this packet lost a normal thing in this scenario (without \
FEC) ?<br></div>2) Second question is what methods of timing synchronization (auto \
correlation function, ?) are used in this OFDM example and where to find them ?<br>
<br></div>My specs of system:<br></div>FFT length = 64<br></div>Sample rate = \
2M<br></div>Packet length = 40 ( i tried with different packet length and 40 gave the \
best results) <br></div>Modulation = BPSK<br></div>Carrier frequency = 2.4 Ghz<br>
</div>Occupied carriers = 52<br> <br></div>Best regards,<br></div>Piotr \
Potocki<br><div><div><div><br><br><br></div></div></div></div> \
<br>_______________________________________________<br> Discuss-gnuradio mailing \
list<br> <a href="mailto:Discuss-gnuradio@gnu.org">Discuss-gnuradio@gnu.org</a><br>
<a href="https://lists.gnu.org/mailman/listinfo/discuss-gnuradio" \
target="_blank">https://lists.gnu.org/mailman/listinfo/discuss-gnuradio</a><br> \
<br></blockquote></div><br></div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic