Flow graph blocking when doing 2x1 transmission

GNU Radio
1

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

2

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

3

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
[discuss-gnuradio-bounces+david.halls=removed_email_address@domain.invalid] on
behalf of Martin B. [[email protected]]
Sent: 02 June 2014 13:16
To: [email protected]
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
[email protected]
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

4

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

5

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 [[email protected]]
Sent: 02 June 2014 15:50
To: [email protected]
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
[email protected]
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

6

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 [[email protected]]
Sent: 02 June 2014 17:16
To: David Halls; [email protected]
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

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

7

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 [[email protected]]
Sent: 02 June 2014 17:16
To: David Halls; [email protected]
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

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

8

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

9

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

10

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