Cyclic Prefixer Rolloff Samples

Hi,

I wonder why the OFDM Cyclic Prefixer uses the samples at the beginning
of the symbol to calculate the roll off. I would have expected that the
samples from the end of the previous symbol are used. So something like
this:

https://github.com/bastibl/gnuradio/commit/1a1f0f92cedac90ccadf5e42f4e09b3188b04352

But since also the unit test expects the samples from the start of the
symbol I might get the concept totally wrong.

Best,
Bastian

Dipl.-Inform. Bastian B.
Institute of Computer Science
University of Innsbruck, Austria
Phone: +43 512 507-53288 / Fax: -53079
http://ccs.uibk.ac.at/~bloessl/

On Fri, Aug 23, 2013 at 10:10:13AM +0200, Bastian B. wrote:

I wonder why the OFDM Cyclic Prefixer uses the samples at the
beginning of the symbol to calculate the roll off. I would have
expected that the samples from the end of the previous symbol are
used. So something like this:

https://github.com/bastibl/gnuradio/commit/1a1f0f92cedac90ccadf5e42f4e09b3188b04352

But since also the unit test expects the samples from the start of
the symbol I might get the concept totally wrong.

First:
I’m not saying there’s definitely no bug in that code–checking that has
been high on my priority list. Just not high enough :slight_smile:

That said, the samples can’t be from the end of the previous symbol, as
that would actually shorten the OFDM symbol duration. You’re copying the
last few samples of the OFDM symbol, right?

Think of it a bit like a filter. We start with rectangular pulse shapes,
and OFDM symbols have length T (or N samples), including the cyclic
prefix.

Now we want the same thing, but with pulse shaping. We cannot simply
change the duration of the OFDM symbol (well, we could, but we want a
fair comparison). If we’d be filtering the OFDM symbol in time domain,
we’d expect the delay line of the filter to trail the output, adding a
few samples to the OFDM symbol (but they would leak into the next
symbol, which means the OFDM symbol spacing is still T).

Only we’re not filtering–we’re adding a tapering window in time domain.
At the beginning of the symbol, we can simply multiply the samples with
the up-ramp of our tapering window (we use a raised cosine flank).

So what happens at the end? We could do the same: Multiply the last few
samples with the down-ramp. But then we’re simply throwing away energy.
It would be much nicer if the down-ramp came after the symbol, during
the up-ramp of the following symbol. This is achieved by adding samples
from the beginning of the symbol (think of it as a “cyclic postfix”) and
multiply those with the down-ramp of the tapering window.

In fact, this cyclic postfix is the only correct continuation of the
OFDM symbol, because of continuous phase. It looks like your solution
does not have continuous phase.

MB

PS: Do you have a copy of Nachrichtenübertragung (Kammeyer)? He explains
it quite well in Chapter 16.4.


Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin B.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

On 08/23/2013 11:35 AM, Martin B. (CEL) wrote:

On Fri, Aug 23, 2013 at 10:10:13AM +0200, Bastian B. wrote:

I wonder why the OFDM Cyclic Prefixer uses the samples at the
beginning of the symbol to calculate the roll off. I would have
expected that the samples from the end of the previous symbol are
used. So something like this:

https://github.com/bastibl/gnuradio/commit/1a1f0f92cedac90ccadf5e42f4e09b3188b04352

But since also the unit test expects the samples from the start of
the symbol I might get the concept totally wrong.

Only we’re not filtering–we’re adding a tapering window in time domain.
At the beginning of the symbol, we can simply multiply the samples with
the up-ramp of our tapering window (we use a raised cosine flank).

So what happens at the end? We could do the same: Multiply the last few
samples with the down-ramp. But then we’re simply throwing away energy.
It would be much nicer if the down-ramp came after the symbol, during
the up-ramp of the following symbol. This is achieved by adding samples
from the beginning of the symbol (think of it as a “cyclic postfix”) and
multiply those with the down-ramp of the tapering window.

Ah OK, I see, taking the samples from the end is indeed stupid -.-
Thanks for your explanation!

On Fri, Aug 23, 2013 at 01:50:14PM +0200, Bastian B. wrote:

Ah OK, I see, taking the samples from the end is indeed stupid -.-
Thanks for your explanation!

Hi Bastian,

just a quick follow-up: Did you have any problems with the rolloff
spectrum, or what caused you to change the code?
I checked the output, and it seemed correct–although I didn’t
have the theoretical values here to compare the results to those.

MB


Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin B.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

Hi Martin,

On 08/30/2013 10:18 AM, Martin B. (CEL) wrote:

have the theoretical values here to compare the results to those.
I am currently measuring the packet error rate of a transmitter that
uses the Cyclic Prefixer block. I experienced some strange effects that
I could not explain and thus looked at all blocks again.
Somehow I thought rolloff -> use samples from the end which is stupid as
you pointed out :slight_smile:
So no, everything seams to work now.

Thanks for your help!
Bastian