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

[Francisco Albani]

Line nº 40 has an unnecesary call to "max". It should be:

        n_consumed = min(n_ready, n_demanded)

---------- Forwarded message ----------
From: Francisco Albani <address@hidden>
Date: 2016-01-07 20:24 GMT-03:00
Subject: Re: [Discuss-gnuradio] Asynchronous source with zeros in between
To:
Cc: GNURadio Discussion List <address@hidden>

Today I finally wrote the first working version.

I will be very grateful if you take a look and tell me if you find anything wrong.

Highlighted code: http://pastebin.com/4fKmHgfE

Thanks and bye!

Raw code:

import numpy

import pmt

from gnuradio import gr

 

class AsyncMsgSourceC(gr.sync_block):

    """

   Transmits zeros when no messages in queue

   and their payload (complex samples) when present.

   """

    def __init__(self):

        gr.sync_block.__init__(self,

            name="async_msg_source_c",

            in_sig=None,

            out_sig=[numpy.complex64])

 

        self.ready_samples = numpy.empty((0,))

 

        self.message_port_register_in(pmt.intern('pdus'))

        self.set_msg_handler(pmt.intern('pdus'), self.msg_handler)

 

    def msg_handler(self, msg):

 

        pdu = pmt.cdr(msg)

        new_samples = pmt.to_python(pdu)

       

        self.ready_samples = numpy.concatenate((

                                self.ready_samples,

                                new_samples

                             ))

 

    def work(self, input_items, output_items):

        out = output_items[0]

 

        n_demanded = len(out)

        n_ready    = len(self.ready_samples)

 

        n_zeros = max(0, n_demanded - n_ready)

        zeros = numpy.zeros(n_zeros)

 

        n_consumed = max(0, min(n_ready, n_demanded))

        samples = self.ready_samples[0:n_consumed]

 

        out[0:n_consumed] = samples

        out[n_consumed:]  = zeros

 

        self.ready_samples = self.ready_samples[n_consumed:]

 

        # TODO: add sob/eob tags

 

        return n_demanded

2015-12-06 11:58 GMT-03:00 Marcus Müller <address@hidden>:

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 <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!

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
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio