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 <[email protected]> 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 >> [email protected] >> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > >
_______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
