Thanks Marcus, that was very informative! On Fri, Sep 9, 2011 at 8:00 PM, Marcus D. Leech <mle...@ripnet.com> 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). >> > 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. > 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 > > > > > ______________________________**_________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/**listinfo/discuss-gnuradio<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio> >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
