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

Reply via email to