Hi Rahman, Just like you, my USRPs have suddenly started failing the CRC for every packet.
By changing the frequency to 1MHZ I'm back to 99% correctly received :) From searching the mailing list it looks like it's related to the increased frequency offset due to aliasing at the higher frequencies. Also, there is a setting in ofdm_receiver.py for SYNC. For me, SYNC="ml" works the best. Mike On 19 June 2010 17:10, Rahman Doost <d.mohamm...@gmail.com> wrote: > Thanks Mike for the comment. I did change the bandwidth, but some error > poped up at runtime for 1.5. Lower values like 0.1 or 0.2 did not change the > behavior of the receiver. Still no correct packet. I receive the packets > though but they fail the CRC check I guess, since I get this "ok:false" > status on each of them. Any idea? > > Thanks, > Rahman > > > On Thu, Jun 17, 2010 at 5:29 AM, Mike Jameson <mikej...@gmail.com> wrote: > >> missed off the filename: ofdm_receiver.py >> >> :) >> >> >> >> On 17 June 2010 10:27, Mike Jameson <mikej...@gmail.com> wrote: >> >>> Hi Rahman, >>> >>> Try broadening the bandwidth of the receiver to allow for the frequency >>> offset between your USRP2s: >>> >>> In /usr/lib/python2.6/dist-packages/gnuradio/blks2impl >>> >>> on line 67 look for "tb = bw*0.08" >>> >>> change this to a higher value such as "tb = bw*1.5" >>> >>> This works for me using usrps. >>> >>> Mike >>> >>> On 16 June 2010 23:13, Rahman Doost <d.mohamm...@gmail.com> wrote: >>> >>>> Guys, >>>> >>>> I'm working on the same thing, I'm trying to receive something with OFDM >>>> example, USRP2 and XCVR boards. But it doesn't work. The transmitter is >>>> sending and the rx signal is crystal clear with spectrum analyzer but no >>>> packet is caught. >>>> Could anyone of you send me the command you're using at both transmitter >>>> and receiver with benchmarks? I really appreciate it. >>>> >>>> Thanks >>>> Rahman >>>> >>>> On Tue, Jun 15, 2010 at 5:53 AM, Mike Jameson <mikej...@gmail.com>wrote: >>>> >>>>> Hi Chris, >>>>> >>>>> The default settings do drop alot of packets as you are seeing. >>>>> >>>>> These are some of the things I've adjusted which happen to have brought >>>>> my packet reception rate up to 99% using 1 USRP with a Basic RX and >>>>> TX joined with a 10db attenuator: >>>>> >>>>> - For benchmark_tx.py and benchmark_rx.py add '-m qpsk' to the command >>>>> line for qpsk instead of bpsk. >>>>> - For benchmark_tx.py add '-s 4' to the command line to reduce the >>>>> packet size sent. >>>>> - For benchmark_tx.py add '-d 1' to the command line to reduce the rate >>>>> and change the benchmark_tx.py script to sleep for 0.01 seconds instead of >>>>> 1. >>>>> - For benchmark_tx.py add '--tx-amplitude=3000' to the command line to >>>>> boost the default output power. >>>>> - In transmit_path.py pad_for_usrp=true and msgq_limit=1 >>>>> >>>>> Cheers, >>>>> >>>>> Mike >>>>> >>>>> On 15 June 2010 10:20, Chris_Spain <christianper...@gmail.com>wrote: >>>>> >>>>>> >>>>>> Thank you Fisheep, you confirmed what I was thinking but, I don't Know >>>>>> why, >>>>>> the packets are been received with no errors, I lost packets but the >>>>>> packets >>>>>> that I receive are good. >>>>>> >>>>>> I don't Know how GNU Radio implementation maps 1024 bytes over 200 >>>>>> carriers >>>>>> with a bpsk modulation, and then the transmission it's OK. >>>>>> >>>>>> Cheers >>>>>> >>>>>> >>>>>> Fisheep wrote: >>>>>> > >>>>>> > Hi, >>>>>> > >>>>>> > I'm not sure why you can't receive all the packet correctly, but I >>>>>> can >>>>>> > briefly tell you how ofdm implement in GNU Radio. >>>>>> > >>>>>> > First, fft_length=512 means it will take 512 subcarriers to do >>>>>> ifft/fft, >>>>>> > and occupied_tones=200 means it only take 200 subcarriers to put >>>>>> your >>>>>> > modulation symbol. Besides, the 200 subcarriers are set at the >>>>>> center of >>>>>> > 512 subcarriers. Then you will see there are the remaining >>>>>> 312(512-200) >>>>>> > subcarriers which is zero outside the occupied_tones. >>>>>> > >>>>>> > likes this: >>>>>> > >>>>>> > xxxxxOOOOOOxxOOOOOOxxxxx >>>>>> > --------------+----------------> f >>>>>> > >>>>>> > O => occupied_tones >>>>>> > x => remaining subcarriers >>>>>> > the two x at the center is to avoid DC offset. >>>>>> > After ifft, the CP is added. >>>>>> > >>>>>> > OFDM is sensitive to the bitrate(interpolate/decimate), so set the >>>>>> bitrate >>>>>> > carefully. >>>>>> > >>>>>> > Hope this will help you little. >>>>>> > >>>>>> > Fisheep. >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > Chris_Spain wrote: >>>>>> >> >>>>>> >> Hello everybody, >>>>>> >> >>>>>> >> >>>>>> >> I' am trying to test and understand the OFDM Modulation implemented >>>>>> in >>>>>> >> GNU Radio. I'm using the deafult values, fft_lenth=512, >>>>>> occupied_tones >>>>>> >> =200, cp_length= 128 and bpsk modulation, besides, I'm using a >>>>>> RFX900 >>>>>> >> Daughterboards on USPR and I'm connecting the TX and RX with a >>>>>> coaxial >>>>>> >> cable. >>>>>> >> >>>>>> >> I try to send a package of 1024 bytes but I'm not receiving all >>>>>> packets, >>>>>> >> always lost the first packet and then is a little bit random, >>>>>> sometimes I >>>>>> >> receive and I demodulated the 2º,3º,4º package and lost 5º, or lost >>>>>> 3º >>>>>> >> and recive ok 2 ºand 4º... >>>>>> >> I don't know what are happening, because I don't know how the OFDM >>>>>> >> implementation map the 1024 bytes onto 200 carriers of data. >>>>>> >> >>>>>> >> If I'm understanding the OFDM theory, with a bpsk modulation each >>>>>> carrier >>>>>> >> are modulated for two bits and my OFDM symbol length are 512+128 >>>>>> >> (fft_length+cp_length).So, ¿with 2 bits per data carrier (200), >>>>>> each >>>>>> >> symbol transport 400 bits, 50 bytes? >>>>>> >> >>>>>> >> That can´t be true because I receive some packages with no errors. >>>>>> >> Somebody can explain me, How works OFDM Modulation implemented in >>>>>> GNU >>>>>> >> Radio? >>>>>> >> >>>>>> >> >>>>>> > >>>>>> > >>>>>> >>>>>> -- >>>>>> View this message in context: >>>>>> http://old.nabble.com/OFMD-TX-and-RX-tp28871027p28888978.html >>>>>> Sent from the GnuRadio mailing list archive at Nabble.com. >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Discuss-gnuradio mailing list >>>>>> Discuss-gnuradio@gnu.org >>>>>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Discuss-gnuradio mailing list >>>>> Discuss-gnuradio@gnu.org >>>>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Discuss-gnuradio mailing list >>>> Discuss-gnuradio@gnu.org >>>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>> >>>> >>> >> >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
