# Re: Flow graph blocking when doing 2x1 transmission

**URL:** <https://www.ruby-forum.com/t/re-flow-graph-blocking-when-doing-2x1-transmission/230161>\
**Category:** GNU Radio\
**Created:** [June 2, 2014, 11:31pm UTC](https://www.ruby-forum.com/t/re-flow-graph-blocking-when-doing-2x1-transmission/230161 "2014-06-02T23:31:43Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![jason\_sam](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/7993a0/32.png) [@jason\_sam](https://www.ruby-forum.com/u/jason_sam)\
**Post date:** [June 2, 2014, 11:31pm UTC](https://www.ruby-forum.com/t/re-flow-graph-blocking-when-doing-2x1-transmission/230161/1 "2014-06-02T23:31:43Z")

</div>

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 ,removed\_email\_address@domain.invalid  
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:

> ```
> int
> out[idx] = 0;
> 
> ```
> 
> Regards,  
> “easiest” way to achieve coherence on both USRP would be a MIMO cable,
> 
> > ```
> > }
> > 
> > ```
> > 
> > * * *
> > 
> > | sample source a |------------\>| USRP |—\> [USRP1]  
> > Alternatively, what about having a block that (rate limitedly) produces

* * *

> 

* * *

> This email has been scanned for email related threats and delivered safely by  
> Mimecast.  
> For more information please visit [http://www.mimecast.com](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

---

<div class="post-metadata">

**Author:** ![divotdave](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/bbe5ce/32.png) [@divotdave](https://www.ruby-forum.com/u/divotdave)\
**Post date:** [June 3, 2014, 8:46am UTC](https://www.ruby-forum.com/t/re-flow-graph-blocking-when-doing-2x1-transmission/230161/2 "2014-06-03T08:46:06Z")

</div>

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