Re: [Discuss-gnuradio] UHD and gr_block_executor error: "source <gr_block gr uhd usrp source (1)> produced no output. We're marking it DONE."

[Josh Blum]

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.

>> 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)
> 

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