Re: Source Block - Flow Control

-------- Original message --------
From: Matt E.
Date:2014/10/16 22:42 (GMT+00:00)
To: John M.
Cc: David Halls ,GNURadio
Subject: Re: [Discuss-gnuradio] Source Block - Flow Control

On Thu, Oct 16, 2014 at 8:40 AM, John M.
<[email protected]mailto:[email protected]>
wrote:
I’m happy this is working for you, David. So do I understand correctly,
that the adding tx_time finally made the MIMO case work?

I’d never done burst transmission with multiple USRP outputs. I’m not
totally surprised but I wasn’t sure what would happen.

Maybe someone from Ettus can comment on this? Since UHD is trying to do
time alignment in the multi_usrp class, what happens to time alignemt in
the non-continuous-streaming case if you don’t include a tx_time tag?

Noncontinuous streaming means there is some amount of down time. If you
don’t include tx_time tags, the device doesn’t know when to start back
up again, so each antenna is going to start at a different time.

Matt

That seemed exactly the kind of behaviour I saw where sync between the
two streams was lost. Matt, can you comment on whether I need to put
dummy padding items before the first burst? to flush buffers and is
there a delicate way to do this?


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

On TX, if you need your first sample to be valid and everything settled
in
the radio, you should zero pad ahead of it. If you need your last
sample
to go out clean, you should zero pad after it. In both cases, a few
microseconds worth is usually fine. This flushes buffers and filters,
but
also gives physical devices like antenna switches to settle.

Matt

On Thu, Oct 16, 2014 at 2:46 PM, David Halls
[email protected]

Thanks Matt. is this likely to be the cause of the Us at the beginning?
How can I pad simply in GNU radio? can i add padding to every burst? if
so that seems straightforward. I can just mux some zeros in.

Also should the padding be included in the burst length?

-------- Original message --------
From: Matt E.
Date:2014/10/16 22:54 (GMT+00:00)
To: David Halls
Cc: John M. ,GNURadio
Subject: Re: [Discuss-gnuradio] Source Block - Flow Control

On TX, if you need your first sample to be valid and everything settled
in the radio, you should zero pad ahead of it. If you need your last
sample to go out clean, you should zero pad after it. In both cases, a
few microseconds worth is usually fine. This flushes buffers and
filters, but also gives physical devices like antenna switches to
settle.

Matt

On Thu, Oct 16, 2014 at 2:46 PM, David Halls
<[email protected]mailto:[email protected]>
wrote:

-------- Original message --------
From: Matt E.
Date:2014/10/16 22:42 (GMT+00:00)
To: John M.
Cc: David Halls ,GNURadio
Subject: Re: [Discuss-gnuradio] Source Block - Flow Control

On Thu, Oct 16, 2014 at 8:40 AM, John M.
<[email protected]mailto:[email protected]>
wrote:
I’m happy this is working for you, David. So do I understand correctly,
that the adding tx_time finally made the MIMO case work?

I’d never done burst transmission with multiple USRP outputs. I’m not
totally surprised but I wasn’t sure what would happen.

Maybe someone from Ettus can comment on this? Since UHD is trying to do
time alignment in the multi_usrp class, what happens to time alignemt in
the non-continuous-streaming case if you don’t include a tx_time tag?

Noncontinuous streaming means there is some amount of down time. If you
don’t include tx_time tags, the device doesn’t know when to start back
up again, so each antenna is going to start at a different time.

Matt

That seemed exactly the kind of behaviour I saw where sync between the
two streams was lost. Matt, can you comment on whether I need to put
dummy padding items before the first burst? to flush buffers and is
there a delicate way to do this?


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/trlhttp://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

You’ll probably want to make a block to do the padding, or mux in zeros.

Matt

On Thu, Oct 16, 2014 at 3:00 PM, David Halls
[email protected]