Check out some of the publications by Fred Harris. He has written some good stuff on sync. algorithms.
On Fri, Sep 9, 2011 at 5:48 PM, Tuan (Johnny) Ta <ta.tu...@gmail.com> wrote: > 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 > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
