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.
on 2012-11-07 03:21
on 2012-11-07 17:11
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
Log in with Google account | Log in with Yahoo account
No account? Register here.