Jeon,
You could also possibly use the HDLC framer/deframer blocks. That block
produces an idle flag when there are no message inputs.
-- Seth
On 10/21/2015 11:39 AM, Jeon wrote:
Dear Marcus,
Thank you for quick and detailed answer.
I'll check that gr-eventstream as well as fundamentals of GNU Radio
you've described.
Regards,
Jeon.
2015-10-21 22:23 GMT+09:00 Marcus Müller <marcus.muel...@ettus.com
<mailto:marcus.muel...@ettus.com>>:
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:
1. Is it allowed to forecast zero item? And does it behave as I
expect?
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:
Consider a flow graph like: http://i.imgur.com/bNa6YuQ.png
Message source produces a short message. Period is quite long.
Thus, There should be a long idle time.
I'd like to build a block 'pad idle'. The block pad a predefined
sequence if the upstream block gives nothing.
I think a prototype would be:
https://gist.github.com/gsongsong/d40b85a76ab8e80ae468#file-gistfile1-txt-L11
By setting the number of required items to zero in forecast(),
general_work() will be called even there is no items received.
And general work() checks the ninput_items and if it is zero,
generates some idle-padding samples/patterns. Otherwise, it just
handles and passess a message/samples to downstream.
But it's just my thought. There may be a couple of considerations.
1. Is it allowed to forecast zero item? And does it behave as I
expect?
2. If forecasting zero item is possible, willl general_work() be
called extremely frequently so that other blocks are prevented
from being called?
Regards,
Jeon.
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
