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

[Ting Wu]

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 = "" 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

OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO

 

Anyone has any clue what might be the reason for this overflow problem?

Any suggestion is appreciated.

 

Wu

 

From: address@hidden [mailto:address@hidden 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