>-----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? 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. _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
