On 10/11/2013 11:48 AM, Alex3371 wrote: > Wow, thank you for your detailed answer. > > But one thing I don't understand: > > " If you called run() on the first one, it would not return from that > call until the flowgraph exited, and your second flowgraph would get > started too late. " > > I don't want the flowgraphs to run parallel to each other. One > flowgraph senses the spectrum with the USRP and the second flowgraph > transmitts a signal with the same USRP (depending on the measurements > of the spectrum). So it's important that they run consecutively.
Ah, I missed this. > In this case, is it fine the way I do call run() for both flowgraphs? > Would replacing it with start() + wait() make any difference? Since you have a finite length flowgraph, there really is no difference. > When the flowgraph is stopped by a head-block the threads are > shutdown, but the flowgraph itself still exists with all the > blockinternal member variables (including possible changes during the > first run) and after a head-reset it can be re-run with the > run()-method. This re-run starts where the previous run stopped. Is > that correct? Yes. On occasion we've found bugs in blocks that assumed their start() functions would only get called once (like in the ALSA audio source/sinks) but otherwise this is how it works. I would suggest, however, that you reconsider this approach if you are eventually going to be doing anything more than simple processing. Starting and stopping flowgraphs is using a very heavy hammer and takes a long time (in sample terms). Instead, think of always having the two flowgraphs instatiated and started, and adding a message input port to a custom block on the transmitter and message output port to a custom block on the receiver. You can then move your control logic into a Python message only block that receives a message from the receiver, does whatever needs to be done as a result of this, then triggers the transmitter by sending a message to it. The flowgraph then is always running, but you've separated your signal processing control from flowgraph run/start/stop/wait semantics. You can also extend this idea of a control block to allow triggering the receiver (via message passing) from a GUI button, which can have an event handler in the Python block to trigger the receiver via message. (This description is missing details on how this would change your flowgraphs to be message triggered, as I'm not aware of what's in them.) Asynchronous messaging is a very new feature of GNU Radio and we don't have many examples of using it to learn from. But the above scenario is one use case we had in mind in designing it. -- Johnathan Corgan, Corgan Labs SDR Training and Development Services http://corganlabs.com
<<attachment: johnathan.vcf>>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
