discuss-gnuradio
[Top][All Lists]
Advanced

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

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


From: Martin Braun
Subject: Re: [Discuss-gnuradio] Fwd: Asynchronous source with zeros in between
Date: Sat, 9 Jan 2016 06:52:09 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0

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* <address@hidden
> <mailto: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
> <mailto: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
> <mailto: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
>>     <<mailto:address@hidden>address@hidden
>>     <mailto: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 <mailto:address@hidden>
>>     https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
>     _______________________________________________
>     Discuss-gnuradio mailing list
>     address@hidden <mailto:address@hidden>
>     https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> 
> 
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 




reply via email to

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