Re: [Discuss-gnuradio] UHD and gr_block_executor error: "source produced no output. We're marking it DONE."

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

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio