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