[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Asynchronous source with zeros in between

From: Marcus Müller
Subject: Re: [Discuss-gnuradio] Asynchronous source with zeros in between
Date: Sun, 6 Dec 2015 15:58:30 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

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,

On 01.12.2015 16:45, Tom Rondeau wrote:
On Mon, Nov 30, 2015 at 2:37 PM, Francisco Albani <address@hidden> 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!


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.


Discuss-gnuradio mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]