Question about tx&rx examples

Hi All,

I got problems in running gnuradio-examples when I tested the USRP
boards:
(Ubuntu9.04/gnuradio-3.2.2)

Example 1) OFDM_Tx&Rx
(…/gnuradio-examples/python/ofdm/benchmark_ofdm_tx&rx)

By the time so far, I have several different kinds of outcomes by
different
attampts even I tried with the same command. It seems that it never has
a
“stable” same outcome. The problems I have met so far include the
following
(these are different experiences that I have had when running the tests
at
different times):

-1, One of the USRPs always can not receive, even though I attempt to
power cycled it or stop receiving and restart again without power
cycling. I
labled it as a “Problem” one.

-2, Both USRPs can transmitting and receiving for a short time(around
2mins), and then one USRP(the same “problem” one as mentioned in result
1)
failed to receive while the other one was still transmitting. The failed
one
could not get recovered, even though I attempted to power cycled it or
stop
receiving and restart again without power cycling.
There’s a similar case that if I stoped receiving of the
“problem”
USRP and restart receiving again without power cycling . The “problem”
USRP
could receive for the first two or three times, but after I attamped to
restart receving for the fourth time(for example). The “Problem” USRP
can
not receive packges.

-3, Yesterday morning before lunch time,both USRPs can miraculously
transmitting and receiving for a relatively long time(around 10-15mins)
without any part of them failed (transmitting and receiving in both
direction). While after coming back from lunch, however, the problem
came
out again exactly same as the first one above. (i.e. transmitting and
receiving only in one direction).


Example 2) non-OFDM example (under
…/gnuradio-examples/digital/benchmark_tx&rx)
-1, Yesterday, there’s no problems if I kept on transmitting from one
to
the other without switching the tx&rx parts. If I stoped receiving and
restarted to receive without power cycling, the receiver would keep on
receiving.

-2, The problem will come out after I switched the TX and RX role of
USRPs. I had to power cycle the USRP which is going to receive,
otherwise,
it will not work. (Actually, both USRPs exhibit problems depending on
which
one is the receiver and this USRP has to be power cycled in order to
receive
packge correctly)

Above are my test results. I was wondering if it might be concluded as
the
hardware problems. If you have any comments or ideas, please let me
know.
Thanks in advance!

Sincerely,

Yuan

On Tue, 2009-08-04 at 12:16 -0700, Milo W. wrote:

Above are my test results. I was wondering if it might be concluded as
the hardware problems. If you have any comments or ideas, please let
me know. Thanks in advance!

While it’s hard to say how likely this is, it is possible that thermal
cycling of the USRPs is causing frequency drift enough to interfere with
reception. I don’t know what the temperature coefficient of the USRP
master oscillator is, but the fact that things are sensitive to how long
the units are powered up and time of day is suspicious.

Johnathan

HI all,
I guess it might be the temperature issue, cause I used a small fan to
pump
out the heat and the receiving part could come back to work. However, I
still have to power cycle to receive in the second
example(gnuradio-examples/digital/benchmark_tx&rx.py). Confusing.
Anyway,
thank you all for the help!
Milo

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs