Re: [Discuss-gnuradio] Strange overflow problem on USRP N2XX

[Josh Blum]

On 09/18/2012 05:36 AM, Ting Wu wrote:
> Hi,
> 
>  
> 
> I made more tests, and even stranger things happened. Let me clarify this
> problem all over again.
> 
>  

Well, here is a description of overflow:
http://files.ettus.com/uhd_docs/manual/html/general.html#overflow-underflow-notes

So, its usually a factor of buffering, interrupts, and CPU performance.
It looks like you are connecting a USRP source to a gr messsage queue
and reading the queue in python. The python processing might be a
serious performance bottleneck

-josh

> 
> 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:
> 
>  
> 
> address@hidden:~$ ./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: address@hidden
> [mailto:address@hidden
> g] On Behalf Of Ting Wu
> Sent: Tuesday, September 18, 2012 5:36 PM
> To: address@hidden
> 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
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>