[Top][All Lists]

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

Re: [Discuss-gnuradio] OFDM Implementation

From: Marcus D. Leech
Subject: Re: [Discuss-gnuradio] OFDM Implementation
Date: Fri, 09 Sep 2011 20:00:58 -0400
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110831 Fedora/3.1.12-2.fc14 Thunderbird/3.1.12

On 09/09/2011 07:26 PM, Tuan (Johnny) Ta wrote:
As far as I know there's no open source code for an OFDM transceiver available. I was trying to build one half a year back but wasn't successful before I had to move on to something else. The benchmark_ofdm code will give you a simplex OFDM system. Ie you can run the transmitter on 1 USRP and receiver on another.

Ie. run this on 1 USRP
./benchmark_ofdm_tx.py -f 2.412G

And this on the other
./benchmark_ofdm_rx.py -f 2.412G

The value of the frequency depends on the daughterboards you're using. If you're using USRP1 make sure the decimation rate is 1/2 of the interpolation rate as the ADC is 2 times faster than the DAC on the USRP1 (or the other way around, you should chek that).
The DAC on the USRP1 runs at twice the rate of the ADC.

Watch out for the frequency offset, it killed the system for me. If the above doesn't work, run the transmitter on 1 USRP and usrp_fft.py on the other. Check the center frequency of the FFT plot and manually adjust the receiver center frequency. I used the RFX2400 boards and the offset for me was ~ 40kHz.

Frequency offset comes up a lot on this list. It's usually in the context of someone who has up to this point in their DSP/SDR "career" only been dealing with baseband signals inside a simulation environment--and environment that doesn't always adequately reflect
  what you'll experience in real-world systems, and real-world channels.

RF synthesizers are only as good as their reference clock. The reference clocks on most garden variety RF platforms are usually of good-to-excellent quality. But they may still have residual errors of a few 10s of PPM. So that means for every MHz of frequency, the absolute, actual frequency could be "off" by a few 10s of Hz. Multiply that up to typical channel frequencies for many experiments in the modern communications domain of 1 to 3GHz or even higher, and you can easily end up with 10s of Khz of absolute frequency offset,
  and this applies to both the transmitter and receiver.

In typical cellular phone systems like LTE, and GSM and the like, the base-station transmitters typically have really good reference clocks-- good to a few PPB--a local rubidium clock, or a GPSDO. The the hand-helds typically have cheap local reference clocks, in order to meet
  the grueling BOM cost requirements of typical consumer electronics.

What that means is that the demodulation chain needs some mechanism to deal with frequency offset, and provide feedback to "center" the baseband signal--either by tweaking the RX hardware, or shifting the baseband signal in software. But the example code that's floating around is typically *not* a *complete* system in this regard. In some sense, much of it was designed to work in the "fantasy" land of the simulation environment, and may not work that well in the real world. In some OFDM systems, for example, I understand that there is often a "pilot" carrier against which one can correlate some kind of sequence, and once you've found the most-strongly-correlated "bin" in the OFDM "comb", you can use that to estimate the frequency offset relative to the transmitter. Examples and simulations may or may not have that covered. College-level programs in DSP and SDR may or may not discuss that important "real world" detail.

Physics, it turns out, is a harsh mistress...

Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

reply via email to

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