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