From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech....@gnu.org [mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech....@gnu.org] On Behalf Of Nowlan, Sean Sent: Friday, October 25, 2013 3:23 PM To: Jenny Galasso; discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] stream tag samples
From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech....@gnu.org<mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech....@gnu.org> [mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech....@gnu.org] On Behalf Of Jenny Galasso Sent: Friday, October 25, 2013 3:06 PM To: discuss-gnuradio@gnu.org<mailto:discuss-gnuradio@gnu.org> Subject: [Discuss-gnuradio] stream tag samples Today at 1:02 PM Hi, I'm using stream tags to time tag my data. In particular, I'm reading in one-second files and tagging the first sample read in with the time. I'm concerned with how the tag will be handled during decimation, filtering etc. I have read the documentation and understand that the tag is reassigned based on the relative_rate. For this particular data set though, it is important that the tags stay with the specific samples to which they were assigned, even if some of the tags are lost during decimation, filtering, etc. Is this even possible? Are there any recommendations or tricks to get it to behave this way? Thanks! Jenny Hi Jenny, If you decimate by N, you're getting rid of N-1 out of every N samples. So naturally you would want the tag to stick with the sample that doesn't get thrown out. Similarly, if you interpolate by M, you introduce M-1 samples into the stream for every input sample; you'd naturally want the tag associated with input sample /i/ to be placed on the first sample of the corresponding batch of M output samples. The propagate_tags method in gnuradio/gnuradio-runtime/lib/block_executor.cc handles this by default. You can override this behavior in your own blocks by calling "set_tag_propagation_policy(TPP_DONT)" in your block's constructor and then handling tags yourself in your work method. Sean I don't think there's a way to tell GNU Radio blocks derived from sync_decimator and sync_interpolator to quit propagating tags as described above (unless you write blocks that inherit from these classes yourself). It's the only way that really makes sense when changing rate domains by a rational factor. Sean
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio