discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] [benchmark_ofdm]


From: Martin Braun
Subject: Re: [Discuss-gnuradio] [benchmark_ofdm]
Date: Wed, 8 Apr 2009 10:00:51 +0200
User-agent: Mutt/1.5.17 (2007-11-01)

On Tue, Apr 07, 2009 at 10:32:20AM -0700, Rita's pfc wrote:
> 
> Hi,
> I'm using benchmark_ofdm tx and rx in 2.4 GHz. I'm trying to transmit a
> fixed size of payload everytime (1328 Bytes). My problem is I don't know
> what values I must put in the parameters: fft-length, occupied-tones,
> cp-length. I know that fft-length is the total number of subcarriers, cp the

Hi,
just to be clear: fft-length is not the total number of subcarriers, it
is, as the name says, the FFT length. If these were identical, it would
be pretty difficult to filter out the OFDM signal as it would uniformly
fill the Nyquist band.
Sorry if this is what you meant, it jusn't wasn't quite clear to me.

> cyclic prefix, occupied-tones number of subcarriers used for data. I have
> been running modifications of these benchmarks, and the best performance I
> get is when the values of these parameters are: fft-length 512, cp 128,
> occupied tones 300. In this case, the 80 % of paquetes I receive are right. 
> How can I calculate the apropiate values ? Must I used the parameter "-s"
> for fixed the packet size to the one I want, 1328? what happen with the "-i"
> and "-d" in the transmitter and the receiver?

The packet length and the OFDM settings are not directly connected -
that is, in principle, you can have any combination (although that does
not always make sense). In theory, GNU Radio works well with any OFDM
setting, so all you have to do is adapt the settings according to your
data transmission requirements (bit rate, channel characteristics etc.).

I haven't got a working setup at my fingertips right now, but -s should
be the right thing to do. However, note that the benchmark_ofdm* code
uses the GNU radio packet module, which itself does stuff to your data,
so perhaps your signal does not look exactly as you expected it to be.

On a side note, when I was playing around with the OFDM benchmark code,
I never achieved a brilliant packet error rate, 80% was close to the
best I achieved - but I never tore the code apart to check for the
cause.

Good luck,
MB

-- 
Dipl.-Ing. Martin Braun           Phone: +49-(0)721-608 3790
Institut fuer Nachrichtentechnik  Fax:   +49-(0)721-608 6071
Universitaet Karlsruhe (TH)       http://www.int.uni-karlsruhe.de/

Attachment: pgp_8I0DTBaC1.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]