On Mon, Nov 5, 2012 at 5:48 PM, Nowlan, Sean <sean.now...@gtri.gatech.edu> wrote: >>-----Original Message----- >>From: trond...@trondeau.com [mailto:trond...@trondeau.com] On Behalf Of Tom >>Rondeau >>Sent: Monday, November 05, 2012 5:16 PM >>To: Nowlan, Sean >>Cc: discuss-gnuradio@gnu.org >>Subject: Re: [Discuss-gnuradio] tag propagation in GNU Radio blocks >> >>On Mon, Nov 5, 2012 at 4:11 PM, Nowlan, Sean <sean.now...@gtri.gatech.edu> >>wrote: >>> How does tag propagation work in these 3 cases? Up until now I've only >>> been dealing with tags on streams running at the output rate of a USRP >>> sink. I've stated the assumed answers, but haven't tested... >>> >>> 1) gr_sync_block (interpolation by factor L): tag on incoming sample x >>> will be moved to sample x*L in output stream >>> >>> >>> >>> 2) gr_sync_block (decimation by factor M): tag on incoming sample x >>> will be moved to sample FLOOR(x/M) in output stream >>> >>> >>> >>> 3) gr_block with arbitrary relationship: user has to move tags >>> him/herself in general_work. >>> >>> >>> >>> Another question: does the scheduler re-number absolute sample offsets >>> after every rate-changing block, or does it work backwards from a sink >>> block all the way to the source block so that absolute offsets are >>> relative to the output? I can see this getting more hairy when >>> multiple source and sink blocks are used. >>> >>> >>> >>> Thanks, >>> >>> Sean >> >> >>Sean, >> >>Yes, you've pretty much got it. All blocks have a relative_rate. For >>interpolating blocks (by L), realative_rate=L, decimating by M >>relative_rate=1/M. Any other block that >has a rate change should set the >>relative_rate. >> >>When a tag is moved to a block, the propagation of the tag handles the >>changing of the item number based on the relative rate. This happens each >>time the tag is >moved between blocks. Since there's no state known about the >>rates of any other blocks, we cannot make a call on that when the tag is >>actually read or used. >> >>There are some tricky blocks that don't have a static relative rate that can >>cause problems with this concept. It's for this reason that we created the >>TPP_DONT tag >propagation policy. This tells the scheduler not to >>automatically pass tags along. In these cases, we expect the block itself to >>handle (or not) the proper manipulation of >the tag numbers. >> >>Tom > > Ok, so the "absolute sample index" at a particular block boundary is really > the nitems_written at the output of that block, and there is no absolute > index mapping maintained across a chain of blocks?
That's correct. The blocks (actually, the buffers attached to the blocks) keep track of the item counts. We try to minimize state across a flowgraph unless it's directly related to the flowgraph operation itself. We want to keep blocks as independent as possible. > Thanks for clearing that up! I see in gr_block.cc that the default tag > propagation policy is ALL-TO-ALL, and the corresponding behavior in > gr_block_executor.cc is that tags are moved according to tag.offset = > tag.offset * relative_rate. Yep, you got it! Tom _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
