OFDM Packet lost

GNU Radio
1

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

2

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