|
From: | Marcus D. Leech |
Subject: | Re: [Discuss-gnuradio] Question about benchmark_tx and benchmark_rx |
Date: | Wed, 14 Dec 2011 19:24:33 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16 |
A common reason for this type of problem is frequency-offset between RX and TX. On the RX side, use uhd_fft.py to observe the spectrum and see where the receiver thinks the peak of the spectrum is. Then adjust your '-f' accordingly on a subsequent run of benchmark_rx.py.Hi there,I made some decent progress but refining the parameters for the benchmark_tx.py and benchmark_rx.py without no errors. However, I can only transmit but I could not receive anything at the receiver side. Could somebody suggest what might be the problem? I tried to work it but still could not find answer on why I did not received anything.Used code: ./benchmark_tx.py -f 400M -r 250k -S 4 and ./benchmark_rx.py -f 400M -r 250k -S 4OS: Ubuntu 11.10 (which I read in blog said that it has some problem with gnuradio)Gnuradio: 3.5.0 rc 0 (which I git from master branch) Hardware: USRP1(transmitter), USRP N210(receiver) Machine: Lenovo T510 (transmitter), Dell Desktop Regards, Muhammad
Crystal oscillators aren't perfect. Even an error of a few 10s of PPM can add up to several Khz at center frequencies in the hundreds of MHz. Unless the receive flow-graph has a way of correcting gross frequency error, you will have to do that manually.
This is such a common problem that I'm surprised you haven't covered it in your coursework yet. Real radios (and radio channels) have
impairments that often aren't adequately modelled by simulations. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org
[Prev in Thread] | Current Thread | [Next in Thread] |