Hi Zing Yu, to be fair, this problem is not what you asked for in your initial post.
A couple of notes: - The output buffer does not have to be "full" in order for the scheduler to call the following downstream block. - Undeterministic latency is one inherent problem of GNU Radio - 200 ms seems a bit much, though. Have you tried decreasing the buffer sizes between blocks? (Try set_max_output_buffer()). - How many blocks are between your custom block and the UHD sink? Lots of blocks == lots of latency. MB On Mon, Dec 03, 2012 at 11:21:29AM -0800, Zing Yu wrote: > Hi Tom, > > What you have suggested is absolutely fine but it does not solve my problem. > Actually, my custom block sends a burst of N samples whenever a condition in > its code is met. Since that conditon is met pretty much regularly, I can say > that the custom block sends a burst after every ~30 mS. Now, whenever > noutput_items=2N are assigned to work() of my custom block, I observe that > particular (to be transmitted) burst somehow does not get sent asap, rather it > is sent after ~200mS. I have verified this by two ways: > i) I receive the transmitted bursts at another node and measure the delay > between successive bursts. > ii) On the other hand, I time each bursts by means of tx_time_tag. Then, I do > see that whenever noutput_items=2N, I see "L" printed in the console (which > means packet is late and is discarded by the FPGA). > > So, in summary, I would like to send my bursts asap no matter what value > noutput_items takes. Or, I want the scheduler to assign me exactly > noutput_items=N items everytime. What do you suggest? > > Thanks, > Yu. > > p.s. > > Alex, > > > Could you explain a bit more how to accomplish what you have said? Thanks. > > ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ > From: Tom Rondeau <[email protected]> > To: Zing Yu <[email protected]> > Cc: "discu [email protected]" <[email protected]> > Sent: Friday, November 30, 2012 7:24 PM > Subject: Re: [Discuss-gnuradio] control of noutput_items by the user > > > > Yu, > > > You don't always have to consume everything that's handed to you. So if you > get > kN items, just process N of them, return N, then the scheduler will pass you > the next N items in the buffer next time. > > > Tom > > > > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association
pgpHBT2MQphTL.pgp
Description: PGP signature
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
