# Source Block - Flow Control **URL:** \ **Category:** GNU Radio\ **Created:** [October 14, 2014, 6:36pm UTC](https://www.ruby-forum.com/t/source-block-flow-control/232529 "2014-10-14T18:36:33Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![addis\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c4cdca/32.png) [@addis\_a](https://www.ruby-forum.com/u/addis_a)\ **Post date:** [October 14, 2014, 6:36pm UTC](https://www.ruby-forum.com/t/source-block-flow-control/232529/1 "2014-10-14T18:36:33Z")
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 ---
**Author:** ![divotdave](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/bbe5ce/32.png) [@divotdave](https://www.ruby-forum.com/u/divotdave)\ **Post date:** [October 14, 2014, 7:54pm UTC](https://www.ruby-forum.com/t/source-block-flow-control/232529/2 "2014-10-14T19:54:31Z")
Use a throttle block immediately after your source block, setting the vector size to match your source. - Jeff ---
**Author:** ![divotdave](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/bbe5ce/32.png) [@divotdave](https://www.ruby-forum.com/u/divotdave)\ **Post date:** [October 14, 2014, 7:58pm UTC](https://www.ruby-forum.com/t/source-block-flow-control/232529/3 "2014-10-14T19:58:05Z")
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 ---
**Author:** ![divotdave](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/bbe5ce/32.png) [@divotdave](https://www.ruby-forum.com/u/divotdave)\ **Post date:** [October 14, 2014, 8:10pm UTC](https://www.ruby-forum.com/t/source-block-flow-control/232529/4 "2014-10-14T20:10:00Z")
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 ---
**Author:** ![divotdave](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/bbe5ce/32.png) [@divotdave](https://www.ruby-forum.com/u/divotdave)\ **Post date:** [October 14, 2014, 10:08pm UTC](https://www.ruby-forum.com/t/source-block-flow-control/232529/5 "2014-10-14T22:08:27Z")
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 L. Date:2014/10/14 20:20 (GMT+00:00) To: Matt E. 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 E. wrote: > during the initial transient (which I don’t recommend), you should do > buffers are filled and the USRP is transmitting. How well this works > > ``` > Later stages of my flow graph are slowed by various bits of > want to slow this initial rate significantly. > > ``` ------------------------------ **------------------------------** ------------ > ``` > Toshiba Research Europe Limited, registered in England and Wales > safely by Mimecast. > > _________________________________________________ > Discuss-gnuradio mailing list > removed_email_address@domain.invalid > https://lists.gnu.org/mailman/__listinfo/discuss-gnuradio > > > ``` * * * Discuss-gnuradio mailing list [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) > **[Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio)** * * * NOTE: The information in this email and any attachments may be confidential and/or legally privileged. This message may be read, copied and used only by the intended recipient. If you are not the intended recipient, please destroy this message, delete any copies held on your system and notify the sender immediately. Toshiba Research Europe Limited, registered in England and Wales (2519556). Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl ---
**Author:** ![divotdave](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/bbe5ce/32.png) [@divotdave](https://www.ruby-forum.com/u/divotdave)\ **Post date:** [October 14, 2014, 9:20pm UTC](https://www.ruby-forum.com/t/source-block-flow-control/232529/6 "2014-10-14T21:20:50Z")
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 ---
**Author:** ![divotdave](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/bbe5ce/32.png) [@divotdave](https://www.ruby-forum.com/u/divotdave)\ **Post date:** [October 14, 2014, 11:58pm UTC](https://www.ruby-forum.com/t/source-block-flow-control/232529/7 "2014-10-14T23:58:31Z")
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 [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) ---
**Author:** ![divotdave](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/bbe5ce/32.png) [@divotdave](https://www.ruby-forum.com/u/divotdave)\ **Post date:** [October 14, 2014, 11:45pm UTC](https://www.ruby-forum.com/t/source-block-flow-control/232529/8 "2014-10-14T23:45:26Z")
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 E. Date:2014/10/14 19:09 (GMT+00:00) To: Jeff L. 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 L. \<[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)\> 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 L. 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 0790tel:%2B44%20(0)%20117%20906%200790 * * * 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](http://www.mimecast.com) * * * Discuss-gnuradio mailing list [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) * * * Discuss-gnuradio mailing list [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) * * * NOTE: The information in this email and any attachments may be confidential and/or legally privileged. This message may be read, copied and used only by the intended recipient. If you are not the intended recipient, please destroy this message, delete any copies held on your system and notify the sender immediately. Toshiba Research Europe Limited, registered in England and Wales (2519556). Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl ---
**Author:** ![divotdave](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/bbe5ce/32.png) [@divotdave](https://www.ruby-forum.com/u/divotdave)\ **Post date:** [October 15, 2014, 12:03am UTC](https://www.ruby-forum.com/t/source-block-flow-control/232529/9 "2014-10-15T00:03:53Z")
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 E. Date:2014/10/14 22:56 (GMT+00:00) To: David Halls Cc: Jeff L. ,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 \<[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)\> 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 E. Date:2014/10/14 19:09 (GMT+00:00) To: Jeff L. 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 L. \<[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)\> 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 L. 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 0790tel:%2B44%20(0)%20117%20906%200790 * * * 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](http://www.mimecast.com) * * * Discuss-gnuradio mailing list [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) * * * Discuss-gnuradio mailing list [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) * * * NOTE: The information in this email and any attachments may be confidential and/or legally privileged. This message may be read, copied and used only by the intended recipient. If you are not the intended recipient, please destroy this message, delete any copies held on your system and notify the sender immediately. Toshiba Research Europe Limited, registered in England and Wales (2519556). Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl[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](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 ---
**Author:** ![divotdave](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/bbe5ce/32.png) [@divotdave](https://www.ruby-forum.com/u/divotdave)\ **Post date:** [October 15, 2014, 12:09am UTC](https://www.ruby-forum.com/t/source-block-flow-control/232529/10 "2014-10-15T00:09:50Z")
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 [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) ---
**Author:** ![divotdave](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/bbe5ce/32.png) [@divotdave](https://www.ruby-forum.com/u/divotdave)\ **Post date:** [October 15, 2014, 12:42am UTC](https://www.ruby-forum.com/t/source-block-flow-control/232529/11 "2014-10-15T00:42:33Z")
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 [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) ---
**Author:** ![divotdave](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/bbe5ce/32.png) [@divotdave](https://www.ruby-forum.com/u/divotdave)\ **Post date:** [October 15, 2014, 12:25am UTC](https://www.ruby-forum.com/t/source-block-flow-control/232529/12 "2014-10-15T00:25:18Z")
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 M. Date:2014/10/14 23:08 (GMT+00:00) To: David Halls Cc: Matt E. ,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 \<[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)\> 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 E. Date:2014/10/14 22:56 (GMT+00:00) To: David Halls Cc: Jeff L. ,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 \<[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)\> 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 E. Date:2014/10/14 19:09 (GMT+00:00) To: Jeff L. 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 L. \<[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)\> 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 L. 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 0790tel:%2B44%20(0)%20117%20906%200790 * * * 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](http://www.mimecast.com) * * * Discuss-gnuradio mailing list [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) * * * Discuss-gnuradio mailing list [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) * * * NOTE: The information in this email and any attachments may be confidential and/or legally privileged. This message may be read, copied and used only by the intended recipient. If you are not the intended recipient, please destroy this message, delete any copies held on your system and notify the sender immediately. Toshiba Research Europe Limited, registered in England and Wales (2519556). Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl[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](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[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](http://www.mimecast.com) * * * * * * Discuss-gnuradio mailing list [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) * * * NOTE: The information in this email and any attachments may be confidential and/or legally privileged. This message may be read, copied and used only by the intended recipient. If you are not the intended recipient, please destroy this message, delete any copies held on your system and notify the sender immediately. Toshiba Research Europe Limited, registered in England and Wales (2519556). Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl ---
**Author:** ![divotdave](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/bbe5ce/32.png) [@divotdave](https://www.ruby-forum.com/u/divotdave)\ **Post date:** [October 15, 2014, 8:49pm UTC](https://www.ruby-forum.com/t/source-block-flow-control/232529/13 "2014-10-15T20:49:09Z")
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 M. [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] Sent: 14 October 2014 23:42 To: David Halls Cc: Matt E.; 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 \<[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)\> 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 M. Date:2014/10/14 23:08 (GMT+00:00) To: David Halls Cc: Matt E. ,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 \<[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)\> 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 E. Date:2014/10/14 22:56 (GMT+00:00) To: David Halls Cc: Jeff L. ,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 \<[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)\> 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 E. Date:2014/10/14 19:09 (GMT+00:00) To: Jeff L. 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 L. \<[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)\> 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 L. 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 0790tel:%2B44%20(0)%20117%20906%200790 * * * 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](http://www.mimecast.com) * * * Discuss-gnuradio mailing list [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) * * * Discuss-gnuradio mailing list [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) * * * NOTE: The information in this email and any attachments may be confidential and/or legally privileged. This message may be read, copied and used only by the intended recipient. If you are not the intended recipient, please destroy this message, delete any copies held on your system and notify the sender immediately. Toshiba Research Europe Limited, registered in England and Wales (2519556). Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl[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](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[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](http://www.mimecast.com) * * * * * * Discuss-gnuradio mailing list [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) * * * NOTE: The information in this email and any attachments may be confidential and/or legally privileged. This message may be read, copied and used only by the intended recipient. If you are not the intended recipient, please destroy this message, delete any copies held on your system and notify the sender immediately. Toshiba Research Europe Limited, registered in England and Wales (2519556). Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl[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](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 ---
**Author:** ![divotdave](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/bbe5ce/32.png) [@divotdave](https://www.ruby-forum.com/u/divotdave)\ **Post date:** [October 15, 2014, 9:04pm UTC](https://www.ruby-forum.com/t/source-block-flow-control/232529/14 "2014-10-15T21:04:38Z")
Hmmmm… 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. 1. 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). 2. Put that stream through your modulator. 3. 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](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 [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) ---
**Author:** ![divotdave](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/bbe5ce/32.png) [@divotdave](https://www.ruby-forum.com/u/divotdave)\ **Post date:** [October 15, 2014, 8:51am UTC](https://www.ruby-forum.com/t/source-block-flow-control/232529/15 "2014-10-15T08:51:25Z")
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 ---
**Author:** ![divotdave](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/bbe5ce/32.png) [@divotdave](https://www.ruby-forum.com/u/divotdave)\ **Post date:** [October 15, 2014, 9:05pm UTC](https://www.ruby-forum.com/t/source-block-flow-control/232529/16 "2014-10-15T21:05:13Z")
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 M. \< ---
**Author:** ![divotdave](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/bbe5ce/32.png) [@divotdave](https://www.ruby-forum.com/u/divotdave)\ **Post date:** [October 16, 2014, 5:42pm UTC](https://www.ruby-forum.com/t/source-block-flow-control/232529/17 "2014-10-16T17:42:12Z")
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 [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) ---
**Author:** ![divotdave](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/bbe5ce/32.png) [@divotdave](https://www.ruby-forum.com/u/divotdave)\ **Post date:** [October 16, 2014, 4:25pm UTC](https://www.ruby-forum.com/t/source-block-flow-control/232529/18 "2014-10-16T16:25:24Z")
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 M. [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] Sent: 15 October 2014 20:03 To: David Halls Cc: Matt E.; GNURadio Subject: Re: [Discuss-gnuradio] Source Block - Flow Control Hmmmm.. 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](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 \<[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)\> 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 M. [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] Sent: 14 October 2014 23:42 To: David Halls Cc: Matt E.; 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 \<[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)\> 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 M. Date:2014/10/14 23:08 (GMT+00:00) To: David Halls Cc: Matt E. ,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 \<[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)\> 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 E. Date:2014/10/14 22:56 (GMT+00:00) To: David Halls Cc: Jeff L. ,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 \<[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)\> 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 E. Date:2014/10/14 19:09 (GMT+00:00) To: Jeff L. 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 L. \<[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)\> 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 L. 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 0790tel:%2B44%20(0)%20117%20906%200790 * * * 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](http://www.mimecast.com) * * * Discuss-gnuradio mailing list [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) * * * Discuss-gnuradio mailing list [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) * * * NOTE: The information in this email and any attachments may be confidential and/or legally privileged. This message may be read, copied and used only by the intended recipient. If you are not the intended recipient, please destroy this message, delete any copies held on your system and notify the sender immediately. Toshiba Research Europe Limited, registered in England and Wales (2519556). Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl[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](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[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](http://www.mimecast.com) * * * * * * Discuss-gnuradio mailing list [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) * * * NOTE: The information in this email and any attachments may be confidential and/or legally privileged. This message may be read, copied and used only by the intended recipient. If you are not the intended recipient, please destroy this message, delete any copies held on your system and notify the sender immediately. Toshiba Research Europe Limited, registered in England and Wales (2519556). Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl[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](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[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](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 ---
**Author:** ![divotdave](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/bbe5ce/32.png) [@divotdave](https://www.ruby-forum.com/u/divotdave)\ **Post date:** [October 16, 2014, 11:40pm UTC](https://www.ruby-forum.com/t/source-block-flow-control/232529/19 "2014-10-16T23:40:01Z")
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 M. Date:2014/10/16 16:40 (GMT+00:00) To: David Halls Cc: Matt E. ,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 \<[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)\> 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 M. [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] Sent: 15 October 2014 20:03 To: David Halls Cc: Matt E.; GNURadio Subject: Re: [Discuss-gnuradio] Source Block - Flow Control Hmmmm.. 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](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 \<[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)\> 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 M. [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] Sent: 14 October 2014 23:42 To: David Halls Cc: Matt E.; 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 \<[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)\> 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 M. Date:2014/10/14 23:08 (GMT+00:00) To: David Halls Cc: Matt E. ,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 \<[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)\> 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 E. Date:2014/10/14 22:56 (GMT+00:00) To: David Halls Cc: Jeff L. ,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 \<[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)\> 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 E. Date:2014/10/14 19:09 (GMT+00:00) To: Jeff L. 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 L. \<[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)\> 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 L. 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 0790tel:%2B44%20(0)%20117%20906%200790 * * * 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](http://www.mimecast.com) * * * Discuss-gnuradio mailing list [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) * * * Discuss-gnuradio mailing list [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) * * * NOTE: The information in this email and any attachments may be confidential and/or legally privileged. This message may be read, copied and used only by the intended recipient. If you are not the intended recipient, please destroy this message, delete any copies held on your system and notify the sender immediately. Toshiba Research Europe Limited, registered in England and Wales (2519556). Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl[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](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[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](http://www.mimecast.com) * * * * * * Discuss-gnuradio mailing list [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) * * * NOTE: The information in this email and any attachments may be confidential and/or legally privileged. This message may be read, copied and used only by the intended recipient. If you are not the intended recipient, please destroy this message, delete any copies held on your system and notify the sender immediately. Toshiba Research Europe Limited, registered in England and Wales (2519556). Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl[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](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[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](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[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](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 ---
**Author:** ![divotdave](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/bbe5ce/32.png) [@divotdave](https://www.ruby-forum.com/u/divotdave)\ **Post date:** [October 16, 2014, 11:44pm UTC](https://www.ruby-forum.com/t/source-block-flow-control/232529/20 "2014-10-16T23:44:11Z")
On Thu, Oct 16, 2014 at 8:40 AM, John M. \<[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) > 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