Re: [Discuss-gnuradio] Flow graph blocking when doing 2x1 transmission

[Marcus Müller]

Hi David,

I think you got that right.
Using msg_port_register_in(..) you could set up a message port, define a
message handler, in which you set a class member (eg. d_datatosend) to
the message'd content, and in your work check whether d_datatosend is
empty or not, and in the latter case, emit that.

That's only one way to solve your non-constant streaming issue, and it's
one of the most computationally intensive, so I don't really know if my
advice was good...

Greetings,
Marcus
On 02.06.2014 23:30, David Halls wrote:
> Hi Marcus,
>
> I'm not sure if understand correctly then, how would you suggest it is 
> possible to implement your suggestion
>
> 'a block that (rate limitedly) produces zero-samples, unless data comes in on 
> a message port?'
>
> ...My new block is connected to the UHD sink - so this should consume the 
> output buffer of the block at a constant rate, and so my setup *should* work?
>
> Many thanks,
>
> David
>
>
> -------- Original message --------
> From: Marcus Müller
> Date:02/06/2014 19:56 (GMT+00:00)
> To: David Halls ,address@hidden
> Subject: Re: [Discuss-gnuradio] Flow graph blocking when doing 2x1 
> transmission
>
> Hi David,
>
> you're right, the scheduler will only call your block when out- or input
> buffer situation have changed, and there's no elegant way to coerce that.
> However, given a sink that consumes with a constant continous rate, that
> will never be a problem for a longer time.
>
> Greetings,
> Marcus
>
> On 02.06.2014 18:55, David Halls wrote:
>> Hi All, Marcus
>>
>> I have created a simple block (not yet finished) to create zeros. How do I 
>> get this to be scheduled if there are no items at the input? If I connect a 
>> source to it, then it works, if I connect my 'sample source b' to it which 
>> has no items at time zero, then the block is not scheduled.
>>
>>     void
>>     avoid_block_impl::forecast (int noutput_items, gr_vector_int 
>> &ninput_items_required)
>>     {
>>         ninput_items_required[0] = noutput_items;
>>     }
>>
>>     int
>>     avoid_block_impl::general_work (int noutput_items,
>>                        gr_vector_int &ninput_items,
>>                        gr_vector_const_void_star &input_items,
>>                        gr_vector_void_star &output_items)
>>     {
>>         const gr_complex *in = (const gr_complex *) input_items[0];
>>         gr_complex *out = (gr_complex *) output_items[0];
>>
>>                 for(int idx=0; idx < noutput_items; idx++)
>>                 {
>>                         out[idx] = 0;
>>                 }
>>
>>         // Tell runtime system how many input items we consumed on
>>         // each input stream.
>>         consume_each (noutput_items);
>>
>>         // Tell runtime system how many output items we produced.
>>         return noutput_items;
>>     }
>>
>> Regards,
>>
>> David
>> ________________________________________
>> From: Marcus Müller address@hidden
>> Sent: 02 June 2014 17:16
>> To: David Halls; address@hidden
>> Subject: Re: [Discuss-gnuradio] Flow graph blocking when doing 2x1 
>> transmission
>>
>> Hi David,
>>
>> "easiest" way to achieve coherence on both USRP would be a MIMO cable,
>> or GPSDO's.
>> That being said, depending on your definition of "sync", just setting
>> the time at both USRPs would little to some little, yet existent error.
>> This error should also occur when using the two USRPs with the same USRP
>> Sink, as long as you don't physically synchronize them. You could then
>> issue timed commands. The python code would look something like:
>>
>> zero_time = uhd.time_spec(0.0)
>> usrp_sink0.set_time_now(zero_time)
>> usrp_sink1.set_time_now(zero_time)
>>
>> If both can receive the same signal, you could synchronize on a signal
>> that both receive; that would of course make your application more
>> complex, and also needs to be done periodically, since it's physically
>> impossible to keep clocks perfectly aligned over a long time.
>>
>> Greetings,
>> Marcus
>>
>> On 02.06.2014 17:49, David Halls wrote:
>>> Hi Marcus,
>>>
>>> Yes, your diagram represents what I am trying to achieve.
>>>
>>> Using two sinks would be really nice! But I have had some problems with 
>>> achieving sync using time stamps (where as using one UHD sink is very 
>>> straightforward). For example, how do I obtain the current time from the 
>>> transmit USRPs, but from another block in the flow graph - in order to 
>>> create a tx_time with the right value? Where I have a UHD source its easy 
>>> as these output an rx_time tag...
>>>
>>> I thought that I could use
>>>
>>> ::uhd::time_spec_t
>>>     usrp_sink_impl::get_time_now(size_t mboard)
>>>     {
>>>       return _dev->get_time_now(mboard);
>>>     }
>>>
>>> but how do I get a pointer to this in other blocks in the flow graph?
>>>
>>> I like the idea of the block to creates zeros (with rate limiting), unless 
>>> there is an input signal. Will this block get scheduled even if there are 
>>> no items at its input, though? Isn't that similar to my simple idea of 
>>> using a mux between a noise source (with 0 amplitude) with sample source b?
>>>
>>> I will try to provide some more detail, although the setup is complicated 
>>> indeed and might involve explaining a lot of the background...
>>>
>>> Regards,
>>>
>>> David
>>> ________________________________________
>>> From: address@hidden address@hidden on behalf of Marcus Müller 
>>> address@hidden
>>> Sent: 02 June 2014 15:50
>>> To: address@hidden
>>> Subject: Re: [Discuss-gnuradio] Flow graph blocking when doing 2x1      
>>> transmission
>>>
>>> Hi David,
>>> Generally, this sounds like in principle, your application looks like
>>> (nb: not an actual GR flowgraph)
>>>
>>> +-----------------+             +------+
>>> | sample source a |------------>| USRP |---> [USRP1]
>>> +-----------------+             |      |
>>>                                 | sink |
>>> +-----------------+             |      |
>>> | sample source b |------------>|      |---> [USRP2]
>>> +-----------------+             +------+
>>>
>>> Let's assume a is continuous and b starts later, or bursts or the like.
>>> Can't you just split the flow graph into two independent flowgraphs,
>>> syncing the USRPs using time stamps?
>>>
>>> Alternatively, what about having a block that (rate limitedly) produces
>>> zero-samples, unless data comes in on a message port?
>>>
>>> Generally, using start-of-burst tags, the newly added command time
>>> message interface for the uhd blocks, and multiple ways to detangle your
>>> sample streams, there are many ways to solve your issues.
>>> I think it would be wise if you described your setup in a little more
>>> detail.
>>>
>>> Greetings,
>>> Marcus
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> address@hidden
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>> ________________________________
>>>
>>> NOTE: The information in this email and any attachments may be confidential 
>>> and/or legally privileged. This message may be read, copied and used only 
>>> by the intended recipient. If you are not the intended recipient, please 
>>> destroy this message, delete any copies held on your system and notify the 
>>> sender immediately.
>>>
>>> Toshiba Research Europe Limited, registered in England and Wales (2519556). 
>>> Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 
>>> 0GZ, England. Web: 
>>> www.toshiba.eu/research/trl<http://www.toshiba.eu/research/trl>
>>> ---------------------------------------------------------------------------------------
>>>  This email has been scanned for email related threats and delivered safely 
>>> by Mimecast.
>>>  For more information please visit http://www.mimecast.com
>>> ---------------------------------------------------------------------------------------
>>>
>>>
>> ________________________________
>>
>> NOTE: The information in this email and any attachments may be confidential 
>> and/or legally privileged. This message may be read, copied and used only by 
>> the intended recipient. If you are not the intended recipient, please 
>> destroy this message, delete any copies held on your system and notify the 
>> sender immediately.
>>
>> Toshiba Research Europe Limited, registered in England and Wales (2519556). 
>> Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 
>> 0GZ, England. Web: 
>> www.toshiba.eu/research/trl<http://www.toshiba.eu/research/trl>
>> ---------------------------------------------------------------------------------------
>>  This email has been scanned for email related threats and delivered safely 
>> by Mimecast.
>>  For more information please visit http://www.mimecast.com
>> ---------------------------------------------------------------------------------------
>>
>>
>
> ________________________________
>
> NOTE: The information in this email and any attachments may be confidential 
> and/or legally privileged. This message may be read, copied and used only by 
> the intended recipient. If you are not the intended recipient, please destroy 
> this message, delete any copies held on your system and notify the sender 
> immediately.
>
> Toshiba Research Europe Limited, registered in England and Wales (2519556). 
> Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
> England. Web: www.toshiba.eu/research/trl
> ---------------------------------------------------------------------------------------
>  This email has been scanned for email related threats and delivered safely 
> by Mimecast.
>  For more information please visit http://www.mimecast.com
> ---------------------------------------------------------------------------------------