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 <marcus.muel...@ettus.com>: > 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>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 > listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > _______________________________________________ > 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
