I'm a bit curious as to why you'd need a forecast that returns 0 --
basically, there's no input stream, so I'm not quite sure forecast
return values make a difference.
Like Tom, I see a bit of a problem with this:
1. from a stream perspective, this is a simple source. Sources should
block /inside/ work as long as they can't produce anything -- as
soon as they produce 0 items, the scheduler assumes they're done (or
at least it was like this back in the day when I tried). Tom, can
you comment on that?
2. Blocking in work() doesn't work when handling messages; those are
only handled when work is not currently executing.
The problem thus is that these are contradicting. Now, there's the
old-style message queue approach (which has become somewhat deprecated),
which does actually what you want: Offer a thread safe queue to wait on
whilst blocking the work() function. Look at the "Message Source" that
GRC has to offer, or directly at the gr::blocks::message_source class.
Now, that sounds fine, but can't accept messages from the message
passing infrastructure, so what you'd have to do is write a block with
zero in- and output streams, accepting messages, and writing to the
message queue of such an message_source.
Best regards,
Marcus
On 01.12.2015 16:45, Tom Rondeau wrote:
> On Mon, Nov 30, 2015 at 2:37 PM, Francisco Albani
> <francisco.alb...@gmail.com <mailto:francisco.alb...@gmail.com>> wrote:
>
> Hi to all.
>
> (this email subject may be inaccurate)
>
> I need a block with the following characteristics:
>
> * Input port for messages.
> * Output port for complex/float/byte/etc. stream.
> * Forecast always answers 0.
> * Work function first check the message queue. If there are no
> messages, emits zeros; if there are, it emits the samples inside
> the message.
>
>
>
> The work function should never directly interact with the message
> queue. I think there is one block that does it, but it's a hassle for
> a couple of reasons.
>
> The message handler function should receive the message and indicate
> to the work function to send it the next time it is called.
>
>
> I'm willing to write it, but first I want to hear from the people
> in the list in case this can be crafted using existing blocks or
> if this idea is deemed to fail for some reason I can't see.
>
> I need this in order to transmit N parallel burst radios using
> something like Polyphase Channel Synthesizer. The problem emerges
> when not all the transmitters have data to send and stop the other
> transmitters flows.
>
> Many thanks!
>
> Bye.
>
>
> Off the top of my head today, I can't think of something existing that
> does this, so you're likely to have to implement it yourself.
>
> Tom
>
>
>
> _______________________________________________
> 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
