# Flow graph blocking when doing 2x1 transmission

**URL:** <https://www.ruby-forum.com/t/flow-graph-blocking-when-doing-2x1-transmission/230140>\
**Category:** GNU Radio\
**Created:** [June 2, 2014, 12:35pm UTC](https://www.ruby-forum.com/t/flow-graph-blocking-when-doing-2x1-transmission/230140 "2014-06-02T12:35:58Z")\
**Posts on this page:** 10\
**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, 12:35pm UTC](https://www.ruby-forum.com/t/flow-graph-blocking-when-doing-2x1-transmission/230140/1 "2014-06-02T12:35:58Z")

</div>

Dear All,

I am using N210s with XCVR2450s. I have successfully performed 2x1  
transmission, but not I am not transmitting the same stream over both  
transmitters. One stream is constantly available, and is no problem. The  
second stream only starts later on, and thus it is blocking the flow  
graph. I tried using a mux for the second stream with some noise so that  
it will transmit noise for the first X samples, and then the second  
stream, but this doesn’t work either.

Any suggestions guys?

David

* * *

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 2, 2014, 2:18pm UTC](https://www.ruby-forum.com/t/flow-graph-blocking-when-doing-2x1-transmission/230140/2 "2014-06-02T14:18:36Z")

</div>

On 06/02/2014 12:34 PM, David Halls wrote:

> I am using N210s with XCVR2450s. I have successfully performed 2x1  
> transmission, but not I am not transmitting the same stream over both  
> transmitters. One stream is constantly available, and is no problem. The  
> second stream only starts later on, and thus it is blocking the flow  
> graph. I tried using a mux for the second stream with some noise so that  
> it will transmit noise for the first X samples, and then the second  
> stream, but this doesn’t work either.

Are you using 2 uhd sinks?

M

---

<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 2, 2014, 3:41pm UTC](https://www.ruby-forum.com/t/flow-graph-blocking-when-doing-2x1-transmission/230140/3 "2014-06-02T15:41:45Z")

</div>

Hi Martin,

How’s it going?

I am using a single UHD sink, with 2 motherboards specified, in order  
that the transmission is sync’d.

D

* * *

From: [discuss-gnuradio-bounces+david.halls=removed\_email\_address@domain.invalid](mailto:discuss-gnuradio-bounces+david.halls=removed_email_address@domain.invalid)  
[discuss-gnuradio-bounces+david.halls=removed\_email\_address@domain.invalid] on  
behalf of Martin B. [removed\_email\_address@domain.invalid]  
Sent: 02 June 2014 13:16  
To: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
Subject: Re: [Discuss-gnuradio] Flow graph blocking when doing 2x1  
transmission

On 06/02/2014 12:34 PM, David Halls wrote:

> I am using N210s with XCVR2450s. I have successfully performed 2x1  
> transmission, but not I am not transmitting the same stream over both  
> transmitters. One stream is constantly available, and is no problem. The  
> second stream only starts later on, and thus it is blocking the flow  
> graph. I tried using a mux for the second stream with some noise so that  
> it will transmit noise for the first X samples, and then the second  
> stream, but this doesn’t work either.

Are you using 2 uhd sinks?

M

* * *

Discuss-gnuradio mailing list  
[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)

> **[Discuss-gnuradio Info Page](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

---

<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 2, 2014, 4:53pm UTC](https://www.ruby-forum.com/t/flow-graph-blocking-when-doing-2x1-transmission/230140/4 "2014-06-02T16:53:07Z")

</div>

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

---

<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 2, 2014, 5:50pm UTC](https://www.ruby-forum.com/t/flow-graph-blocking-when-doing-2x1-transmission/230140/5 "2014-06-02T17:50:20Z")

</div>

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: discuss-gnuradio-bounces+david.halls=removed\_email\_address@domain.invalid  
[discuss-gnuradio-bounces+david.halls=removed\_email\_address@domain.invalid] on  
behalf of Marcus Müller [removed\_email\_address@domain.invalid]  
Sent: 02 June 2014 15:50  
To: removed\_email\_address@domain.invalid  
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  
removed\_email\_address@domain.invalid  
[https://lists.gnu.org/mailman/listinfo/discuss-gnuradio](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

---

<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 2, 2014, 6:29pm UTC](https://www.ruby-forum.com/t/flow-graph-blocking-when-doing-2x1-transmission/230140/6 "2014-06-02T18:29:14Z")

</div>

Hi Marcus,

Thanks - I require sample level timing sync. Using the external sync to  
get accurate LO frequencies is great, but not sufficient. Using a single  
UHD block with 2 motherboards gives me sample-level sync.

Thanks for the code but how are the uhd, and usrp\_sink0, usrp\_sink0  
objects obtained within my own out-of-tree block?

Also setting their time will synchronise the time registers of the two  
USRPs in the same way as using the external sync (with PPS - I have an  
octoclock-G), but don’t I need to use a ‘tx\_time’ tag (and ‘sob’, ‘eob’)  
too so that they know _when_ to transmit their respective bursts? This  
means having some communication between the two source streams so they  
can agree on a mutually agreeable tx\_time?

Regards,

David

* * *

From: Marcus Müller [removed\_email\_address@domain.invalid]  
Sent: 02 June 2014 17:16  
To: David Halls; [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
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:

> ```
> {
> 
> ```
> 
> syncing the USRPs using time stamps?  
> Greetings,
> 
> 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](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 2, 2014, 6:57pm UTC](https://www.ruby-forum.com/t/flow-graph-blocking-when-doing-2x1-transmission/230140/7 "2014-06-02T18:57:33Z")

</div>

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 [removed\_email\_address@domain.invalid]  
Sent: 02 June 2014 17:16  
To: David Halls; [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
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:

> ```
> {
> 
> ```
> 
> syncing the USRPs using time stamps?  
> Greetings,
> 
> 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](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 2, 2014, 6:17pm UTC](https://www.ruby-forum.com/t/flow-graph-blocking-when-doing-2x1-transmission/230140/8 "2014-06-02T18:17:27Z")

</div>

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

---

<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 2, 2014, 8:57pm UTC](https://www.ruby-forum.com/t/flow-graph-blocking-when-doing-2x1-transmission/230140/9 "2014-06-02T20:57:15Z")

</div>

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

---

<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 2, 2014, 7:44pm UTC](https://www.ruby-forum.com/t/flow-graph-blocking-when-doing-2x1-transmission/230140/10 "2014-06-02T19:44:08Z")

</div>

Hi David,  
On 02.06.2014 18:24, David Halls wrote:

> Hi Marcus,
> 
> Thanks - I require sample level timing sync. Using the external sync to get  
> accurate LO frequencies is great, but not sufficient. Using a single UHD block  
> with 2 motherboards gives me sample-level sync.  
> That will only be true if the USRPs are physically sharing the same time  
> reference – using a single USRP sink will not align clocks, but only  
> make sure that stream commands are issued “close after each other”,  
> leaving more than sample duration of random latency between issue and  
> execution  
> Thanks for the code but how are the uhd, and usrp\_sink0, usrp\_sink0 objects  
> obtained within my own out-of-tree block?  
> Good point! Usually, you can only do that from where you’re constructing  
> your flow graph; this is where you have the handles for both blocks.  
> You can, however, write methods (or constructors) that take shared  
> pointers to USRP sinks, which will enable you to call methods on the  
> blocks; be careful not to run into multithreading issues when doing  
> that.

> Also setting their time will synchronise the time registers of the two USRPs in  
> the same way as using the external sync (with PPS - I have an octoclock-G),  
> ah, ok, so this is where the common time ref comes from, and why using a  
> single sink synchronizes things. Cool!  
> but don’t I need to use a ‘tx\_time’ tag (and ‘sob’, ‘eob’) too so that they  
> know _when_ to transmit their respective bursts? This means having some  
> communication between the two source streams so they can agree on a mutually  
> agreeable tx\_time?  
> Well, with a common PPS pulse, you can do something like  
> usrp\_sink{0,1}.set\_time\_next\_pps(zero\_time)

and just let the usrps set the time at the rising edge of your octoclock  
PPS signal.

Then, using  
usrp\_sink{0,1}.set\_start\_time(uhd.time\_spec(x))  
you could issue the start of streaming for x seconds in the future.

Greetings,  
Marcus