Hi,
I made more tests, and even stranger things happened. Let me clarify
this
problem all over again.
I have two USRP (N210 Rev.4) (Let’s say U1 and U2) with LFRX
daughterboard,
and two computers (Endeavo ST160E) (Let’s say P1 and P2).
First, U1 is connected with P1 and running test code (see below) works
well.
U2 is connected with P2, and running the code below prints ‘O’,
indicating
overflow problem.
Then, I connect U1 to P2. Overflow problem happens again, and printing
of
‘O’ becomes more frequent.
Then, I connect U2 to P2. Same as above, frequent printing of ‘O’.
Then I rebooted P2, and connect it with U1. No overflow problem.
Then I connect P2 with U2. Again there is overflow problem.
Then I rebooted P2 again, and connect it to U2. No overflow problem
again.
For P1, there is always overflow problem even if I reboot it and no
matter
it is connected with U1 or U2.
This is the code for making tests:
#######################################code##########################
#!/usr/bin/env python
from gnuradio import gr
from gnuradio import uhd
import time
from time import sleep
from struct import unpack
samp_rate = 4e6
gain = 0
class trig_with_pretrig(gr.top_block):
def __init__(self):
gr.top_block.__init__(self)
self.source = uhd.usrp_source(device_addr="",
stream_args=uhd.stream_args(‘sc16’, ‘sc16’, args=“scalar=1024”))
self.source.set_samp_rate(samp_rate)
self.source.set_gain(gain)
self.source.set_center_freq(0)
self.queue = gr.msg_queue()
self.sink = gr.message_sink(gr.sizeof_short*2, self.queue,
False)
self.connect(self.source, self.sink)
if name==“main”:
tb = trig_with_pretrig()
tb.start()
while True:
#Test speed of computer
tb.queue.flush()
for i in range(1000):
msg = tb.queue.delete_head()
payload = msg.to_string()
loadLen = int(msg.arg2())
format = str(loadLen*2)+'h'
data = unpack(format, payload)
datach1 = data[0::2]
dataMax = max(datach1)
wait_len = tb.queue.count()
sleep(1)
##########################code ############################
When there is overflow problem, it is like this:
lrg@lrg:~$ ./test_overflow.py
linux; GNU C++ version 4.4.3; Boost_104000;
UHD_003.004.003-224-gc2e197c0
– Opening a USRP2/N-Series device…
– Current recv frame size: 1448 bytes
– Current send frame size: 1472 bytes
– Detecting internal GPSDO… Found a Jackson Labs GPS
– found
– Setting references to the internal GPSDO
– Initializing time to the internal GPSDO
OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
Anyone has any clue what might be the reason for this overflow problem?
Any suggestion is appreciated.
Wu
From:
discuss-gnuradio-bounces+wu.ting=removed_email_address@domain.invalid
[mailto:discuss-gnuradio-bounces+wu.ting=removed_email_address@domain.invalid
g] On Behalf Of Ting Wu
Sent: Tuesday, September 18, 2012 5:36 PM
To: [email protected]
Subject: [Discuss-gnuradio] Strange overflow problem on USRP N2XX
Hi all,
Now I’m using several USRP N200 and N210 to build an observation
network.
I have bought several new computers, which are exactly the same.
When I connect a USRP N210 with one computer, it has overflow problem
(occasionally print ‘O’).
However, when I connect the same USRP with another computer (exactly the
same model), it does not have such problem.
Several months ago, when I used a USRP N200, it also had similar
problem.
When I connect the USRP to a laptop (a very new and fast one), it
occasionally has overflow problem.
However, when I connect it to other computers (some of them are very old
and
slow), it did not have the problem.
This really bothers me because I don’t know what is the reason of this
problem, so we are not sure what computers we should buy in future
operation.
Does anyone have any clue?
Wu