Francisco, looks like you have a bugfix there. Can you submit a pull request?
M On 01/08/2016 02:27 PM, Francisco Albani wrote: > 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] > <mailto:[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] > <mailto:[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] > <mailto:[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 >> <<mailto:[email protected]>[email protected] >> <mailto:[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 list >> [email protected] <mailto:[email protected]> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] <mailto:[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
