[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] stream tag samples

From: Nowlan, Sean
Subject: Re: [Discuss-gnuradio] stream tag samples
Date: Fri, 25 Oct 2013 19:40:53 +0000



From: discuss-gnuradio-bounces+address@hidden [mailto:discuss-gnuradio-bounces+address@hidden On Behalf Of Nowlan, Sean
Sent: Friday, October 25, 2013 3:23 PM
To: Jenny Galasso; address@hidden
Subject: Re: [Discuss-gnuradio] stream tag samples



From: discuss-gnuradio-bounces+address@hidden [mailto:discuss-gnuradio-bounces+address@hidden] On Behalf Of Jenny Galasso
Sent: Friday, October 25, 2013 3:06 PM
To: address@hidden
Subject: [Discuss-gnuradio] stream tag samples


Today at 1:02 PM

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?





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.




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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]