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=comf5.comm.eng.osaka-u.ac...@gnu.org [mailto:discuss-gnuradio-bounces+wu.ting=comf5.comm.eng.osaka-u.ac...@gnu.or g] On Behalf Of Ting Wu Sent: Tuesday, September 18, 2012 5:36 PM To: discuss-gnuradio@gnu.org 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
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio