Thanks Michael, I think this is too complicated for my use case, so I'll find another way.
Apart from this, is there any way to tell the top block to flush the samples still in it after you call stop() and wait()?
I don't want those samples to be sent out after I call start() again.
Many thanks,
Adrian
On September 16, 2019 6:23:52 PM UTC, Michael Dickens <
address@hidden> wrote:
Hi Adrian - It's non-trivial to determine the state of the buffers from inside blocks, but with the correct C++ class/type coercion it can be done -- even if you're not supposed to do that. I don't recommend doing so, of course. Thinking there will be a better way to do what you're hoping to do. - MLD
On Mon, Sep 16, 2019 at 11:41 AM Adrian Musceac <
address@hidden> wrote:
Hi Kevin,
Thanks for the answer, unfortunately in my case I want to keep the flowgraph running and I'd need a way to check the state of the block buffers. Maybe I can do that with a custom block before the source or maybe I should rethink my approach.
Adrian
On September 16, 2019 2:42:06 PM UTC, Kevin Reid <
address@hidden> wrote:
On Mon, Sep 16, 2019 at 4:22 AM Adrian Musceac <
address@hidden> wrote:
So far I haven't found a way (callback?) to tell when the last sample is out of the flowgraph. I am using the C++ API of GNU radio.
The wait() method of a top_block will block the calling thread until all items have passed through.
Note that this will only succeed if your source blocks indicate there are no more items, by returning -1 (gr::block::WORK_DONE). Vector and file sources and other such standard fixed-length sources do, but if your source is merely emitting no items at this time (e.g. a network source that's not currently receiving packets) the flow graph will still be running waiting for more. I do not know of a way to ask for "when all buffers are currently empty", if that's what you need.
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--