# OFDM Example, 'Noisy' final symbol **URL:** \ **Category:** GNU Radio\ **Created:** [April 30, 2014, 11:53am UTC](https://www.ruby-forum.com/t/ofdm-example-noisy-final-symbol/240786 "2014-04-30T11:53:33Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![Detlef\_R](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/58f4c7/32.png) [@Detlef\_R](https://www.ruby-forum.com/u/Detlef_R)\ **Post date:** [April 30, 2014, 11:53am UTC](https://www.ruby-forum.com/t/ofdm-example-noisy-final-symbol/240786/1 "2014-04-30T11:53:33Z")
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 ---
**Author:** ![divotdave](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/bbe5ce/32.png) [@divotdave](https://www.ruby-forum.com/u/divotdave)\ **Post date:** [April 30, 2014, 1:09pm UTC](https://www.ruby-forum.com/t/ofdm-example-noisy-final-symbol/240786/2 "2014-04-30T13:09:17Z")
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 ---
**Author:** ![divotdave](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/bbe5ce/32.png) [@divotdave](https://www.ruby-forum.com/u/divotdave)\ **Post date:** [April 30, 2014, 1:15pm UTC](https://www.ruby-forum.com/t/ofdm-example-noisy-final-symbol/240786/3 "2014-04-30T13:15:25Z")
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. [removed\_email\_address@domain.invalid] Sent: 30 April 2014 12:07 To: David Halls; [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 ---
**Author:** ![divotdave](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/bbe5ce/32.png) [@divotdave](https://www.ruby-forum.com/u/divotdave)\ **Post date:** [April 30, 2014, 3:57pm UTC](https://www.ruby-forum.com/t/ofdm-example-noisy-final-symbol/240786/4 "2014-04-30T15:57:54Z")
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 ---
**Author:** ![divotdave](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/bbe5ce/32.png) [@divotdave](https://www.ruby-forum.com/u/divotdave)\ **Post date:** [April 30, 2014, 4:16pm UTC](https://www.ruby-forum.com/t/ofdm-example-noisy-final-symbol/240786/5 "2014-04-30T16:16:53Z")
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. [removed\_email\_address@domain.invalid] Sent: 30 April 2014 14:56 To: David Halls; [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 ---
**Author:** ![divotdave](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/bbe5ce/32.png) [@divotdave](https://www.ruby-forum.com/u/divotdave)\ **Post date:** [April 30, 2014, 4:58pm UTC](https://www.ruby-forum.com/t/ofdm-example-noisy-final-symbol/240786/6 "2014-04-30T16:58:26Z")
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 ---
**Author:** ![divotdave](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/bbe5ce/32.png) [@divotdave](https://www.ruby-forum.com/u/divotdave)\ **Post date:** [April 30, 2014, 5:18pm UTC](https://www.ruby-forum.com/t/ofdm-example-noisy-final-symbol/240786/7 "2014-04-30T17:18:34Z")
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. [removed\_email\_address@domain.invalid] Sent: 30 April 2014 15:56 To: David Halls; [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 ---
**Author:** ![divotdave](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/bbe5ce/32.png) [@divotdave](https://www.ruby-forum.com/u/divotdave)\ **Post date:** [April 30, 2014, 4:04pm UTC](https://www.ruby-forum.com/t/ofdm-example-noisy-final-symbol/240786/8 "2014-04-30T16:04:38Z")
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. [removed\_email\_address@domain.invalid] Sent: 30 April 2014 14:56 To: David Halls; [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 ---
**Author:** ![divotdave](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/bbe5ce/32.png) [@divotdave](https://www.ruby-forum.com/u/divotdave)\ **Post date:** [May 1, 2014, 11:12pm UTC](https://www.ruby-forum.com/t/ofdm-example-noisy-final-symbol/240786/9 "2014-05-01T23:12:24Z")
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