|
From: | Marcus Müller |
Subject: | Re: [Discuss-gnuradio] Pad 'idle' items when an upstream block gives nothing |
Date: | Wed, 21 Oct 2015 15:23:15 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 |
Hi Jeon, with gr-eventstream, there's something that already does the "idle time padding": https://github.com/osh/gr-eventstream/ Read Tim's articles, too: http://oshearesearch.com/tag/gr-eventstream/ To answer your question: Well, yes, and no :) First: your Pad Idle block is a stream source (It doesn't have a stream input, only a message input); you don't have to implement a forecast, just use a sync block type (or the source block type that gr_modtool offers you to generate). Generally, it's right to tell GNU Radio you can't produce anything with the current input, but: stream sources are a little special, as they never get input, so from GNU Radio's perspective, the input situation can't ever change. So telling GNU Radio you can't produce anything will make your flow graph stop. As a side note, I've never thought about whether forecast ever gets called on a source -- basically, what should that do? There's not ninput_required array with nonzero length to be filled with values on a block with no inputs! 2. If forecasting zero item is possible, willl general_work() be called extremely frequently so that other blocks are prevented from being called?There's no "preventing other blocks from being called". GNU Radio is multithreaded, and as long as there's stuff to be done, the other blocks will be called until all buffers have run dry. The point here is that you should just block in your work function if you're a source. However, with the modern message passing alone, that's impossible, because messages are always delivered when your work is currently not running. Hence, gr-eventstream takes a queue approach, and that works pretty well. Best regards, Marcus On 10/21/2015 02:53 PM, Jeon wrote:
|
[Prev in Thread] | Current Thread | [Next in Thread] |