discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Problem of benchmark_ofdm_rx.py. Could not recei


From: Milo Wong
Subject: Re: [Discuss-gnuradio] Problem of benchmark_ofdm_rx.py. Could not receive.
Date: Wed, 29 Jul 2009 17:32:30 -0700

Thank you, Tom.

What I mean by "switching tx/rx part" is just to switch the roles of two USRPs from tx to rx(or inverse).

I only have RFX2400 at hand and I tried 2.45G and 2.5G freq later on. So far, that one still could not receive the OFDM signal . But I tried another scheme (benchmark_tx & benchmark_rx) which performed well. So I could exclude the possibility of USRP's hardware problems.  But after I continued to switched the tx&rx role of USRPs, there's still one could not receive unless I power ON and OFF to restart it. That means if I want to switch the tx/rx roles, I need to power on/off to get them restart. What's the problems might be?

Thanks,

Yuan



On Wed, Jul 29, 2009 at 1:46 PM, Tom Rondeau <address@hidden> wrote:
Milo Wong wrote:
Hi,

I was doing a test using benchmark_ofdm_tx and rx to achieve the ofdm communication between two USRPs. At first, both USRPs could transmit and receive correctly. However, after swithing tx/rx part for a few times, one USRP suddenly failed in receiving (still can transmit), no matter which host PC it connected to. While, the other one still could work both in tx and rx. The one could not receive sometimes had "TIME OUT" after I stopped transmitting on the other side, or sometimes it only displayed a received wrong package with a very big packge number, or sometimes it had nothing to display.

We tried to switched two daughter boards and the problem was the same, still that one could not receive. Here are our test information:


I'm not exactly sure what you mean by "switching tx/rx part." Are you switching which roles the USRPs play?

>From what you say below, you're running the RFX2400 board. This has caused problems in the past if the oscillator frequency was too far off. When you multiply this up to 2.4 GHz, it can cause two USRPs that are nominally at 2.45 GHz to be off by a few kHz. This can be enough to cause the USRPs to be out of frequency locking range. The oscillator will also drift with temperature. Since they were working for you originally, it might be that as they warmed up, they were pushed just far enough outside the frequency range to become a problem.

Given the information you've provided, that's the best answer I have right now. Do you have any other daughterboards you can test with? Can you run other examples that still work?

The "TIME OUT" message comes from the receiver when it correlates to the access code but isn't able to get the packets. So it's seeming something, just not well enough to fully receive.

Tom

*Ubuntu 9.04

gnuradio-3.2.2/gnuradio-examples/python/ofdm/benchmark_ofdm_tx & rx
USRP/RFX2400*

run command:

*sudo python benchmark_ofdm_tx.py -f 2.45G
sudo python benchmark_ofdm_rx.py -f 2.45G*

Is there anyone who can help me with this problem? Thanks in advance!


Sincerely,

Yuan

 ------------------------------------------------------------------------

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]