UHD and gr_block_executor error: "source <gr_block gr uhd usrp source (1)> produced no output. We're

GNU Radio
1

Hi All,

I’m working on a program that allows two E100’s to communicate over
radio frequencies. This program runs well on a pair of N210s, but on
the On the receiving end, the program has two principle flow graphs that
both connect to the uhd usrp source. The first one used (A) is used
only at the beginning of the program; afterwards, the second flow graph
(B) is used. Upon running the program, I’m getting the following error
messages:

 UHD source block got error code 0x9
 gr_block_executor: source <gr_block gr uhd usrp source (1)>

produced no output. We’re marking it DONE.

and, much more frequently,

 UHD source block got error code 0x10
 gr_block_executor: source <gr_block gr uhd usrp source (1)>

produced no output. We’re marking it DONE.

I’ve tried leaving A and B connected the entire time, connecting B
before disconnecting A, disconnecting A before connecting B, but none of
these have alleviated the issue. The error messages don’t typically
occur until we’ve switched to B. Also, I’ve been unable to find what
either of these error codes stand for in the GR and UHD documentation.

I get this error whether I’m running the program on one or both of the
E100s. Even when I’m only running it on one of the E100s, it should
definitely be detecting something at the rx port, since I’m running it
directly there from a noise generator.

Do you have any idea what these error codes mean or why I might be
getting these errors?

Thank you very much for your help,

Chris

2 
UHD source block got error code 0x9
gr_block_executor: source <gr_block gr uhd usrp source (1)> produced

no output. We’re marking it DONE.

and, much more frequently,

UHD source block got error code 0x10
gr_block_executor: source <gr_block gr uhd usrp source (1)> produced

no output. We’re marking it DONE.

They are totally bogus error codes.
http://www.ettus.com/uhd_docs/doxygen/html/structuhd_1_1rx__metadata__t.html

What do you mean by connecting A or B. Can you send some psudocode that
demonstrates what you are doing that causes the problem?

3

Hi Josh,

See below…

On 8/2/2011 3:19 PM, Josh B. wrote:

They are totally bogus error codes.
http://www.ettus.com/uhd_docs/doxygen/html/structuhd_1_1rx__metadata__t.html

What do you mean by connecting A or B.

By connecting or disconnecting A or B, I mean using gr_block’s connect
and disconnect methods to connect A or B to the source. Class A and
class B are both subclasses of gr.hier_block2, so they each contain a
part of a flowgraph. Self.tb, below, is our instance of gr_top_block.

 self.tb.stop()
 self.tb.wait()
 self.tb.lock()
 self.tb.connect(self.tb.u_src, self.tb.b_flow)
 self.tb.disconnect(self.tb.u_src, self.tb.a_flow)
 self.tb.unlock()
 self.tb.start()

Can you send some psudocode that
demonstrates what you are doing that causes the problem?

The problem itself arises during this next block, which immediately
follows the code above:

 if self.tb.tx_freq != self.minFreq:
     self.tb.lock()
     self.tb.set_snk_freq(self.minFreq)
     self.tb.unlock()
     self.tb.tx_beacon = True
 if self.rx_scan_freq != self.origTxFreq + index * self.step_size:
     self.tb.lock()
     self.rx_scan_freq = self.origTxFreq + index * self.step_size
     result = self.tb.set_src_freq(self.rx_scan_freq)
     self.tb.unlock()
     time.sleep(0.1)

Thanks!

Chris

4

OK I understand what you are doing. Not sure how the problem occurs. I
wonder if the locking/unlocking during running pushes the driver into
come corner case. See if any of my comments below make a difference for
you:

self.tb.stop()
self.tb.wait()
self.tb.lock()
self.tb.connect(self.tb.u_src, self.tb.b_flow)
self.tb.disconnect(self.tb.u_src, self.tb.a_flow)
self.tb.unlock()
self.tb.start()

Someone stop me if I am wrong, but to reconnect blocks in your flow
graph, you can stop->re-connect->start, or lock->reconnect->unlock, but
you dont have to do both.

    self.tb.tx_beacon = True
if self.rx_scan_freq != self.origTxFreq + index * self.step_size:
    self.tb.lock()
    self.rx_scan_freq = self.origTxFreq + index * self.step_size
    result = self.tb.set_src_freq(self.rx_scan_freq)
    self.tb.unlock()
    time.sleep(0.1)

You shouldnt have to lock the flow graph to change block parameters. I
don’t think that is the cause of the issue but that might be worth
trying.

If you can encapsulate the issue with a simpler flow graph or something
you can email. I would be happy to try to replicate and debug the
problem.

-josh

5

Hello,
We have been seeing a similar problem when we tried to change a top
block by stopping it and then creating a new top block.

First it looked like the problem was related to the synchronization of
uhd sources, see
http://lists.gnu.org/archive/html/discuss-gnuradio/2011-05/msg00441.html
(The start of the discussion is here:
[Discuss-gnuradio] How to delete and create a new top_block?)

Later we found that the problem still occurred after the fix with the
timeout. We noticed that when looking at the clock signals on an
oscilloscope, the sources didn’t resynchronize properly. When this
happened, the error you see also appeared. We fixed this by setting the
top block to 0 before creating a new top block.
for i in range(4):
tb = 0
tb = top_block()
tb.start()

Maybe something isn’t reset properly or maybe this is some sort of
garbage-collection related problem? Any other ideas?

/Ulrika