On Fri, Aug 23, 2013 at 10:10:13AM +0200, Bastian Bloessl 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 :) 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 Braun 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
pgppvwby8r7HL.pgp
Description: PGP signature
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
