Re: [Discuss-gnuradio] Source Block - Flow Control

[Jeff Long]

Use a throttle block immediately after your source block, setting the 
vector size to match your source.


- Jeff

On 10/14/2014 04:34 PM, David Halls wrote:

Dear All,

I am wondering how to add some flow control to a source block, so that
it doesn’t fire out items so quickly.

Later stages of my flow graph are slowed by various bits of processing
and combining, before transmission via USRP, with bursts being
transmitted every few seconds.

What happens is that the block fires out 1,000s of vectors, and then
seems to slow down and settle into sync with the rest of the flow graph
after a few seconds. As my source block is reading in from a Database, I
want to slow this initial rate significantly.

The block outputs vectors of bytes (v_len=144). Any ideas?

Regards,

David

---

David Halls Ph.D.

Research Engineer

Toshiba Research Europe Limited

32 Queen Square, Bristol, BS1 4ND, UK

Tel: +44 (0) 117 906 0790




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



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Source Block - Flow Control

[Jeff Long]

Should have mentioned ... set the throttle rate just slightly higher 
than what the chain would consume at steady state when all the buffers 
are filled and the USRP is transmitting. How well this works depends on 
what the rest of the chain looks like.


- Jeff

On 10/14/2014 05:52 PM, Jeff Long wrote:

Use a throttle block immediately after your source block, setting the
vector size to match your source.

- Jeff

On 10/14/2014 04:34 PM, David Halls wrote:

Dear All,

I am wondering how to add some flow control to a source block, so that
it doesn’t fire out items so quickly.

Later stages of my flow graph are slowed by various bits of processing
and combining, before transmission via USRP, with bursts being
transmitted every few seconds.

What happens is that the block fires out 1,000s of vectors, and then
seems to slow down and settle into sync with the rest of the flow graph
after a few seconds. As my source block is reading in from a Database, I
want to slow this initial rate significantly.

The block outputs vectors of bytes (v_len=144). Any ideas?

Regards,

David

---

David Halls Ph.D.

Research Engineer

Toshiba Research Europe Limited

32 Queen Square, Bristol, BS1 4ND, UK

Tel: +44 (0) 117 906 0790




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



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio






___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Source Block - Flow Control

[Matt Ettus]

Jeff,

If there is a hardware device like a USRP in the chain, then you should not
use a throttle block.  What you are seeing is the initial startup burst.
When everything starts up, all the buffers are empty, and GNU Radio will
generate data until something backs up.  Once they fill up, you are seeing
the rate settle down.  This is all normal.

If you really need to rate limit what gets requested of the database during
the initial transient (which I don't recommend), you should do that within
your source block.

Matt


On Tue, Oct 14, 2014 at 10:56 AM, Jeff Long  wrote:

> Should have mentioned ... set the throttle rate just slightly higher than
> what the chain would consume at steady state when all the buffers are
> filled and the USRP is transmitting. How well this works depends on what
> the rest of the chain looks like.
>
> - Jeff
>
>
> On 10/14/2014 05:52 PM, Jeff Long wrote:
>
>> Use a throttle block immediately after your source block, setting the
>> vector size to match your source.
>>
>> - Jeff
>>
>> On 10/14/2014 04:34 PM, David Halls wrote:
>>
>>> Dear All,
>>>
>>> I am wondering how to add some flow control to a source block, so that
>>> it doesn’t fire out items so quickly.
>>>
>>> Later stages of my flow graph are slowed by various bits of processing
>>> and combining, before transmission via USRP, with bursts being
>>> transmitted every few seconds.
>>>
>>> What happens is that the block fires out 1,000s of vectors, and then
>>> seems to slow down and settle into sync with the rest of the flow graph
>>> after a few seconds. As my source block is reading in from a Database, I
>>> want to slow this initial rate significantly.
>>>
>>> The block outputs vectors of bytes (v_len=144). Any ideas?
>>>
>>> Regards,
>>>
>>> David
>>>
>>> ---
>>>
>>> David Halls Ph.D.
>>>
>>> Research Engineer
>>>
>>> Toshiba Research Europe Limited
>>>
>>> 32 Queen Square, Bristol, BS1 4ND, UK
>>>
>>> Tel: +44 (0) 117 906 0790
>>>
>>>
>>> 
>>>
>>> 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
>>> 
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Source Block - Flow Control

[Jeff Long]

Agree the throttle it not the best solution. David - what is your 
source, and what problem are those 1000's of vectors causing at startup?


- Jeff

On 10/14/2014 06:08 PM, Matt Ettus wrote:


Jeff,

If there is a hardware device like a USRP in the chain, then you should
not use a throttle block.  What you are seeing is the initial startup
burst.  When everything starts up, all the buffers are empty, and GNU
Radio will generate data until something backs up.  Once they fill up,
you are seeing the rate settle down.  This is all normal.

If you really need to rate limit what gets requested of the database
during the initial transient (which I don't recommend), you should do
that within your source block.

Matt


On Tue, Oct 14, 2014 at 10:56 AM, Jeff Long mailto:willco...@gmail.com>> wrote:

Should have mentioned ... set the throttle rate just slightly higher
than what the chain would consume at steady state when all the
buffers are filled and the USRP is transmitting. How well this works
depends on what the rest of the chain looks like.

- Jeff


On 10/14/2014 05:52 PM, Jeff Long wrote:

Use a throttle block immediately after your source block,
setting the
vector size to match your source.

- Jeff

On 10/14/2014 04:34 PM, David Halls wrote:

Dear All,

I am wondering how to add some flow control to a source
block, so that
it doesn’t fire out items so quickly.

Later stages of my flow graph are slowed by various bits of
processing
and combining, before transmission via USRP, with bursts being
transmitted every few seconds.

What happens is that the block fires out 1,000s of vectors,
and then
seems to slow down and settle into sync with the rest of the
flow graph
after a few seconds. As my source block is reading in from a
Database, I
want to slow this initial rate significantly.

The block outputs vectors of bytes (v_len=144). Any ideas?

Regards,

David

--__--__---

David Halls Ph.D.

Research Engineer

Toshiba Research Europe Limited

32 Queen Square, Bristol, BS1 4ND, UK

Tel: +44 (0) 117 906 0790




--__--__

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

--__--__


_
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org 
https://lists.gnu.org/mailman/__listinfo/discuss-gnuradio





_
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org 
https://lists.gnu.org/mailman/__listinfo/discuss-gnuradio






___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Source Block - Flow Control

[David Halls]

Thanks guys!

I am transmitting data from a database, which is inserted by some sensors. The 
network is contains multiple relay hops and the processing at each relay is 
highly complex therefore the system o's not real time. The source transmits a 
data burst every 0.5 secs.

The issue is that the initial burst reads frantically and fills the buffers 
with the same value,  which then takes ages to propagate through the system.

does that make any sense?


 Original message 
From: Jeff Long
Date:2014/10/14 20:20 (GMT+00:00)
To: Matt Ettus
Cc: GNURadio
Subject: Re: [Discuss-gnuradio] Source Block - Flow Control

Agree the throttle it not the best solution. David - what is your
source, and what problem are those 1000's of vectors causing at startup?

- Jeff

On 10/14/2014 06:08 PM, Matt Ettus wrote:
>
> Jeff,
>
> If there is a hardware device like a USRP in the chain, then you should
> not use a throttle block.  What you are seeing is the initial startup
> burst.  When everything starts up, all the buffers are empty, and GNU
> Radio will generate data until something backs up.  Once they fill up,
> you are seeing the rate settle down.  This is all normal.
>
> If you really need to rate limit what gets requested of the database
> during the initial transient (which I don't recommend), you should do
> that within your source block.
>
> Matt
>
>
> On Tue, Oct 14, 2014 at 10:56 AM, Jeff Long  <mailto:willco...@gmail.com>> wrote:
>
> Should have mentioned ... set the throttle rate just slightly higher
> than what the chain would consume at steady state when all the
> buffers are filled and the USRP is transmitting. How well this works
> depends on what the rest of the chain looks like.
>
> - Jeff
>
>
> On 10/14/2014 05:52 PM, Jeff Long wrote:
>
> Use a throttle block immediately after your source block,
> setting the
> vector size to match your source.
>
> - Jeff
>
> On 10/14/2014 04:34 PM, David Halls wrote:
>
> Dear All,
>
> I am wondering how to add some flow control to a source
> block, so that
> it doesn’t fire out items so quickly.
>
> Later stages of my flow graph are slowed by various bits of
> processing
> and combining, before transmission via USRP, with bursts being
> transmitted every few seconds.
>
> What happens is that the block fires out 1,000s of vectors,
> and then
> seems to slow down and settle into sync with the rest of the
> flow graph
> after a few seconds. As my source block is reading in from a
> Database, I
> want to slow this initial rate significantly.
>
> The block outputs vectors of bytes (v_len=144). Any ideas?
>
> Regards,
>
> David
>
> 
> --__--__---
>
> David Halls Ph.D.
>
> Research Engineer
>
> Toshiba Research Europe Limited
>
> 32 Queen Square, Bristol, BS1 4ND, UK
>
> Tel: +44 (0) 117 906 0790
> 
>
>
> 
> --__--__
>
> 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>
> <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
> 
> --__--__
>
>
> _
> Discuss-gnuradio mailing list
> Discuss-gnura

Re: [Discuss-gnuradio] Source Block - Flow Control

[David Halls]

Matt,

In my source block I can limit the calls to the DB ok, but I will still need to 
output something from the block, won't I? This will then propagate and fill the 
buffers?

Thanks,

David


 Original message 
From: Matt Ettus
Date:2014/10/14 19:09 (GMT+00:00)
To: Jeff Long
Cc: GNURadio
Subject: Re: [Discuss-gnuradio] Source Block - Flow Control


Jeff,

If there is a hardware device like a USRP in the chain, then you should not use 
a throttle block.  What you are seeing is the initial startup burst.  When 
everything starts up, all the buffers are empty, and GNU Radio will generate 
data until something backs up.  Once they fill up, you are seeing the rate 
settle down.  This is all normal.

If you really need to rate limit what gets requested of the database during the 
initial transient (which I don't recommend), you should do that within your 
source block.

Matt


On Tue, Oct 14, 2014 at 10:56 AM, Jeff Long 
mailto:willco...@gmail.com>> wrote:
Should have mentioned ... set the throttle rate just slightly higher than what 
the chain would consume at steady state when all the buffers are filled and the 
USRP is transmitting. How well this works depends on what the rest of the chain 
looks like.

- Jeff


On 10/14/2014 05:52 PM, Jeff Long wrote:
Use a throttle block immediately after your source block, setting the
vector size to match your source.

- Jeff

On 10/14/2014 04:34 PM, David Halls wrote:
Dear All,

I am wondering how to add some flow control to a source block, so that
it doesn’t fire out items so quickly.

Later stages of my flow graph are slowed by various bits of processing
and combining, before transmission via USRP, with bursts being
transmitted every few seconds.

What happens is that the block fires out 1,000s of vectors, and then
seems to slow down and settle into sync with the rest of the flow graph
after a few seconds. As my source block is reading in from a Database, I
want to slow this initial rate significantly.

The block outputs vectors of bytes (v_len=144). Any ideas?

Regards,

David

---

David Halls Ph.D.

Research Engineer

Toshiba Research Europe Limited

32 Queen Square, Bristol, BS1 4ND, UK

Tel: +44 (0) 117 906 0790




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



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org<mailto:Discuss-gnuradio@gnu.org>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org<mailto:Discuss-gnuradio@gnu.org>
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
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Source Block - Flow Control

[Matt Ettus]

No, if you don't have anything useful to output in a source block, you can
(and should) block while you wait.  If you have something useful, but not
as much as requested, you can output only what you have.  There is no need
to generate filler in GNU Radio.

Matt


On Tue, Oct 14, 2014 at 2:43 PM, David Halls 
wrote:

>  Matt,
>
>  In my source block I can limit the calls to the DB ok, but I will still
> need to output something from the block, won't I? This will then propagate
> and fill the buffers?
>
>  Thanks,
>
>  David
>
>
>  Original message 
> From: Matt Ettus
> Date:2014/10/14 19:09 (GMT+00:00)
> To: Jeff Long
> Cc: GNURadio
> Subject: Re: [Discuss-gnuradio] Source Block - Flow Control
>
>
> Jeff,
>
>  If there is a hardware device like a USRP in the chain, then you should
> not use a throttle block.  What you are seeing is the initial startup
> burst.  When everything starts up, all the buffers are empty, and GNU Radio
> will generate data until something backs up.  Once they fill up, you are
> seeing the rate settle down.  This is all normal.
>
>  If you really need to rate limit what gets requested of the database
> during the initial transient (which I don't recommend), you should do that
> within your source block.
>
>  Matt
>
>
> On Tue, Oct 14, 2014 at 10:56 AM, Jeff Long  wrote:
>
>> Should have mentioned ... set the throttle rate just slightly higher than
>> what the chain would consume at steady state when all the buffers are
>> filled and the USRP is transmitting. How well this works depends on what
>> the rest of the chain looks like.
>>
>> - Jeff
>>
>>
>> On 10/14/2014 05:52 PM, Jeff Long wrote:
>>
>>> Use a throttle block immediately after your source block, setting the
>>> vector size to match your source.
>>>
>>> - Jeff
>>>
>>> On 10/14/2014 04:34 PM, David Halls wrote:
>>>
>>>> Dear All,
>>>>
>>>> I am wondering how to add some flow control to a source block, so that
>>>> it doesn’t fire out items so quickly.
>>>>
>>>> Later stages of my flow graph are slowed by various bits of processing
>>>> and combining, before transmission via USRP, with bursts being
>>>> transmitted every few seconds.
>>>>
>>>> What happens is that the block fires out 1,000s of vectors, and then
>>>> seems to slow down and settle into sync with the rest of the flow graph
>>>> after a few seconds. As my source block is reading in from a Database, I
>>>> want to slow this initial rate significantly.
>>>>
>>>> The block outputs vectors of bytes (v_len=144). Any ideas?
>>>>
>>>> Regards,
>>>>
>>>> David
>>>>
>>>> ---
>>>>
>>>> David Halls Ph.D.
>>>>
>>>> Research Engineer
>>>>
>>>> Toshiba Research Europe Limited
>>>>
>>>> 32 Queen Square, Bristol, BS1 4ND, UK
>>>>
>>>> Tel: +44 (0) 117 906 0790
>>>>
>>>>
>>>> 
>>>> 
>>>>
>>>> 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
>>>> 
>>>> 
>>>>
>>>>
>>>> ___
>>>> Discuss-gnuradio mailing list
>>>> Discuss-gnuradio@gnu.org
>>>> https://lists.gnu.org/mailman/

Re: [Discuss-gnuradio] Source Block - Flow Control

[David Halls]

That sounds promising. The only thing is that the data *is* valid from time 
zero, but I just want to send the values from my source block, say once per 
second.

What can I use to block in my block, just not produce any items for some period 
of time or a number of calls?  and is there anyway to know when I can stop 
blocking? What will fill the buffers further down the chain?

thanks,

David


 Original message 
From: Matt Ettus
Date:2014/10/14 22:56 (GMT+00:00)
To: David Halls
Cc: Jeff Long ,GNURadio
Subject: Re: [Discuss-gnuradio] Source Block - Flow Control


No, if you don't have anything useful to output in a source block, you can (and 
should) block while you wait.  If you have something useful, but not as much as 
requested, you can output only what you have.  There is no need to generate 
filler in GNU Radio.

Matt


On Tue, Oct 14, 2014 at 2:43 PM, David Halls 
mailto:david.ha...@toshiba-trel.com>> wrote:
Matt,

In my source block I can limit the calls to the DB ok, but I will still need to 
output something from the block, won't I? This will then propagate and fill the 
buffers?

Thanks,

David


 Original message 
From: Matt Ettus
Date:2014/10/14 19:09 (GMT+00:00)
To: Jeff Long
Cc: GNURadio
Subject: Re: [Discuss-gnuradio] Source Block - Flow Control


Jeff,

If there is a hardware device like a USRP in the chain, then you should not use 
a throttle block.  What you are seeing is the initial startup burst.  When 
everything starts up, all the buffers are empty, and GNU Radio will generate 
data until something backs up.  Once they fill up, you are seeing the rate 
settle down.  This is all normal.

If you really need to rate limit what gets requested of the database during the 
initial transient (which I don't recommend), you should do that within your 
source block.

Matt


On Tue, Oct 14, 2014 at 10:56 AM, Jeff Long 
mailto:willco...@gmail.com>> wrote:
Should have mentioned ... set the throttle rate just slightly higher than what 
the chain would consume at steady state when all the buffers are filled and the 
USRP is transmitting. How well this works depends on what the rest of the chain 
looks like.

- Jeff


On 10/14/2014 05:52 PM, Jeff Long wrote:
Use a throttle block immediately after your source block, setting the
vector size to match your source.

- Jeff

On 10/14/2014 04:34 PM, David Halls wrote:
Dear All,

I am wondering how to add some flow control to a source block, so that
it doesn’t fire out items so quickly.

Later stages of my flow graph are slowed by various bits of processing
and combining, before transmission via USRP, with bursts being
transmitted every few seconds.

What happens is that the block fires out 1,000s of vectors, and then
seems to slow down and settle into sync with the rest of the flow graph
after a few seconds. As my source block is reading in from a Database, I
want to slow this initial rate significantly.

The block outputs vectors of bytes (v_len=144). Any ideas?

Regards,

David

---

David Halls Ph.D.

Research Engineer

Toshiba Research Europe Limited

32 Queen Square, Bristol, BS1 4ND, UK

Tel: +44 (0) 117 906 0790




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



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org<mailto:Discuss-gnuradio@gnu.org>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org<mailto:Discuss-gnuradio@gnu.org>
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 Wale

Re: [Discuss-gnuradio] Source Block - Flow Control

[John Malsbury]

David,

Perhaps you can use an async message to trigger the blocks output?

In some applications that require filler between valid data frames, I've
seen people throttle based off of the number and size of received messages
at the USRP.
-John


On Tue, Oct 14, 2014 at 3:02 PM, David Halls 
wrote:

>  That sounds promising. The only thing is that the data *is* valid from
> time zero, but I just want to send the values from my source block, say
> once per second.
>
>  What can I use to block in my block, just not produce any items for some
> period of time or a number of calls?  and is there anyway to know when I
> can stop blocking? What will fill the buffers further down the chain?
>
>  thanks,
>
>  David
>
>
>  Original message 
> From: Matt Ettus
> Date:2014/10/14 22:56 (GMT+00:00)
> To: David Halls
> Cc: Jeff Long ,GNURadio
> Subject: Re: [Discuss-gnuradio] Source Block - Flow Control
>
>
> No, if you don't have anything useful to output in a source block, you can
> (and should) block while you wait.  If you have something useful, but not
> as much as requested, you can output only what you have.  There is no need
> to generate filler in GNU Radio.
>
>  Matt
>
>
> On Tue, Oct 14, 2014 at 2:43 PM, David Halls  > wrote:
>
>> Matt,
>>
>>  In my source block I can limit the calls to the DB ok, but I will still
>> need to output something from the block, won't I? This will then propagate
>> and fill the buffers?
>>
>>  Thanks,
>>
>>  David
>>
>>
>>  Original message 
>> From: Matt Ettus
>> Date:2014/10/14 19:09 (GMT+00:00)
>> To: Jeff Long
>> Cc: GNURadio
>> Subject: Re: [Discuss-gnuradio] Source Block - Flow Control
>>
>>
>> Jeff,
>>
>>  If there is a hardware device like a USRP in the chain, then you should
>> not use a throttle block.  What you are seeing is the initial startup
>> burst.  When everything starts up, all the buffers are empty, and GNU Radio
>> will generate data until something backs up.  Once they fill up, you are
>> seeing the rate settle down.  This is all normal.
>>
>>  If you really need to rate limit what gets requested of the database
>> during the initial transient (which I don't recommend), you should do that
>> within your source block.
>>
>>  Matt
>>
>>
>> On Tue, Oct 14, 2014 at 10:56 AM, Jeff Long  wrote:
>>
>>> Should have mentioned ... set the throttle rate just slightly higher
>>> than what the chain would consume at steady state when all the buffers are
>>> filled and the USRP is transmitting. How well this works depends on what
>>> the rest of the chain looks like.
>>>
>>> - Jeff
>>>
>>>
>>> On 10/14/2014 05:52 PM, Jeff Long wrote:
>>>
>>>> Use a throttle block immediately after your source block, setting the
>>>> vector size to match your source.
>>>>
>>>> - Jeff
>>>>
>>>> On 10/14/2014 04:34 PM, David Halls wrote:
>>>>
>>>>> Dear All,
>>>>>
>>>>> I am wondering how to add some flow control to a source block, so that
>>>>> it doesn’t fire out items so quickly.
>>>>>
>>>>> Later stages of my flow graph are slowed by various bits of processing
>>>>> and combining, before transmission via USRP, with bursts being
>>>>> transmitted every few seconds.
>>>>>
>>>>> What happens is that the block fires out 1,000s of vectors, and then
>>>>> seems to slow down and settle into sync with the rest of the flow graph
>>>>> after a few seconds. As my source block is reading in from a Database,
>>>>> I
>>>>> want to slow this initial rate significantly.
>>>>>
>>>>> The block outputs vectors of bytes (v_len=144). Any ideas?
>>>>>
>>>>> Regards,
>>>>>
>>>>> David
>>>>>
>>>>> ---
>>>>>
>>>>> David Halls Ph.D.
>>>>>
>>>>> Research Engineer
>>>>>
>>>>> Toshiba Research Europe Limited
>>>>>
>>>>> 32 Queen Square, Bristol, BS1 4ND, UK
>>>>>
>>>>> Tel: +44 (0) 117 906 0790
>>>>>
>>>>>
>>>>> 
>>>>> 
>

Re: [Discuss-gnuradio] Source Block - Flow Control

[David Halls]

Hi John,

Nice to hear from you.

Perhaps in a similar fashion to Martin's HPD block; I can pass a message back 
from later in the flow graph to indicate when to release a packet from the 
source?

David


 Original message 
From: John Malsbury
Date:2014/10/14 23:08 (GMT+00:00)
To: David Halls
Cc: Matt Ettus ,GNURadio
Subject: Re: [Discuss-gnuradio] Source Block - Flow Control

David,

Perhaps you can use an async message to trigger the blocks output?

In some applications that require filler between valid data frames, I've seen 
people throttle based off of the number and size of received messages at the 
USRP.

-John


On Tue, Oct 14, 2014 at 3:02 PM, David Halls 
mailto:david.ha...@toshiba-trel.com>> wrote:
That sounds promising. The only thing is that the data *is* valid from time 
zero, but I just want to send the values from my source block, say once per 
second.

What can I use to block in my block, just not produce any items for some period 
of time or a number of calls?  and is there anyway to know when I can stop 
blocking? What will fill the buffers further down the chain?

thanks,

David


 Original message 
From: Matt Ettus
Date:2014/10/14 22:56 (GMT+00:00)
To: David Halls
Cc: Jeff Long ,GNURadio
Subject: Re: [Discuss-gnuradio] Source Block - Flow Control


No, if you don't have anything useful to output in a source block, you can (and 
should) block while you wait.  If you have something useful, but not as much as 
requested, you can output only what you have.  There is no need to generate 
filler in GNU Radio.

Matt


On Tue, Oct 14, 2014 at 2:43 PM, David Halls 
mailto:david.ha...@toshiba-trel.com>> wrote:
Matt,

In my source block I can limit the calls to the DB ok, but I will still need to 
output something from the block, won't I? This will then propagate and fill the 
buffers?

Thanks,

David


 Original message 
From: Matt Ettus
Date:2014/10/14 19:09 (GMT+00:00)
To: Jeff Long
Cc: GNURadio
Subject: Re: [Discuss-gnuradio] Source Block - Flow Control


Jeff,

If there is a hardware device like a USRP in the chain, then you should not use 
a throttle block.  What you are seeing is the initial startup burst.  When 
everything starts up, all the buffers are empty, and GNU Radio will generate 
data until something backs up.  Once they fill up, you are seeing the rate 
settle down.  This is all normal.

If you really need to rate limit what gets requested of the database during the 
initial transient (which I don't recommend), you should do that within your 
source block.

Matt


On Tue, Oct 14, 2014 at 10:56 AM, Jeff Long 
mailto:willco...@gmail.com>> wrote:
Should have mentioned ... set the throttle rate just slightly higher than what 
the chain would consume at steady state when all the buffers are filled and the 
USRP is transmitting. How well this works depends on what the rest of the chain 
looks like.

- Jeff


On 10/14/2014 05:52 PM, Jeff Long wrote:
Use a throttle block immediately after your source block, setting the
vector size to match your source.

- Jeff

On 10/14/2014 04:34 PM, David Halls wrote:
Dear All,

I am wondering how to add some flow control to a source block, so that
it doesn’t fire out items so quickly.

Later stages of my flow graph are slowed by various bits of processing
and combining, before transmission via USRP, with bursts being
transmitted every few seconds.

What happens is that the block fires out 1,000s of vectors, and then
seems to slow down and settle into sync with the rest of the flow graph
after a few seconds. As my source block is reading in from a Database, I
want to slow this initial rate significantly.

The block outputs vectors of bytes (v_len=144). Any ideas?

Regards,

David

---

David Halls Ph.D.

Research Engineer

Toshiba Research Europe Limited

32 Queen Square, Bristol, BS1 4ND, UK

Tel: +44 (0) 117 906 0790




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



___
Discuss-gnuradio mai

Re: [Discuss-gnuradio] Source Block - Flow Control

[John Malsbury]

In the implementation I have in mind, the upstream logic didn't make
decisions on when the data generating block should generate data per se...
Instead, the upstream block provided feedback on the number of packets
received by the USRP (via the old async message block).  With this feedback
and knowledge of the interpolation steps between itself and the USRP, the
data generating block could throttle its own output to achieve a specified
latency [on the order of 10's of ms].

I think using a simpler scheme of triggering with an async message would be
a more convenient place to start though... What do you think, David?

-John

On Tue, Oct 14, 2014 at 3:23 PM, David Halls 
wrote:

>  Hi John,
>
>  Nice to hear from you.
>
>  Perhaps in a similar fashion to Martin's HPD block; I can pass a message
> back from later in the flow graph to indicate when to release a packet from
> the source?
>
>  David
>
>
>  Original message 
> From: John Malsbury
> Date:2014/10/14 23:08 (GMT+00:00)
> To: David Halls
> Cc: Matt Ettus ,GNURadio
> Subject: Re: [Discuss-gnuradio] Source Block - Flow Control
>
>   David,
>
> Perhaps you can use an async message to trigger the blocks output?
>
> In some applications that require filler between valid data frames, I've
> seen people throttle based off of the number and size of received messages
> at the USRP.
>  -John
>
>
> On Tue, Oct 14, 2014 at 3:02 PM, David Halls  > wrote:
>
>> That sounds promising. The only thing is that the data *is* valid from
>> time zero, but I just want to send the values from my source block, say
>> once per second.
>>
>>  What can I use to block in my block, just not produce any items for
>> some period of time or a number of calls?  and is there anyway to know when
>> I can stop blocking? What will fill the buffers further down the chain?
>>
>>  thanks,
>>
>>  David
>>
>>
>> ---- Original message 
>> From: Matt Ettus
>>   Date:2014/10/14 22:56 (GMT+00:00)
>> To: David Halls
>> Cc: Jeff Long ,GNURadio
>> Subject: Re: [Discuss-gnuradio] Source Block - Flow Control
>>
>>
>> No, if you don't have anything useful to output in a source block, you
>> can (and should) block while you wait.  If you have something useful, but
>> not as much as requested, you can output only what you have.  There is no
>> need to generate filler in GNU Radio.
>>
>>  Matt
>>
>>
>> On Tue, Oct 14, 2014 at 2:43 PM, David Halls <
>> david.ha...@toshiba-trel.com> wrote:
>>
>>> Matt,
>>>
>>>  In my source block I can limit the calls to the DB ok, but I will
>>> still need to output something from the block, won't I? This will then
>>> propagate and fill the buffers?
>>>
>>>  Thanks,
>>>
>>>  David
>>>
>>>
>>>  Original message 
>>> From: Matt Ettus
>>> Date:2014/10/14 19:09 (GMT+00:00)
>>> To: Jeff Long
>>> Cc: GNURadio
>>> Subject: Re: [Discuss-gnuradio] Source Block - Flow Control
>>>
>>>
>>> Jeff,
>>>
>>>  If there is a hardware device like a USRP in the chain, then you
>>> should not use a throttle block.  What you are seeing is the initial
>>> startup burst.  When everything starts up, all the buffers are empty, and
>>> GNU Radio will generate data until something backs up.  Once they fill up,
>>> you are seeing the rate settle down.  This is all normal.
>>>
>>>  If you really need to rate limit what gets requested of the database
>>> during the initial transient (which I don't recommend), you should do that
>>> within your source block.
>>>
>>>  Matt
>>>
>>>
>>> On Tue, Oct 14, 2014 at 10:56 AM, Jeff Long  wrote:
>>>
>>>> Should have mentioned ... set the throttle rate just slightly higher
>>>> than what the chain would consume at steady state when all the buffers are
>>>> filled and the USRP is transmitting. How well this works depends on what
>>>> the rest of the chain looks like.
>>>>
>>>> - Jeff
>>>>
>>>>
>>>> On 10/14/2014 05:52 PM, Jeff Long wrote:
>>>>
>>>>> Use a throttle block immediately after your source block, setting the
>>>>> vector size to match your source.
>>>>>
>>>>> - Jeff
>>>>>
>>>>> On 10/14/2014 04:34 PM, David Halls wrote:
>>>>>
>>>>>&g

Re: [Discuss-gnuradio] Source Block - Flow Control

[Marcus Müller]

Hi David,

since you should be blocking, just do the following in your work
1. sleep till the next full second
2. save timestamp to check if you have already generated output this second
3. generate output

If you want so, this is basically "throttle as a source". The "sleep" is
fairly inaccurate compared to things like hardware clocks, but since you
most likely have something like a USRP transmitting bursts, this won't
be a problem.

Typically, GNU Radio's packet generators take asynchronous messages and
turn them into streams. I'd say it's easier for you to take your
database source and instead of generating throttled samples just sending
a message once in a while -- it also fits the idea of item streams being
more continuous from a user's perspective quite nicely, so I fully agree
with John.

Greetings,
Marcus

On 15.10.2014 00:02, David Halls wrote:
> That sounds promising. The only thing is that the data *is* valid from time 
> zero, but I just want to send the values from my source block, say once per 
> second.
>
> What can I use to block in my block, just not produce any items for some 
> period of time or a number of calls?  and is there anyway to know when I can 
> stop blocking? What will fill the buffers further down the chain?
>
> thanks,
>
> David
>
>
>  Original message 
> From: Matt Ettus
> Date:2014/10/14 22:56 (GMT+00:00)
> To: David Halls
> Cc: Jeff Long ,GNURadio
> Subject: Re: [Discuss-gnuradio] Source Block - Flow Control
>
>
> No, if you don't have anything useful to output in a source block, you can 
> (and should) block while you wait.  If you have something useful, but not as 
> much as requested, you can output only what you have.  There is no need to 
> generate filler in GNU Radio.
>
> Matt
>
>
> On Tue, Oct 14, 2014 at 2:43 PM, David Halls 
> mailto:david.ha...@toshiba-trel.com>> wrote:
> Matt,
>
> In my source block I can limit the calls to the DB ok, but I will still need 
> to output something from the block, won't I? This will then propagate and 
> fill the buffers?
>
> Thanks,
>
> David
>
>
>  Original message 
> From: Matt Ettus
> Date:2014/10/14 19:09 (GMT+00:00)
> To: Jeff Long
> Cc: GNURadio
> Subject: Re: [Discuss-gnuradio] Source Block - Flow Control
>
>
> Jeff,
>
> If there is a hardware device like a USRP in the chain, then you should not 
> use a throttle block.  What you are seeing is the initial startup burst.  
> When everything starts up, all the buffers are empty, and GNU Radio will 
> generate data until something backs up.  Once they fill up, you are seeing 
> the rate settle down.  This is all normal.
>
> If you really need to rate limit what gets requested of the database during 
> the initial transient (which I don't recommend), you should do that within 
> your source block.
>
> Matt
>
>
> On Tue, Oct 14, 2014 at 10:56 AM, Jeff Long 
> mailto:willco...@gmail.com>> wrote:
> Should have mentioned ... set the throttle rate just slightly higher than 
> what the chain would consume at steady state when all the buffers are filled 
> and the USRP is transmitting. How well this works depends on what the rest of 
> the chain looks like.
>
> - Jeff
>
>
> On 10/14/2014 05:52 PM, Jeff Long wrote:
> Use a throttle block immediately after your source block, setting the
> vector size to match your source.
>
> - Jeff
>
> On 10/14/2014 04:34 PM, David Halls wrote:
> Dear All,
>
> I am wondering how to add some flow control to a source block, so that
> it doesn't fire out items so quickly.
>
> Later stages of my flow graph are slowed by various bits of processing
> and combining, before transmission via USRP, with bursts being
> transmitted every few seconds.
>
> What happens is that the block fires out 1,000s of vectors, and then
> seems to slow down and settle into sync with the rest of the flow graph
> after a few seconds. As my source block is reading in from a Database, I
> want to slow this initial rate significantly.
>
> The block outputs vectors of bytes (v_len=144). Any ideas?
>
> Regards,
>
> David
>
> ---
>
> David Halls Ph.D.
>
> Research Engineer
>
> Toshiba Research Europe Limited
>
> 32 Queen Square, Bristol, BS1 4ND, UK
>
> Tel: +44 (0) 117 906 0790
>
>
> 
>
> NOTE: The information in this email and any attachments may be
> confidential and/or legally privileged. This message may be read, co

Re: [Discuss-gnuradio] Source Block - Flow Control

[David Halls]

Hi John,

I have been trying at this all day! Not familiar with the async message stuff, 
I have tried putting ‘sleep()’ in the source block, I have tried a throttle 
outside it and even discarding the first X items just before the UHD sink to 
flush the buffer away.

This all causes weird underflows and things at the USRP and results in a 
horrible looking constellation at the RX (I am transmitting 2x1 MISO which 
requires perfect TX sync). This is exactly the behaviour, I think, that Matt 
warned of!!

Could you give me a bit more of an idea of how to even do the simpler idea, 
that I had thought of… I need to basically trigger the source at certain 
intervals. How does the message queue interact with the block, does the program 
flow jump to ‘parse_header_data_msg()’ automatically when a message arrives?

DH

From: John Malsbury [mailto:jmalsbury.perso...@gmail.com]
Sent: 14 October 2014 23:42
To: David Halls
Cc: Matt Ettus; GNURadio
Subject: Re: [Discuss-gnuradio] Source Block - Flow Control

In the implementation I have in mind, the upstream logic didn't make decisions 
on when the data generating block should generate data per se...  Instead, the 
upstream block provided feedback on the number of packets received by the USRP 
(via the old async message block).  With this feedback and knowledge of the 
interpolation steps between itself and the USRP, the data generating block 
could throttle its own output to achieve a specified latency [on the order of 
10's of ms].
I think using a simpler scheme of triggering with an async message would be a 
more convenient place to start though... What do you think, David?

-John

On Tue, Oct 14, 2014 at 3:23 PM, David Halls 
mailto:david.ha...@toshiba-trel.com>> wrote:
Hi John,

Nice to hear from you.

Perhaps in a similar fashion to Martin's HPD block; I can pass a message back 
from later in the flow graph to indicate when to release a packet from the 
source?

David

 Original message 
From: John Malsbury
Date:2014/10/14 23:08 (GMT+00:00)
To: David Halls
Cc: Matt Ettus ,GNURadio
Subject: Re: [Discuss-gnuradio] Source Block - Flow Control

David,

Perhaps you can use an async message to trigger the blocks output?

In some applications that require filler between valid data frames, I've seen 
people throttle based off of the number and size of received messages at the 
USRP.
-John


On Tue, Oct 14, 2014 at 3:02 PM, David Halls 
mailto:david.ha...@toshiba-trel.com>> wrote:
That sounds promising. The only thing is that the data *is* valid from time 
zero, but I just want to send the values from my source block, say once per 
second.

What can I use to block in my block, just not produce any items for some period 
of time or a number of calls?  and is there anyway to know when I can stop 
blocking? What will fill the buffers further down the chain?

thanks,

David

 Original message 
From: Matt Ettus
Date:2014/10/14 22:56 (GMT+00:00)
To: David Halls
Cc: Jeff Long ,GNURadio
Subject: Re: [Discuss-gnuradio] Source Block - Flow Control


No, if you don't have anything useful to output in a source block, you can (and 
should) block while you wait.  If you have something useful, but not as much as 
requested, you can output only what you have.  There is no need to generate 
filler in GNU Radio.

Matt


On Tue, Oct 14, 2014 at 2:43 PM, David Halls 
mailto:david.ha...@toshiba-trel.com>> wrote:
Matt,

In my source block I can limit the calls to the DB ok, but I will still need to 
output something from the block, won't I? This will then propagate and fill the 
buffers?

Thanks,

David

 Original message 
From: Matt Ettus
Date:2014/10/14 19:09 (GMT+00:00)
To: Jeff Long
Cc: GNURadio
Subject: Re: [Discuss-gnuradio] Source Block - Flow Control


Jeff,

If there is a hardware device like a USRP in the chain, then you should not use 
a throttle block.  What you are seeing is the initial startup burst.  When 
everything starts up, all the buffers are empty, and GNU Radio will generate 
data until something backs up.  Once they fill up, you are seeing the rate 
settle down.  This is all normal.

If you really need to rate limit what gets requested of the database during the 
initial transient (which I don't recommend), you should do that within your 
source block.

Matt


On Tue, Oct 14, 2014 at 10:56 AM, Jeff Long 
mailto:willco...@gmail.com>> wrote:
Should have mentioned ... set the throttle rate just slightly higher than what 
the chain would consume at steady state when all the buffers are filled and the 
USRP is transmitting. How well this works depends on what the rest of the chain 
looks like.

- Jeff


On 10/14/2014 05:52 PM, Jeff Long wrote:
Use a throttle block immediately after your source block, setting the
vector size to match your source.

- Jeff

On 10/14/2014 04:34 PM, David Halls wrote:
Dear All,

I am wondering how to add some flow control to a source 

Re: [Discuss-gnuradio] Source Block - Flow Control

[John Malsbury]

H.. I've never done burst transmissions with a 2x MIMO case.  That may
or may not put a minor wrinkle in things.  Let's go for the gusto and try
this anyway...

(or were you not looking for a burst transmission?)

This assumes you're using a relatively recent (past couple months?) build
of UHD and GR.

   1. Produce some data as a PDU.  The quickest is to use a message strobe
   into a random PDU generator.  If you want data you control, use a message
   strobe with something like this as the message value:


   pmt.cons(pmt.to_pmt({}),pmt.init_u8vector(payload_size,[0x55]*payload_size))

   Of course, you'd ultimately replace this fixed or random data with your
   own PDU-producing block.  Or maybe use some clever python inside or outside
   the flowgraph.

   2. Use PDU-to-stream block, make sure the length tag name matches
   whatever UHD is using downstream (this is a parameter in the uhd sink now).

   3. Put that stream through your modulator.

   4. I think there's a block that multiplies the value of the length in
   the length tag.  set this to the interpolation factor of your modulator and
   put it somewhere in the chain.  If this block does not have one, borrow the
   one from gr-mac.  "burst_tagger"
   <https://github.com/jmalsbury/gr-mac/blob/master/lib/burst_tagger_impl.cc>

In summary:

   *Message Strobe -> Random PDU -> PDU to Stream -> Modulator ->
[see how the constellation works]*

Give it a shot.  If it doesnt work, give a brief try with the SISO case.

You'll want to add some leading/trailing samples to flush FIR-filters and
such for the full frame to get out of the USRP unscathed.  We can address
this next...
-John

On Wed, Oct 15, 2014 at 11:47 AM, David Halls 
wrote:

>  Hi John,
>
>
>
> I have been trying at this all day! Not familiar with the async message
> stuff, I have tried putting ‘sleep()’ in the source block, I have tried a
> throttle outside it and even discarding the first X items just before the
> UHD sink to flush the buffer away.
>
>
>
> This all causes weird underflows and things at the USRP and results in a
> horrible looking constellation at the RX (I am transmitting 2x1 MISO which
> requires perfect TX sync). This is exactly the behaviour, I think, that
> Matt warned of!!
>
>
>
> Could you give me a bit more of an idea of how to even do the simpler
> idea, that I had thought of… I need to basically trigger the source at
> certain intervals. How does the message queue interact with the block, does
> the program flow jump to ‘parse_header_data_msg()’ automatically when a
> message arrives?
>
>
>
> DH
>
>
>
> *From:* John Malsbury [mailto:jmalsbury.perso...@gmail.com]
> *Sent:* 14 October 2014 23:42
> *To:* David Halls
> *Cc:* Matt Ettus; GNURadio
>
> *Subject:* Re: [Discuss-gnuradio] Source Block - Flow Control
>
>
>
> In the implementation I have in mind, the upstream logic didn't make
> decisions on when the data generating block should generate data per se...
> Instead, the upstream block provided feedback on the number of packets
> received by the USRP (via the old async message block).  With this feedback
> and knowledge of the interpolation steps between itself and the USRP, the
> data generating block could throttle its own output to achieve a specified
> latency [on the order of 10's of ms].
>
> I think using a simpler scheme of triggering with an async message would
> be a more convenient place to start though... What do you think, David?
>
>
> -John
>
>
>
> On Tue, Oct 14, 2014 at 3:23 PM, David Halls 
> wrote:
>
>  Hi John,
>
>
>
> Nice to hear from you.
>
>
>
> Perhaps in a similar fashion to Martin's HPD block; I can pass a message
> back from later in the flow graph to indicate when to release a packet from
> the source?
>
>
>
> David
>
>
>
>  Original message 
>
> From: John Malsbury
>
> Date:2014/10/14 23:08 (GMT+00:00)
>
> To: David Halls
>
> Cc: Matt Ettus ,GNURadio
>
> Subject: Re: [Discuss-gnuradio] Source Block - Flow Control
>
>
>
> David,
>
> Perhaps you can use an async message to trigger the blocks output?
>
> In some applications that require filler between valid data frames, I've
> seen people throttle based off of the number and size of received messages
> at the USRP.
>
> -John
>
>
>
>
>
> On Tue, Oct 14, 2014 at 3:02 PM, David Halls 
> wrote:
>
>  That sounds promising. The only thing is that the data *is* valid from
> time zero, but I just want to send the values from my source block, say
> once per second.
>
>
>
> What can I use to block in my block, just not produce any items for some
>

Re: [Discuss-gnuradio] Source Block - Flow Control

[John Malsbury]

Also, I would have sent you a sample flow graph.. but the computer I'm in
front of has an embarrassingly old version of GR.

On Wed, Oct 15, 2014 at 12:03 PM, John Malsbury <
jmalsbury.perso...@gmail.com> wrote:

> H.. I've never done burst transmissions with a 2x MIMO case.  That may
> or may not put a minor wrinkle in things.  Let's go for the gusto and try
> this anyway...
>
> (or were you not looking for a burst transmission?)
>
> This assumes you're using a relatively recent (past couple months?) build
> of UHD and GR.
>
>1. Produce some data as a PDU.  The quickest is to use a message
>strobe into a random PDU generator.  If you want data you control, use a
>message strobe with something like this as the message value:
>
>
>
> pmt.cons(pmt.to_pmt({}),pmt.init_u8vector(payload_size,[0x55]*payload_size))
>
>Of course, you'd ultimately replace this fixed or random data with
>your own PDU-producing block.  Or maybe use some clever python inside or
>outside the flowgraph.
>
>2. Use PDU-to-stream block, make sure the length tag name matches
>whatever UHD is using downstream (this is a parameter in the uhd sink now).
>
>3. Put that stream through your modulator.
>
>4. I think there's a block that multiplies the value of the length in
>the length tag.  set this to the interpolation factor of your modulator and
>put it somewhere in the chain.  If this block does not have one, borrow the
>one from gr-mac.  "burst_tagger"
><https://github.com/jmalsbury/gr-mac/blob/master/lib/burst_tagger_impl.cc>
>
> In summary:
>
>*Message Strobe -> Random PDU -> PDU to Stream -> Modulator ->
> [see how the constellation works]*
>
> Give it a shot.  If it doesnt work, give a brief try with the SISO case.
>
> You'll want to add some leading/trailing samples to flush FIR-filters and
> such for the full frame to get out of the USRP unscathed.  We can address
> this next...
> -John
>
> On Wed, Oct 15, 2014 at 11:47 AM, David Halls <
> david.ha...@toshiba-trel.com> wrote:
>
>>  Hi John,
>>
>>
>>
>> I have been trying at this all day! Not familiar with the async message
>> stuff, I have tried putting ‘sleep()’ in the source block, I have tried a
>> throttle outside it and even discarding the first X items just before the
>> UHD sink to flush the buffer away.
>>
>>
>>
>> This all causes weird underflows and things at the USRP and results in a
>> horrible looking constellation at the RX (I am transmitting 2x1 MISO which
>> requires perfect TX sync). This is exactly the behaviour, I think, that
>> Matt warned of!!
>>
>>
>>
>> Could you give me a bit more of an idea of how to even do the simpler
>> idea, that I had thought of… I need to basically trigger the source at
>> certain intervals. How does the message queue interact with the block, does
>> the program flow jump to ‘parse_header_data_msg()’ automatically when a
>> message arrives?
>>
>>
>>
>> DH
>>
>>
>>
>> *From:* John Malsbury [mailto:jmalsbury.perso...@gmail.com]
>> *Sent:* 14 October 2014 23:42
>> *To:* David Halls
>> *Cc:* Matt Ettus; GNURadio
>>
>> *Subject:* Re: [Discuss-gnuradio] Source Block - Flow Control
>>
>>
>>
>> In the implementation I have in mind, the upstream logic didn't make
>> decisions on when the data generating block should generate data per se...
>> Instead, the upstream block provided feedback on the number of packets
>> received by the USRP (via the old async message block).  With this feedback
>> and knowledge of the interpolation steps between itself and the USRP, the
>> data generating block could throttle its own output to achieve a specified
>> latency [on the order of 10's of ms].
>>
>> I think using a simpler scheme of triggering with an async message would
>> be a more convenient place to start though... What do you think, David?
>>
>>
>> -John
>>
>>
>>
>> On Tue, Oct 14, 2014 at 3:23 PM, David Halls <
>> david.ha...@toshiba-trel.com> wrote:
>>
>>  Hi John,
>>
>>
>>
>> Nice to hear from you.
>>
>>
>>
>> Perhaps in a similar fashion to Martin's HPD block; I can pass a message
>> back from later in the flow graph to indicate when to release a packet from
>> the source?
>>
>>
>>
>> David
>>
>>
>>
>>  Original message 
>>
>> From: John Malsbury
>>
>> D

Re: [Discuss-gnuradio] Source Block - Flow Control

[David Halls]

John thanks for all your help, this works, although it is necessary to add 
‘tx_sob’ and ‘tx_eob’ tags (or certainly it is for those not using the latest 
gr-uhd).

If you are using MIMO it is more complicated, as you have to add a ‘tx_time’ 
tag as well. This is not obvious how to generate in a tx flow graph.

My solution was to use a UHD source (the same address as the tx USRP), which 
generates rx_time, I then created a block which reads in this rx_time tag and 
sends it as a message to a block just before my UHD sink which converts this to 
a tx_time based on the number of bursts sent, and the burst interval that I 
desire.



As I am using MIMO, i.e. multiple USRPs in one UHD sink, I also had to use 
multiple USRPs in the UHD source to produce the rx_time (although the multiple 
rx_times will be equal).



From: John Malsbury [mailto:jmalsbury.perso...@gmail.com]
Sent: 15 October 2014 20:03
To: David Halls
Cc: Matt Ettus; GNURadio
Subject: Re: [Discuss-gnuradio] Source Block - Flow Control

H.. I've never done burst transmissions with a 2x MIMO case.  That may or 
may not put a minor wrinkle in things.  Let's go for the gusto and try this 
anyway...

(or were you not looking for a burst transmission?)

This assumes you're using a relatively recent (past couple months?) build of 
UHD and GR.

  1.  Produce some data as a PDU.  The quickest is to use a message strobe into 
a random PDU generator.  If you want data you control, use a message strobe 
with something like this as the message value:

pmt.cons(pmt.to_pmt({}),pmt.init_u8vector(payload_size,[0x55]*payload_size))

Of course, you'd ultimately replace this fixed or random data with your own 
PDU-producing block.  Or maybe use some clever python inside or outside the 
flowgraph.
  2.  Use PDU-to-stream block, make sure the length tag name matches whatever 
UHD is using downstream (this is a parameter in the uhd sink now).
  3.  Put that stream through your modulator.
  4.  I think there's a block that multiplies the value of the length in the 
length tag.  set this to the interpolation factor of your modulator and put it 
somewhere in the chain.  If this block does not have one, borrow the one from 
gr-mac.  
"burst_tagger"<https://github.com/jmalsbury/gr-mac/blob/master/lib/burst_tagger_impl.cc>

In summary:

   Message Strobe -> Random PDU -> PDU to Stream -> Modulator ->[see 
how the constellation works]

Give it a shot.  If it doesnt work, give a brief try with the SISO case.

You'll want to add some leading/trailing samples to flush FIR-filters and such 
for the full frame to get out of the USRP unscathed.  We can address this 
next...
-John

On Wed, Oct 15, 2014 at 11:47 AM, David Halls 
mailto:david.ha...@toshiba-trel.com>> wrote:
Hi John,

I have been trying at this all day! Not familiar with the async message stuff, 
I have tried putting ‘sleep()’ in the source block, I have tried a throttle 
outside it and even discarding the first X items just before the UHD sink to 
flush the buffer away.

This all causes weird underflows and things at the USRP and results in a 
horrible looking constellation at the RX (I am transmitting 2x1 MISO which 
requires perfect TX sync). This is exactly the behaviour, I think, that Matt 
warned of!!

Could you give me a bit more of an idea of how to even do the simpler idea, 
that I had thought of… I need to basically trigger the source at certain 
intervals. How does the message queue interact with the block, does the program 
flow jump to ‘parse_header_data_msg()’ automatically when a message arrives?

DH

From: John Malsbury 
[mailto:jmalsbury.perso...@gmail.com<mailto:jmalsbury.perso...@gmail.com>]
Sent: 14 October 2014 23:42
To: David Halls
Cc: Matt Ettus; GNURadio

Subject: Re: [Discuss-gnuradio] Source Block - Flow Control

In the implementation I have in mind, the upstream logic didn't make decisions 
on when the data generating block should generate data per se...  Instead, the 
upstream block provided feedback on the number of packets received by the USRP 
(via the old async message block).  With this feedback and knowledge of the 
interpolation steps between itself and the USRP, the data generating block 
could throttle its own output to achieve a specified latency [on the order of 
10's of ms].
I think using a simpler scheme of triggering with an async message would be a 
more convenient place to start though... What do you think, David?

-John

On Tue, Oct 14, 2014 at 3:23 PM, David Halls 
mailto:david.ha...@toshiba-trel.com>> wrote:
Hi John,

Nice to hear from you.

Perhaps in a similar fashion to Martin's HPD block; I can pass a message back 
from later in the flow graph to indicate when to release a packet from the 
source?

David

 Original message 
From: John Malsbury
Date:2014/10/14 23:08 (GMT+00:00)
To: David Halls
Cc: Matt Ettus ,GNURadio
Subject: Re: [Discuss-gnuradi

Re: [Discuss-gnuradio] Source Block - Flow Control

[John Malsbury]

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?

-John

On Thu, Oct 16, 2014 at 7:23 AM, David Halls 
wrote:

>  John thanks for all your help, this works, although it is necessary to
> add ‘tx_sob’ and ‘tx_eob’ tags (or certainly it is for those not using the
> latest gr-uhd).
>
>
>
> If you are using MIMO it is more complicated, as you have to add a
> ‘tx_time’ tag as well. This is not obvious how to generate in a tx flow
> graph.
>
>
>
> My solution was to use a UHD source (the same address as the tx USRP),
> which generates rx_time, I then created a block which reads in this rx_time
> tag and sends it as a message to a block just before my UHD sink which
> converts this to a tx_time based on the number of bursts sent, and the
> burst interval that I desire.
>
>
>
> As I am using MIMO, i.e. multiple USRPs in one UHD sink, I also had to use
> multiple USRPs in the UHD source to produce the rx_time (although the
> multiple rx_times will be equal).
>
>
>
>
>
>
>
> *From:* John Malsbury [mailto:jmalsbury.perso...@gmail.com]
> *Sent:* 15 October 2014 20:03
>
> *To:* David Halls
> *Cc:* Matt Ettus; GNURadio
> *Subject:* Re: [Discuss-gnuradio] Source Block - Flow Control
>
>
>
> H.. I've never done burst transmissions with a 2x MIMO case.  That may
> or may not put a minor wrinkle in things.  Let's go for the gusto and try
> this anyway...
>
> (or were you not looking for a burst transmission?)
>
>
> This assumes you're using a relatively recent (past couple months?) build
> of UHD and GR.
>
>1. Produce some data as a PDU.  The quickest is to use a message
>strobe into a random PDU generator.  If you want data you control, use a
>message strobe with something like this as the message value:
>
>
>
> pmt.cons(pmt.to_pmt({}),pmt.init_u8vector(payload_size,[0x55]*payload_size))
>
>Of course, you'd ultimately replace this fixed or random data with
>your own PDU-producing block.  Or maybe use some clever python inside or
>outside the flowgraph.
>2. Use PDU-to-stream block, make sure the length tag name matches
>whatever UHD is using downstream (this is a parameter in the uhd sink now).
>3. Put that stream through your modulator.
>4. I think there's a block that multiplies the value of the length in
>the length tag.  set this to the interpolation factor of your modulator and
>put it somewhere in the chain.  If this block does not have one, borrow the
>one from gr-mac.  "burst_tagger"
><https://github.com/jmalsbury/gr-mac/blob/master/lib/burst_tagger_impl.cc>
>
> In summary:
>
>*Message Strobe -> Random PDU -> PDU to Stream -> Modulator ->
> [see how the constellation works]*
>
> Give it a shot.  If it doesnt work, give a brief try with the SISO case.
>
> You'll want to add some leading/trailing samples to flush FIR-filters and
> such for the full frame to get out of the USRP unscathed.  We can address
> this next...
>
> -John
>
>
>
> On Wed, Oct 15, 2014 at 11:47 AM, David Halls <
> david.ha...@toshiba-trel.com> wrote:
>
>  Hi John,
>
>
>
> I have been trying at this all day! Not familiar with the async message
> stuff, I have tried putting ‘sleep()’ in the source block, I have tried a
> throttle outside it and even discarding the first X items just before the
> UHD sink to flush the buffer away.
>
>
>
> This all causes weird underflows and things at the USRP and results in a
> horrible looking constellation at the RX (I am transmitting 2x1 MISO which
> requires perfect TX sync). This is exactly the behaviour, I think, that
> Matt warned of!!
>
>
>
> Could you give me a bit more of an idea of how to even do the simpler
> idea, that I had thought of… I need to basically trigger the source at
> certain intervals. How does the message queue interact with the block, does
> the program flow jump to ‘parse_header_data_msg()’ automatically when a
> message arrives?
>
>
>
> DH
>
>
>
> *From:* John Malsbury [mailto:jmalsbury.perso...@gmail.com]
> *Sent:* 14 October 2014 23:42
> *To:* David Halls
> *Cc:* Matt Ettus; GNURadio
>
>
> *Subject:* Re: [Discuss-gnuradio] Source Block -

Re: [Discuss-gnuradio] Source Block - Flow Control

[David Halls]

That's right John, the tx_time tag was required.

This is actually relatively involved to create in a tx flow graph. I added a 
UHD source to acquire rx_time which I then pass as a message to a block just 
before the twin UHD sink, where I calculate a desired tx_time.

perhaps someone can chime in as to whether the new message ports that Martin 
has added to the UHD blocks allow messages to pass out of the block or are they 
for passing info in only? If so this would be an easier way to do it I guess

I still get 2 Us (one for each usrp) at the very beginning. Although this 
doesn't seem to damage performance.  If I add some padding items to the 
beginning before the first burst would this help? and if so what's an elegant 
way to do so?

Interested to hear if anyone can answer John's question too!


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

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?

-John

On Thu, Oct 16, 2014 at 7:23 AM, David Halls 
mailto:david.ha...@toshiba-trel.com>> wrote:
John thanks for all your help, this works, although it is necessary to add 
‘tx_sob’ and ‘tx_eob’ tags (or certainly it is for those not using the latest 
gr-uhd).

If you are using MIMO it is more complicated, as you have to add a ‘tx_time’ 
tag as well. This is not obvious how to generate in a tx flow graph.

My solution was to use a UHD source (the same address as the tx USRP), which 
generates rx_time, I then created a block which reads in this rx_time tag and 
sends it as a message to a block just before my UHD sink which converts this to 
a tx_time based on the number of bursts sent, and the burst interval that I 
desire.



As I am using MIMO, i.e. multiple USRPs in one UHD sink, I also had to use 
multiple USRPs in the UHD source to produce the rx_time (although the multiple 
rx_times will be equal).



From: John Malsbury 
[mailto:jmalsbury.perso...@gmail.com<mailto:jmalsbury.perso...@gmail.com>]
Sent: 15 October 2014 20:03

To: David Halls
Cc: Matt Ettus; GNURadio
Subject: Re: [Discuss-gnuradio] Source Block - Flow Control

H.. I've never done burst transmissions with a 2x MIMO case.  That may or 
may not put a minor wrinkle in things.  Let's go for the gusto and try this 
anyway...

(or were you not looking for a burst transmission?)

This assumes you're using a relatively recent (past couple months?) build of 
UHD and GR.

  1.  Produce some data as a PDU.  The quickest is to use a message strobe into 
a random PDU generator.  If you want data you control, use a message strobe 
with something like this as the message value:

pmt.cons(pmt.to_pmt({}),pmt.init_u8vector(payload_size,[0x55]*payload_size))

Of course, you'd ultimately replace this fixed or random data with your own 
PDU-producing block.  Or maybe use some clever python inside or outside the 
flowgraph.
  2.  Use PDU-to-stream block, make sure the length tag name matches whatever 
UHD is using downstream (this is a parameter in the uhd sink now).
  3.  Put that stream through your modulator.
  4.  I think there's a block that multiplies the value of the length in the 
length tag.  set this to the interpolation factor of your modulator and put it 
somewhere in the chain.  If this block does not have one, borrow the one from 
gr-mac.  
"burst_tagger"<https://github.com/jmalsbury/gr-mac/blob/master/lib/burst_tagger_impl.cc>

In summary:

   Message Strobe -> Random PDU -> PDU to Stream -> Modulator ->[see 
how the constellation works]

Give it a shot.  If it doesnt work, give a brief try with the SISO case.

You'll want to add some leading/trailing samples to flush FIR-filters and such 
for the full frame to get out of the USRP unscathed.  We can address this 
next...
-John

On Wed, Oct 15, 2014 at 11:47 AM, David Halls 
mailto:david.ha...@toshiba-trel.com>> wrote:
Hi John,

I have been trying at this all day! Not familiar with the async message stuff, 
I have tried putting ‘sleep()’ in the source block, I have tried a throttle 
outside it and even discarding the first X items just before the UHD sink to 
flush the buffer away.

This all causes weird underflows and things at the USRP and results in a 
horrible looking constellation at the RX (I am transmitting 2x1 MISO which 
requires perfect TX sync). This is exactly the behaviour, I think, that Matt

Re: [Discuss-gnuradio] Source Block - Flow Control

[Matt Ettus]

On Thu, Oct 16, 2014 at 8:40 AM, John Malsbury  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
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Source Block - Flow Control

[David Halls]

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



On Thu, Oct 16, 2014 at 8:40 AM, John Malsbury 
mailto:jmalsbury.perso...@gmail.com>> 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
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Source Block - Flow Control

[Matt Ettus]

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 
wrote:

>
>
>   Original message 
> From: Matt Ettus
> Date:2014/10/16 22:42 (GMT+00:00)
> To: John Malsbury
> Cc: David Halls ,GNURadio
> Subject: Re: [Discuss-gnuradio] Source Block - Flow Control
>
>
>
> On Thu, Oct 16, 2014 at 8:40 AM, John Malsbury <
> jmalsbury.perso...@gmail.com> 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
>
>
>
> --
> This email has been scanned for email related threats and delivered safely
> by Mimecast.
> For more information please visit http://www.mimecast.com
> --
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Source Block - Flow Control

[David Halls]

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 Ettus
Date:2014/10/16 22:54 (GMT+00:00)
To: David Halls
Cc: John Malsbury ,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 
mailto:david.ha...@toshiba-trel.com>> wrote:


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



On Thu, Oct 16, 2014 at 8:40 AM, John Malsbury 
mailto:jmalsbury.perso...@gmail.com>> 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<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
---


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Source Block - Flow Control

[Matt Ettus]

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 
wrote:

>  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 Ettus
> Date:2014/10/16 22:54 (GMT+00:00)
> To: David Halls
> Cc: John Malsbury ,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  > wrote:
>
>>
>>
>>   Original message 
>> From: Matt Ettus
>>  Date:2014/10/16 22:42 (GMT+00:00)
>> To: John Malsbury
>> Cc: David Halls ,GNURadio
>> Subject: Re: [Discuss-gnuradio] Source Block - Flow Control
>>
>>
>>
>>  On Thu, Oct 16, 2014 at 8:40 AM, John Malsbury <
>> jmalsbury.perso...@gmail.com> 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
>>
>>
>>
>>  --
>> 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
> --
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio