On Fri, Sep 9, 2011 at 8:00 PM, Marcus D. Leech
<address@hidden> wrote:
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).
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.
Yes, the 40kHz offset that I had was within specs, because I transmitted at 2.4GHz, so it was ~ 17 PPM.
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.
In fact, the benchmark_ofdm_rx chain has ofdm_sync_pn, which is the synchronization block aiming to correct the frequency offset. The algorithm is here
T. M. Schmidl and D. C. Cox, “Robust Frequency and Timing Synchronization for OFDM,” IEEE Trans. on Comm., vol. 45, no. 12, pp. 1613-1621, December 1997
However, even with the synchronization block, the offset still seems to be too much. I was in the process of tracing the data through the sync block before I had to move on.
Physics, it turns out, is a harsh mistress...
But it's def fun!
Johnny
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org