On Mon, Sep 30, 2019 at 8:02 AM Andrew Payne wrote:
> I always do a tb.stop() followed by a tb.wait(), because I assume that
> .stop() is not blocking but .wait() is blocking
Yes, this is correct.
If you call stop() then wait() you stop the flow graph and wait for the
threads to actually shut
Thanks Kevin. I ended up calling the python method os.stat.st_size on
the IQ file that the flowgraph will transmit, converted that file size
to a time duration in seconds considering the sample size and rate,
start the flowgraph, then have a sleep function that checks for a flag
every 100
On Sat, Sep 28, 2019 at 7:46 PM Andrew Payne wrote:
> Understood. I do need to thread that tb.wait() because I have a callback
> to start the flow graph and a callback to stop the flow graph. Say I start
> then wait for it in an independent thread. Then say a different thread
> decides to stop
On Sat, Sep 28, 2019 at 6:34 PM Andrew Payne wrote:
> I have a short IQ file that I simply want to play once without repeating,
> and I want the calling Python code to "know" when it's completed after
> commanding the GR class instance to start via a call to tb.start(), if tb
> is the class
Hello,
I am writing a program in Python to interface with a simple file
source to USRP sink flowgraph.
I have a short IQ file that I simply want to play once without
repeating, and I want the calling Python code to "know" when it's
completed after commanding the GR class instance to start via a
