[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] UHD and gr_block_executor error: "source <gr_bloc
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."
Tue, 02 Aug 2011 15:21:17 -0700
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:220.127.116.11) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11
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.connect(self.tb.u_src, self.tb.b_flow)
> self.tb.disconnect(self.tb.u_src, self.tb.a_flow)
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.tx_beacon = True
> if self.rx_scan_freq != self.origTxFreq + index * self.step_size:
> self.rx_scan_freq = self.origTxFreq + index * self.step_size
> result = self.tb.set_src_freq(self.rx_scan_freq)
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.