Line nº 40 has an unnecesary call to "max". It should be:
n_consumed = min(n_ready, n_demanded)
---------- Forwarded message ----------
From: Francisco Albani <[email protected]>
Date: 2016-01-07 20:24 GMT-03:00
Subject: Re: [Discuss-gnuradio] Asynchronous source with zeros in between
To:
Cc: GNURadio Discussion List <[email protected]>
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 <[email protected]>:
> 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 <
> <[email protected]>[email protected]> 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
> [email protected]https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> [email protected]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
