OFDM Example, 'Noisy' final symbol

GNU Radio
1

Hi Martin, All,

Has anyone noticed that the final symbol of any burst (no matter how
many packets in a transmission) appears slightly ‘noisy’ in the OFDM
example code? Is it something to do with my set-up?

I attach a picture of the eq’d FD constellation when I send two packet:
a) the first packet, b) the second packet (excluding the final (16th)
symbol), and c) second packet (with all symbols)

Is it to do with sample alignment/timing error? I have tried sliding the
samples passed to the FFT at the receiver, moving the window backwards
and forwards and can’t get a better result…

DH

NOTE: The information in this email and any attachments may be
confidential and/or legally privileged. This message may be read, copied
and used only by the intended recipient. If you are not the intended
recipient, please destroy this message, delete any copies held on your
system and notify the sender immediately.

Toshiba Research Europe Limited, registered in England and Wales
(2519556). Registered Office 208 Cambridge Science Park, Milton Road,
Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl

2

On 30.04.2014 11:51, David Halls wrote:

Is it to do with sample alignment/timing error? I have tried sliding the
samples passed to the FFT at the receiver, moving the window backwards
and forwards and can’t get a better result…

This was my first thought when I read the subject line… where are you
getting symbols? Before the equalizer? And is this OTA, or simulated?

Really, all OFDM symbols should be equally noisy. A timing offset will
normally only make the acquisition start somewhere between start and end
of the cyclic prefix. So, I’m unsure what this is without any further
analysis.

Martin

3

Hi Martin,

This is OTA or over a cable, 2.48GHz using the N210 with XCVR2450. The
results I sent are over a cable, and the results I sent are post
equalizer.

It is only the final symbol of a burst, not the final symbol of each
packet.

I agree they should all be equally noisy, and I am certain it’s not
‘noise’ as such.

I thought if the timing window is too late, then some TD samples for the
final symbol will be included in the FFT that are just noise. I have
stored the TD samples and manually performed FFT and eq’n and shifting
the window of samples to pass to the FFT (either forwards or backwards)
by up 16 samples does not help.

You have never noticed this happen?

DH

From: Martin B. [[email protected]]
Sent: 30 April 2014 12:07
To: David Halls; [email protected]
Subject: Re: OFDM Example, ‘Noisy’ final symbol

On 30.04.2014 11:51, David Halls wrote:

Is it to do with sample alignment/timing error? I have tried sliding the
samples passed to the FFT at the receiver, moving the window backwards
and forwards and can’t get a better result…

This was my first thought when I read the subject line… where are you
getting symbols? Before the equalizer? And is this OTA, or simulated?

Really, all OFDM symbols should be equally noisy. A timing offset will
normally only make the acquisition start somewhere between start and end
of the cyclic prefix. So, I’m unsure what this is without any further
analysis.

Martin

NOTE: The information in this email and any attachments may be
confidential and/or legally privileged. This message may be read, copied
and used only by the intended recipient. If you are not the intended
recipient, please destroy this message, delete any copies held on your
system and notify the sender immediately.

Toshiba Research Europe Limited, registered in England and Wales
(2519556). Registered Office 208 Cambridge Science Park, Milton Road,
Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl

4

On 30.04.2014 13:14, David Halls wrote:

Hi Martin,

This is OTA or over a cable, 2.48GHz using the N210 with XCVR2450. The
results I sent are over a cable, and the results I sent are post equalizer.

Which equalizer are you using? A custom one? Those in GNU Radio aren’t
fantastic, and they don’t output soft info.

It is only the final symbol of a burst, not the final symbol of each packet.

So what you’re saying is that when you send several packets directly one
after another, only the last one gets this?

I agree they should all be equally noisy, and I am certain it’s not
‘noise’ as such.

I thought if the timing window is too late, then some TD samples for the
final symbol will be included in the FFT that are just noise. I have
stored the TD samples and manually performed FFT and eq’n and shifting
the window of samples to pass to the FFT (either forwards or backwards)
by up 16 samples does not help.

If the timing window’s late, something’s seriously wrong. It should
always be early.

I currently don’t have a good idea, though.

M

5

Hi Martin,

Setting the rolloff factor in the cyclic prefixer to CP_len (16 samples)
fixes the problem?! Previously I had rolloff = 0.

Any thoughts?

DH

From: Martin B. [[email protected]]
Sent: 30 April 2014 14:56
To: David Halls; [email protected]
Subject: Re: OFDM Example, ‘Noisy’ final symbol

On 30.04.2014 13:14, David Halls wrote:

Hi Martin,

This is OTA or over a cable, 2.48GHz using the N210 with XCVR2450. The
results I sent are over a cable, and the results I sent are post equalizer.

Which equalizer are you using? A custom one? Those in GNU Radio aren’t
fantastic, and they don’t output soft info.

It is only the final symbol of a burst, not the final symbol of each packet.

So what you’re saying is that when you send several packets directly one
after another, only the last one gets this?

I agree they should all be equally noisy, and I am certain it’s not
‘noise’ as such.

I thought if the timing window is too late, then some TD samples for the
final symbol will be included in the FFT that are just noise. I have
stored the TD samples and manually performed FFT and eq’n and shifting
the window of samples to pass to the FFT (either forwards or backwards)
by up 16 samples does not help.

If the timing window’s late, something’s seriously wrong. It should
always be early.

I currently don’t have a good idea, though.

M

On 30.04.2014 11:51, David Halls wrote:

Is it to do with sample alignment/timing error? I have tried sliding the

NOTE: The information in this email and any attachments may be
confidential and/or legally privileged. This message may be read, copied
and used only by the intended recipient. If you are not the intended
recipient, please destroy this message, delete any copies held on your
system and notify the sender immediately.

Toshiba Research Europe Limited, registered in England and Wales
(2519556). Registered Office 208 Cambridge Science Park, Milton Road,
Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl

6

On 30.04.2014 16:03, David Halls wrote:

It’s just the built in basic FDE. Its not awesome, but works well enough
at high SNR.

Hm, the FDE doesn’t output soft info, so I’m stumped why you’d see
anything other than clean constellation points in the first place.

last symbol?

Could the pulse shaping performed in the cyclic prefixer have any effect?!

From your other email, it looks like it does… but you can’t set the
rolloff to the CP length, you need some space for multipath.

Martin

7

Sorry, my fault - I altered the FDE so it does give soft outputs,
because the constellation decoder makes hard decisions anyway - so I
didn’t see the need for it to be done twice.

I forgot i’d made changes :s But now maybe I understand why people
haven’t seen this issue - because they have never looked at the soft
outputs of the FDE!!

I am not quite clear how the pulse shaping works, it seems to extend
each packet by rolloff_len/2 samples, it works out the flanks by

for (int i = 1; i < d_rolloff_len; i++) {
d_up_flank[i-1] = 0.5 * (1 + cos(M_PI * i/rolloff_len -
M_PI));
d_down_flank[i-1] = 0.5 * (1 + cos(M_PI *
(rolloff_len-i)/rolloff_len - M_PI));
}

Which makes sense…

then applies using

    if (d_rolloff_len) {
      for (int i = 0; i < d_rolloff_len-1; i++) {
        out[i] = out[i] * d_up_flank[i] + d_delay_line[i];
        d_delay_line[i] = in[i] * d_down_flank[i];
      }
    }

Is it extending the symbol and then shaping? Not sure I understand why
each packet is extended by rolloff_len/2, not each symbol.

Is pulse shaping applied in the USRP, and can this be controlled from
USRP_sink?

Phew!

DH

From: Martin B. [[email protected]]
Sent: 30 April 2014 15:56
To: David Halls; [email protected]
Subject: Re: OFDM Example, ‘Noisy’ final symbol

On 30.04.2014 16:03, David Halls wrote:

It’s just the built in basic FDE. Its not awesome, but works well enough
at high SNR.

Hm, the FDE doesn’t output soft info, so I’m stumped why you’d see
anything other than clean constellation points in the first place.

last symbol?

Could the pulse shaping performed in the cyclic prefixer have any effect?!

From your other email, it looks like it does… but you can’t set the
rolloff to the CP length, you need some space for multipath.

Martin

NOTE: The information in this email and any attachments may be
confidential and/or legally privileged. This message may be read, copied
and used only by the intended recipient. If you are not the intended
recipient, please destroy this message, delete any copies held on your
system and notify the sender immediately.

Toshiba Research Europe Limited, registered in England and Wales
(2519556). Registered Office 208 Cambridge Science Park, Milton Road,
Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl

8

Hi,

It’s just the built in basic FDE. Its not awesome, but works well enough
at high SNR.

Yes, when I send multiple packets, its only the last OFDM symbol of the
last packet that is affected.

I have tried suffixing FFT_len/4 (i.e. 16 = CP) lots of 0’s in the TD at
the transmitter, and this fixes the problem (low power noise instead of
0’s also works).

Could it be an analogue issue? It is always the last symbol, i.e. the
end of the transmission, and it looks like the power might trail off
from the attached picture? But it seems strange that it’s exactly the
last symbol?

Could the pulse shaping performed in the cyclic prefixer have any
effect?!

Regards,

David

From: Martin B. [[email protected]]
Sent: 30 April 2014 14:56
To: David Halls; [email protected]
Subject: Re: OFDM Example, ‘Noisy’ final symbol

On 30.04.2014 13:14, David Halls wrote:

Hi Martin,

This is OTA or over a cable, 2.48GHz using the N210 with XCVR2450. The
results I sent are over a cable, and the results I sent are post equalizer.

Which equalizer are you using? A custom one? Those in GNU Radio aren’t
fantastic, and they don’t output soft info.

It is only the final symbol of a burst, not the final symbol of each packet.

So what you’re saying is that when you send several packets directly one
after another, only the last one gets this?

I agree they should all be equally noisy, and I am certain it’s not
‘noise’ as such.

I thought if the timing window is too late, then some TD samples for the
final symbol will be included in the FFT that are just noise. I have
stored the TD samples and manually performed FFT and eq’n and shifting
the window of samples to pass to the FFT (either forwards or backwards)
by up 16 samples does not help.

If the timing window’s late, something’s seriously wrong. It should
always be early.

I currently don’t have a good idea, though.

M

On 30.04.2014 11:51, David Halls wrote:

Is it to do with sample alignment/timing error? I have tried sliding the

NOTE: The information in this email and any attachments may be
confidential and/or legally privileged. This message may be read, copied
and used only by the intended recipient. If you are not the intended
recipient, please destroy this message, delete any copies held on your
system and notify the sender immediately.

Toshiba Research Europe Limited, registered in England and Wales
(2519556). Registered Office 208 Cambridge Science Park, Milton Road,
Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl

9

On 04/30/2014 05:17 PM, David Halls wrote:

Sorry, my fault - I altered the FDE so it does give soft outputs,
because the constellation decoder makes hard decisions anyway - so I
didn’t see the need for it to be done twice.

How exactly have you implemented that?

M_PI));
}
}

Is it extending the symbol and then shaping? Not sure I understand why
each packet is extended by rolloff_len/2, not each symbol.

Pulse shaping works by adding an up-flank at the start of every OFDM
symbol, and then extending the OFDM symbol by a down-flank.
What you’re seeing is the delay line. After the last symbol, we could
either discard this (which would lead to some out-of-band emissions), or
send it (which is what we’re doing).

Is pulse shaping applied in the USRP, and can this be controlled from
USRP_sink?

No, the USRP is agnostic of the actual modulation used.

M