Forum: GNU Radio larger cyclic prefix in OFDM example degrades performance

Posted by David Andersson (Guest)
on 2012-11-07 03:21
(Received via mailing list)
I've been working with the OFDM examples that come with GNURADIO
(benchmark_tx.py and benchmark_rx.py).  I've noticed that my bit error 
rate
(BER) increases as the length of my cyclic prefix (CP) increases.  This 
is
opposite of what theory predicts, since larger CP decreases inter-symbol
interference.

I googled the issue and found this paper document the same issue (page 
31):
http://upcommons.upc.edu/pfc/bitstream/2099.1/1226...

The paper explains this by saying longer CP adds additional overhead by
making the frames longer, thus leading to worse performance.  I'm having 
a
hard time understanding how this explains a performance increase.  I see
little change in system performance between CP=1 and 128 when monitoring
system resources, and the number of packets received and number of 
correct
packets doesn't change much from run to run.  Just the number of errors 
in
packets that do fail.

I played around with a lot of different input parameters (FFT size, 
tx/rx
gain, occupied tones, bandwidth, etc) but the issue persists.  There's 
also
no direct correlation between these parameters and BER, and all these
parameters can increase the complexity of the system.

I'm using a USRP2 with a xcvr2450 daughterboard and the latest version 
of
GNURADIO as of august (I think 3.6?) on ubuntu.

Has anyone else had this issue?  Any solutions or insight into the 
source
of the problem?

Regards,
Dave.
Posted by Tom Rondeau (Guest)
on 2012-11-07 17:11
(Received via mailing list)
On Tue, Nov 6, 2012 at 9:20 PM, David Andersson <rkdandersson@gmail.com> 
wrote:
> making the frames longer, thus leading to worse performance.  I'm having a
>
> I'm using a USRP2 with a xcvr2450 daughterboard and the latest version of
> GNURADIO as of august (I think 3.6?) on ubuntu.
>
> Has anyone else had this issue?  Any solutions or insight into the source of
> the problem?
>
> Regards,
> Dave.

Hi Dave,

What you'll want to do is take a look at the frequency, phase, and
timing estimates of the receiver over the length of a packet. These
values are estimated once at the beginning of the packet with the
preamble symbols and then held through the rest of the symbols in a
packet. As you make the packet longer, you're more likely to rotate in
phase of slip in time due to small inaccuracies in the estimates.

Tom
Please log in before posting. Registration is free and takes only a minute.
Existing account (Switch to SSL-encrypted connection)
NEW: Do you have a Google/GoogleMail or Yahoo account? No registration required!
Log in with Google account | Log in with Yahoo account
No account? Register here.